The expensive part is in working memory
Chasing a bug means holding several things at once: the call path, the suspect variables, the hypotheses you have already eliminated, the next thing to check. None of that is in a file. It is in working memory.
An interruption clears it. The code is still there when you return, but the model of it has to be rebuilt. Developers are not unusually sensitive to interruption; the recovery cost is genuinely higher for this kind of work.
This is also why 25 minutes often feels wrong for programming. It can take ten minutes to load the problem back in, and the alarm arrives shortly after you get there.
Different tasks, different lengths
Engineering work is not uniform, so there is no reason to run the whole day at one interval.
- Designing a feature or chasing a hard bug: 50 to 90 minutes, and cap it at two or three a day.
- Code review: 25 to 30 minutes. Quality drops noticeably in the back half of a long review.
- Refactoring and writing tests: 25 minutes. The work is already divided into small units.
- Waiting on a build or CI: not a session. Starting something new in that gap ruins both.
- During an incident: do not apply the technique at all. The rhythm is set externally.
Leave yourself a way back in
When interruption is unavoidable, you can still cut the cost of returning. The cheapest insurance is thirty seconds before you stand up.
Write one line about what you were checking and what you meant to look at next. A comment, a note, either is fine. Leaving a deliberately failing test, or stopping mid-expression so the file will not compile, works on the same principle: the screen tells you where to resume.
That single line routinely turns a fifteen-minute recovery into a two-minute one.
Sound and notification settings
Lyrics compete with code. Reading and writing code is itself a language task, so words in your ears interfere more than most people expect. Instrumental music, or an information-free sound like brown noise, is the safer default.
Sort notifications by whether they demand immediate action. Keep sound for incidents and turn off everything else, badges included. A small number in the corner of the screen keeps pulling attention back.
What teams can do
Individual effort only goes so far. A few shared agreements make this dramatically easier: a no-meeting morning, an explicit split between questions that need an answer now and questions that can be asynchronous, and meetings clustered onto particular days.
These protect individual focus and raise team throughput at the same time. Reducing interruption is not a courtesy; it is a throughput decision.