The week I finally changed my default, I was writing a database migration for one of my own Android apps. Nothing glamorous: a new column, a backfill, and a set of instrumented tests to prove that old data survived the upgrade. The tests ran on an emulator and took about nine minutes from build to result.
I was running 25-minute blocks out of habit. Every block went the same way. Five minutes to get the emulator up, the right branch checked out, and my head back around the schema. Nine minutes of waiting for the run. Five minutes reading the failure and working out what it meant. Then, with six minutes left, I would have an idea for the fix, make it, and hear the ring before I could run the tests again. Break. Come back. Five minutes of setup, and the idea I had been so sure of now needed reconstructing from a half-written comment.
The slightly embarrassing part is that I build a Pomodoro timer app, and I was sitting there ignoring my own ring and feeling vaguely guilty about it. That guilt was the useful signal. The timer was not keeping me honest. It was cutting the work at the one moment it had started to make sense.
It was cutting the work at the one moment it had started to make sense.
I switched to 50-minute blocks for that job. Each one held two full test loops instead of one and a bit. The migration was done in three blocks that I had been failing to finish in seven.
Why 25 minutes exists in the first place
It is worth being fair to the classic interval, because it is short for a good reason. Francesco Cirillo developed the Pomodoro Technique in the late 1980s, named after a tomato-shaped kitchen timer, and the shape is 25 minutes of work, a short break, and a longer break after four rounds. The short length makes starting easy. Almost nobody can refuse 25 minutes, which is exactly why it works on the days you least want to work.
But the 25 is not the clever part. The clever parts are the boundary, naming one task before you begin, and the enforced break at the end. None of those require the number to stay at 25. If you have inherited it as a rule rather than a starting point, some of your work is probably paying for the mismatch every day, and you may not notice because the log still looks tidy.
Five signs the timer is fighting the work
You spend the first eight to ten minutes of every block reopening files and remembering where you were.
The timer rings at the moment the problem finally makes sense.
Each break destroys a mental model you need for the next step, so the break costs more than it restores.
You routinely ignore the ring to finish a coherent piece, then feel slightly dishonest about it.
Your block count goes up while your finished-things count stays flat.
One bad afternoon proves nothing. Look for the same sign across four or five blocks of the same kind of work. Coding, long-form writing, data analysis, and detailed design are the usual suspects, because all four ask you to hold a structure in your head before you can add anything to it. Email does not. That difference is the whole story.
Time your setup for three blocks
Intuition is bad at this, so I use arithmetic. For three blocks of the same kind of work, note how long it takes to get from "timer started" to "actually adding something". Opening the right files, reloading the failing test, rereading the paragraph above the one you are writing. Be honest. Say it comes out at eight minutes.
Eight minutes inside a 25-minute block is 32 percent of the block spent getting back to where you already were. The same eight minutes inside a 50-minute block is 16 percent. Nothing about your discipline changed. You just stopped paying the toll twice as often.
The working threshold I use: if setup and context recovery take more than about a third of the block, test a longer one. If setup is two minutes, the short block is fine, and lengthening it will not help. You will just get more time to drift.
Some work has a loop built into it, and the loop decides for you. My migration had a nine-minute test run. If one honest cycle of "run, read, change one thing" takes 20 minutes, a 25-minute block can only ever hold one cycle and a bit of setup. You will feel the timer as an interruption every single time, because it is one. Size the block to hold two loops and the work stops fighting the clock.
Short blocks are still right for some work
None of this makes 25 minutes the beginner version. It is the correct tool when:
You are resisting the start and need the smallest credible commitment
The task is uncertain and you are running a probe, not building
The work is a bounded set of small actions: triage, admin, a review pass, replying to four people
The day is unreliable, so a 50-minute promise is fiction
Bug reproduction, first outlines, proofreading, and expense claims all fit comfortably in 25 minutes. The short boundary creates a bit of urgency without demanding deep context, which is exactly what those tasks need. I still use 25 for invoicing, because given 50 minutes I will start redesigning the invoice template.
Low-energy afternoons are another case for short blocks. A sharp 25 on a mechanical task usually beats a heroic 90 that drifts by minute 30. There is more on that in plan low-energy afternoons realistically. Interval length is an equipment choice, not a measure of how serious you are.
Lengthen by one step and keep everything else still
When the signs line up, go in one step, not three. Move from 25 to 40 or 50 and stay there for three to five comparable blocks before judging. Keep the break rules the same so you are testing one variable, not five.
After each block I write four things, which takes about thirty seconds:
How long setup took
Whether I reached a clean stopping point
Whether my attention drifted before the ring
How easy the next restart felt
That turns a preference into evidence. After a week it is usually obvious, and occasionally surprising. I expected longer blocks to help my writing as much as my code, and for first drafts they did not. Drafting in 25 minutes kept me from rereading. Editing, on the other hand, went much better at 50.
A longer block also needs a stronger perimeter than a short one. Fill the water glass first, close chat and email, have the files you need on screen before starting, and tell whoever is at home when you will surface. A 50-minute block placed in a nine-minute gap between meetings is not a 50-minute block. If the house is the problem, start with protecting focus at home.
Where you put it matters as much as how long it is. Long blocks belong in the hours when your energy and your household are both most reliable. The fragmented hours are for work that tolerates fragmentation. Pair the long blocks with batched shallow work before and after, not with chat open during them, which is the balance described in when batching tasks helps and when it hurts. The full shape of the day is in structure a remote workday.
Where longer stops helping
Longer is not automatically better, and 90 minutes is not more grown-up than 50. Past a certain point a long block becomes 45 minutes of work followed by 45 minutes of reading loosely related documentation while technically still on the clock. I have done this. It feels like research. It is mostly avoidance with tabs.
If you cannot hold one task for 40 minutes without inventing distractions, the answer is a shorter block and a better environment first, then test longer again.
Also watch for longer blocks becoming a way to skip breaks. That is fatigue piling up quietly, and it usually shows up as a bad decision around 16:00. A 50-minute block wants something like a ten-minute break, not five, and definitely not zero.
A rough map of 25, 50 and 90
25 with a 5-minute break fits triage, email batches, small edits, and anything where setup is trivial. It breaks badly on debugging, long prose edits, and refactors where the first fifteen minutes are orientation.
50 with a 10-minute break fits feature slices, code review with real commentary, design iterations, and anything with a test loop of five to fifteen minutes. This is where most of my development work lives now.
90 fits rare quiet days and work that punishes stopping: complex refactors, architecture drafts, a deep read of an unfamiliar codebase. It fails when the household, the calendar, or your own hydration fragments the hour anyway. If you want the case for protecting one long stretch a day, deep work for developers makes it well.
For client work, where a block also has to produce something a client can review, choosing focus length for client work attaches these lengths to deliverables and dates.
What survives any length
Whatever number you land on, keep the three things that made the method work: one named task per block, a real break at the end, and a written next action before you stand up. Those survive every change of interval.
And stop comparing block counts across lengths as if they were the same unit. Four 50-minute blocks and eight 25-minute blocks are not comparable scores, and neither of them is the thing you were trying to measure. My migration took seven short blocks to fail and three long ones to finish. The number that mattered was one: the migration shipped. Count what finished, and let the timer serve the loop. When the loop outgrows the timer, change the timer.
End of this piece
Writer
PrimedEcho
Independent notes on remote work, focus, and freelance practice. About this site.
