On slowing down to go further

For most of my first decade writing software, I measured days by commits. A day with many was a good day; a day with none felt borrowed. It took me an embarrassingly long time to notice that my best work — the designs that outlived three rewrites of everything around them — almost never came from one of those days.

Speed is a local maximum

Typing fast is a local optimum. The interface I'm designing, the failure mode I'm ignoring, the abstraction I'm about to inflict on a team I'll no longer be on — none of that rewards velocity. Slowing down is not working less; it's moving the effort from production to judgement.

The uncomfortable arithmetic: an hour of thinking before writing usually saves three hours of rewriting, but only the writing shows up in the sprint board. So teams optimise the visible half and wonder why rework eats the calendar.

Urgency is the enemy of judgement, and judgement is the job.

What sustainable pace looked like in practice

Three habits survived contact with reality. First, one deep block a day, defended like a production incident. Second, writing the design doc before the ticket, because the doc is where the bad ideas are cheap. Third, a hard rule that I never ship anything I couldn't explain to the person maintaining it in two years — usually me, on a bad day.

None of this is heroic. That's the point. Careers are long; systems are long; the person who is still here, still curious, and still trusted in year fifteen is the one who refused to spend their judgement to buy speed they didn't need.