Pomodoro for developers: a setup that survives deep work
The standard advice fails at a keyboard for two specific reasons: twenty-five minutes is roughly the length of the part where you are still loading the problem, and the waits that programming is full of are not distractions but the timer treats them as one.
Why 25 minutes cuts in the wrong place
Programming has a loading phase. Before you can change anything you have to get the relevant parts of the system into your head at once: which function calls which, what that variable holds by the time it reaches here, why the previous person did the strange thing. That phase does not produce output. It produces the state you need in order to produce output.
Twenty-five minutes tends to end somewhere inside it. You get the ring at the moment you have just assembled the picture, and you have a choice between ignoring the timer (which teaches you to ignore the timer) or spending five minutes losing the thing you spent twenty assembling.
The original technique is stricter about this than most people realise: an interrupted pomodoro is not shortened, it is discarded entirely. It also says any activity you estimate at more than five to seven pomodoros should be broken into smaller ones. Both rules are in the original paper, and both point the same way for this kind of work: make the unit fit the task rather than making the task fit the unit.
Pick a length from the shape of the work
Not from a preference. Different programming days have different shapes, and the length should follow.
- 50 minutes, 10 off. The default for most implementation work. Long enough to load a problem and act on it, short enough that a wasted one is not a wasted afternoon.
- 90 minutes, 20 off. For the ones that need everything held at once: tracking a bug across three services, a migration, a refactor with no safe halfway point. The cost is real; a 90-minute block that goes wrong takes the morning with it.
- 25 minutes, 5 off. Genuinely good for the other half of the job. Code review, replying to a stack of comments, chasing flaky tests, writing the commit messages you skipped. Discrete tasks, no loading phase.
- 15 minutes, 3 off. For starting when you do not want to. Fifteen minutes is short enough to agree to, and the point is not the fifteen minutes.
Those four are the presets we ship, and the 90-minute one is named after the ultradian rhythm idea. Worth being straight about that: the notion that waking attention runs in roughly 90-minute cycles is a popular explanation with much weaker evidence behind it than productivity writing implies. Use 90 minutes because it fits a hard problem, not because a biological clock says so.
A build you are waiting on is not a distraction
This is the thing generic Pomodoro advice has no answer for. Compiles, test suites, container rebuilds, CI, a slow query, a deploy: programming has enforced waits that are part of the work rather than an escape from it. Advice written for writing prose simply does not have this problem.
The important thing about a wait is that it is not free time, it is held time. You are still carrying the state. Whatever you do during it either preserves that state or destroys it, and the cost is not the seconds you spend. It is what you have to rebuild afterwards.
The ten-second rule for what to do during a wait
There is an old and useful set of thresholds for this. Jakob Nielsen's response-time limits, from Usability Engineering and drawing on work by Miller in 1968 and Card and colleagues in 1991:
- 0.1 second. Feels instantaneous.
- 1.0 second. “The limit for the user's flow of thought to stay uninterrupted”, though the delay is noticed.
- 10 seconds. “The limit for keeping the user's attention focused on the dialogue”. Past this, attention goes somewhere else.
Those numbers were written about user interfaces, but your build is a user interface and you are the user. Read as advice for waits:
- Under ten seconds: do not switch. Watch it. It feels like waste and it is not: you are holding state that costs far more than ten seconds to rebuild.
- Ten seconds to about two minutes: switch within the problem. Reread the function you are about to change, write the next test name, work out what a failure would mean. Not the chat window. This is exactly the case Leroy's attention-residue work covers: leaving something open and going elsewhere is more expensive than the switch itself, and a half-finished thought is as open as it gets.
- Longer than that: stop pretending you will not switch, and choose the switch in advance. Make the build tell you it is done rather than watching for it: a desktop notification hooked to the end of the command, a sound, anything that means you are not the polling loop. Then go and do a decided thing, not the first thing.
Where inactivity detection gets developers wrong
Now the part where our own product needs a warning label, because this specific failure hits programmers harder than anyone.
The Focus Valley desktop app decides whether you are working by asking the operating system one number: seconds since your last keypress or mouse move. Past sixty, it concludes you have gone, and stops counting.
That number cannot tell the difference between an empty chair and a person reading. Twenty minutes spent reading a long diff, staring at a stack trace, or thinking with your hands off the keyboard is thinking, and to the system it is indistinguishable from lunch. The timer will pause on you mid-thought.
There are only two honest answers, and you should pick one deliberately:
- Turn activity detection off in Preferences for reading- and thinking-heavy sessions. The timer then runs like any other timer, and the number it gives you goes back to being elapsed time, which for that kind of session is arguably the right measurement anyway.
- Leave it on and accept that thinking is not counted. Your total becomes a record of hands-on-keyboard time specifically. That is a legitimate thing to measure, as long as you know that is what you are looking at.
What we will not do is claim the app knows the difference. It reads one integer, and how it works says exactly which one.
Where the timer goes
Two failure modes, opposite directions. A timer in a browser tab is behind your editor within thirty seconds and you never see it again, and a tab also cannot see anything happening outside itself, so its record of your session is elapsed time and nothing more. A timer that pops over your work interrupts the thing it was bought to protect.
The arrangement that survives: a small always-on-top window in a corner you are not using, or on a second screen if you have one; the end-of-session alert allowed to be loud and full-screen, since it is meant to be obeyed; and every other notification silenced. The alert is only worth having if it is not competing with six others.
If you live in a terminal, put the session boundary in the shell rather than the mouse. A one-line alias that starts the session and opens the file you are working on costs nothing and removes the moment where you decide whether to start.
How to stop mid-problem without losing it
The break only works if you can come back. Thirty seconds before you stand up, write down three things: what you were doing, what you had just found out, and the exact next action. In a scratch file, or a comment you will delete, anywhere.
This is the cheapest thing in this article and the one most worth doing. An open loop you have not written down keeps running in the background and quietly taxes whatever comes next; a specific written plan is what stops it. Without the note, the first ten minutes after the break are spent rebuilding state you already had.
Corollary, and it is counterintuitive: the worst moment to take a break is the moment you get stuck, which is precisely when you will want one. Finish the thought, or write it down. Then go.
The setup, in full
- 50/10 for implementation, 90/20 for problems that need everything loaded, 25/5 for review and small tasks, 15/3 for starting.
- One sentence before each session about what will be different when it ends.
- Notifications off, chat away, phone out of reach. Only the session alert is allowed to be loud.
- Waits under ten seconds: watch them. Under two minutes: stay inside the problem. Longer: make the build notify you, and choose the switch in advance.
- Decide, on purpose, whether inactivity detection is on. Reading is invisible to it.
- Three lines of notes before every break.
- Never break at the moment you get stuck.
None of this needs our software. The free web timer is here if you want somewhere to start, the desktop app is what adds the part a browser tab cannot do, and five other apps are compared honestly if this one does not fit.