There is a particular kind of burnout that looks like productivity. You are shipping, you are responsive, your calendar is full, and somewhere along the way the only thing you think about became the thing you are paid to think about.
I have been there, and I did not notice from the inside. What I noticed was that my work had got narrower — competent, faster than before, and reaching for the same four solutions.
The pattern
The engineers whose judgement I trust most all have something with three properties:
- It is not a side project that could plausibly become a startup
- It has an ending — a match, a meal, a roll of film
- They are visibly, cheerfully mediocre at it
That third property does more work than it sounds like. Being a beginner at something on purpose keeps you honest about what it feels like to be the least experienced person in the room. I run architecture reviews for a living; the ability to remember what not-knowing feels like is directly load-bearing for that job.
The second property matters too. Software is never finished — there is always another refactor, another edge case, another thing you could improve. A hobby with a hard stop gives you the experience of completion, which is otherwise scarce in this line of work.
Saturday
Cricket starts too early, lasts too long, and I am not good at it.
What it is, though, is a game of long-running state. A decision in the twelfth over gets answered in the thirty-eighth. You set a field for something that might happen twice. You make a bowling change based on a read that takes an hour to confirm or refute, and you have to hold the shape of the whole game in your head while paying attention to the current ball.
I have never found a better rehearsal for arguing about a caching strategy, or for the specific discomfort of committing to an architectural decision whose consequences arrive in the third year. It also has the property that no amount of theory substitutes for having stood there — which is a useful thing to be reminded of by an activity that does not involve a keyboard.
Sunday
The kitchen is the one system where I skip the design document entirely.
No plan, no review gate, no rollback strategy. If it fails we order something. That freedom is unavailable anywhere else in my week — everything I do professionally has a change-control process attached, appropriately — and I have come to think of it as load-bearing rather than recreational. Andhra food, mostly, with whatever Ontario grocery stores will give me, which is its own constraint-satisfaction problem.
The other thing cooking gives you is immediate feedback from reality. You are wrong in twenty minutes and you know it. Most of my professional decisions take quarters to be evaluated. Recalibrating on a shorter loop occasionally is good for the instincts.
The argument, stated properly
This is not a wellness post, and I want to be clear about that because the wellness framing is easy to dismiss and also not what I mean.
The claim is about quality of work. The instinct that tells you a design is wrong before you can articulate why is assembled out of everything you have ever paid attention to — patterns from other domains, analogies, a sense of how systems fail generally rather than how software fails specifically. Narrow the inputs and you narrow the instinct.
The engineers I have worked with who consistently saw around corners were not the ones who had read the most engineering blogs. They were the ones with an unusual second thing — music, woodworking, competitive chess, long-distance running, a language they were learning badly — and who could reach for a structural analogy from somewhere outside the field.
There is a supporting observation about the mechanics of thought that I trust from experience even though I cannot cite it precisely: most of my architecture problems have solved themselves while I was doing something else. None of them have ever solved themselves while I stared at them. Whatever the underlying process is, it appears to require that you stop.
The counter-argument I take seriously
Not everyone has the room. A hobby requiring weekend hours and disposable income is a privilege, and telling someone with young children and a long commute that they need a hobby to be a better engineer is both unhelpful and slightly obnoxious.
So the narrower version of the claim, which I think survives: the inputs matter, and work is not sufficient input. If the hobby is available, take it seriously. If it is not, the substitute is a deliberate interest in domains adjacent to your own — reading about how other industries fail, talking to people whose constraints are unlike yours. Cheaper, and it does much of the same work.
What does not substitute is more of the same. Another framework, another conference talk, another optimisation of the thing you already do well. That is depth, and depth is table stakes. The judgement comes from somewhere else.