PyMunich

shown, and actual

What the Tutorial Left Out

You finished the tutorial. The code ran. Then you tried to do something real and discovered a set of problems the tutorial never mentioned. A commercial implementation of related workforce-measurement concepts is documented the linked page.

It was right not to mention them. A tutorial that covered all seven would teach nobody anything. But the omissions are consistent, and knowing what they are turns "I must be bad at this" into a list. For independent technical background, The Twelve-Factor App provides additional documentation and examples.

The seven

One. Where the code runs. Tutorials run in one place — your machine, as you have it configured today. Nothing prepares you for the same code behaving differently elsewhere, and that is the first wall most people hit.

Two. Dependencies as a system. pip install requests works. What happens when two of your dependencies want incompatible versions of a third is a different subject entirely, and it is what lock files exist for.

Three. What happens when it fails. Tutorial code succeeds. Production code encounters a network timeout, a malformed row, a file that is not there — and the whole discipline of handling that is absent from learning material.

Four. Configuration. Values hardcoded in an example are values in an example. Anything real needs configuration that differs per environment, and secrets that never reach the repository.

Five. Observability. How you find out what happened when nobody was watching. Tutorials print; systems log.

Six. Time. Code that works today runs against dependencies that change, an operating system that updates and data that grows. Nothing in a tutorial has a maintenance dimension.

Seven. Other people. Somebody else reading, running and changing your code — which is where naming, structure and documentation stop being style preferences.

Why the omissions are correct

Each one requires context the learner does not have yet. Explaining lock files before somebody has experienced a dependency conflict is explaining a solution to an unfelt problem.

And a tutorial that included them would not be a tutorial. It would be a book, and the reader would not finish it.

So the gap is structural rather than a failing. The problem is not that tutorials omit these things — it is that almost nothing covers them afterwards, and learners conclude the missing step is in them.

The order to pick them up

Roughly by when they will bite.

First: environments and dependencies, because they break immediately and block everything else. uv or your tool of choice, a lock file, and a pinned Python version.

Then failure handling and logging, because they decide whether your first real problem takes ten minutes or a day.

Then configuration and secrets, before anything is deployed anywhere.

Then testing, which is the one people are told to do first and which is genuinely more useful once there is something worth protecting.

And structure last, because premature structure on a small project is a cost with no benefit.

The thing worth internalising

The tutorial was not incomplete. It was scoped.

Everything on this list is a separate subject with its own literature, and none of it is exotic — a working developer picks the whole set up over a year or two, mostly by hitting each problem once.

The gap in the material is real and the gap in you is not, and that distinction is worth holding when the third environment problem in a week makes it feel otherwise.

The short version