Main idea

Technical experience is built in a short loop: you try, you fail, you search, you understand, you fix, and you keep something from the fix. Half an hour on a contained bug, a day on an endpoint that resists, a problem picked up again the next morning — it is that detour that teaches you to recognize the faint signals in a piece of code and to sense that an overly easy solution hides a cost.

It isn't the pain that teaches, it is the analyzability. As long as the flaw fits within a perimeter you can open, read and trace back to a decision, it instructs. When it shows up on a system that has grown, whose layers have piled up, whose decisions are implicit and whose tests may be validating a flawed understanding of the need, it can no longer be traced to anything: nobody knows why everything is collapsing.

The move that follows is the patch. You don't understand any better, you add one more layer onto an architecture you never inhabited.

Why it matters

This redefines what to protect when you want a team to learn. It isn't the presence of errors — there will be some — it is their size and the delay before they appear, two quantities you can act on through scoping, tests and release frequency.

It also explains why a team can accumulate years of incidents without gaining skill: its errors always arrive too late and too large to teach anything.

Nuances and limits

Some late errors teach remarkably well, provided something makes them analyzable after the fact: a serious post-mortem, a reconstructed timeline, an operational trace. Analyzability can therefore be restored, at a cost that is no longer the cost of the moment.

And too short a loop has a flaw of its own: it teaches the local gesture without ever exposing you to the system effects that only appear at scale.

Open questions

• What is the maximum delay between a technical decision and its first observable consequence that still keeps the loop instructive?