The first sign, for me, is that I check Slack more often. Not a big jump, just slowly creeping up. Reading the same thread twice. Switching tabs to nothing in particular. By the time I notice, I have usually been doing the same kind of work for too long.
The thing is, I do not really run out of time on a project. I run out of energy for the specific kind of work the project needs at that moment. Three days of heads-down coding and I stop seeing the architecture. A week of project planning calls and discovery work and I just want to build something. Two days of reading other people’s code and I need to write my own.
The fix, more often than not, is a different kind of work. Not a break.
Two times this actually changed an outcome
Permalink to “Two times this actually changed an outcome”The first one is from a nine-day latency incident I wrote about separately, where the bug turned out to be in our vector-database vendor’s client. The part I left out of that post is that I did not actually work on it eight hours a day for nine days. After day 3, when I had run out of useful things to try and was stuck waiting on the vendor’s account team, I deliberately switched to other sprint work for half-day stretches.
What that bought me was not a new idea about the bug. It was the energy to keep pushing on the social side of it. Another round with the account team and the escalation finally got the main engineer onto a call. If I had been grinding on the technical problem the whole time I would not have had it in me to also go fight the org chart. Switching kinds of work let me come back to the political part fresh.
The second one is more recent. I had a sprint where the stated goal was a hard time target on a test-fixture optimisation. Most of the wins were falling to me by default, not because I love perf work but because I happened to spot the biggest issues. By the middle of the sprint I noticed the work was getting smaller in a bad way. My mood was off, curiosity was low, fixes were getting marginal. We were maybe 2% off the target.
Instead of grinding harder, I let the perf work coast on the existing pipeline and shifted part of my time to logging latencies in the same codebase, something adjacent that had been bothering me anyway. That investigation eventually turned into the PII-aware structlog work, which was a shippable piece of infrastructure the team needed independently. Net delivery for the sprint actually went up, even though I did not quite hit the original time target.
That is the throughput argument in one example. Pushing harder on the assigned work would have produced fewer marginal milliseconds. Switching produced a separate artifact the team kept using.
The kinds of work I actually rotate between
Permalink to “The kinds of work I actually rotate between”Most posts on this topic list four things: coding, planning, reviewing, docs. That list is too clean to be useful, at least for me. Mine, looking at a real month:
- coding
- exploring (reading our own codebase, reading prior work on the web, dumping notes into a personal markdown file)
- thinking out loud with an AI agent about something half-formed
- building benchmarks
- building demos
- writing RFCs
- interviewing teammates about what is annoying them and where they think the wins are
- deep-diving into business context (what the customer is actually trying to do, why a feature exists, what the contract says)
Coding and exploring recharge each other most reliably for me. After two days of coding I cannot read another diff, but I can spend a morning on a discovery loop and come back to coding actually wanting to write again. After a week of exploring and dumping notes, the urge to build something is what gets me back to the keyboard.
Demos and RFCs are different. They consume the same kind of energy as coding, just spent differently. They do not recharge it, they substitute for it. Useful to know, because slotting a demo right after a long coding stretch does not help me the way a discovery day does.
What I had wrong about meetings
Permalink to “What I had wrong about meetings”I used to believe meeting-less days were when I did my best work. Block the calendar, no interruptions, four-hour blocks. That is true on a good day. On a long stretch it stops being true. By Wednesday of an all-coding week I am avoiding the work, not doing it.
One or two meetings on those days actually help. Not a calendar full of them, just a few. A 30-minute customer call or a teammate interview is a context switch I cannot give myself on my own. I come back to the code with something new in my head, which more often than not means I see the next move I had been missing.
Some weeks though, I cannot switch inside the work. The customer schedule is what it is, the sprint is what it is, the thing on fire is the thing on fire. On those weeks the switch has to happen outside of work. Sport, going somewhere with friends or my wife, anything that uses a different part of me for a few hours.
