I ran a strict Pomodoro experiment on myself from June through November last year. Every work session logged. Every interruption noted. Every task categorized as deep work or shallow work. After 782 tracked sessions, the data told me things I didn't expect, and the biggest lesson had nothing to do with the timer itself.
The Original Technique
Francesco Cirillo developed the Pomodoro Technique in the late 1980s as a university student. He used a tomato-shaped kitchen timer (pomodoro is Italian for tomato) and committed to 25 minutes of focused work followed by a 5-minute break. After four sessions, you take a longer break of 15 to 30 minutes.
The 25-minute interval wasn't based on neuroscience research. Cirillo picked it because it was short enough to feel manageable but long enough to make meaningful progress on a task. The real innovation wasn't the duration. It was the act of committing to a defined block and treating interruptions as something to actively resist rather than accept.
What Six Months of Data Showed
I categorized every session by task type: coding (deep work), code review, email and Slack, meetings prep, documentation, and debugging. Here's what the numbers looked like across 782 sessions.
Completion rate varied wildly by task type. Coding sessions had a 73% completion rate, meaning I worked the full 25 minutes without breaking focus. Email and Slack sessions hit 91%, which makes sense because those tasks are inherently broken into small chunks. Debugging had the lowest completion rate at 58%. I'd hit a wall or a breakthrough before the timer went off and either gave up or kept going past the buzzer.
My most productive hours were 9:30 to 11:30 AM and 2:00 to 4:00 PM. The hour after lunch (12:30 to 1:30) was consistently the worst. Not just fewer completed sessions, but lower quality output when I reviewed the work later. I eventually stopped scheduling deep work in that slot entirely.
The average number of completed sessions per day was 9.2, translating to about 3 hours and 50 minutes of focused work. That surprised me because I was "working" 8 to 9 hours a day. More than half my workday was transitions, context switching, and ambient busyness that feels productive but doesn't move anything forward.
25 Minutes Isn't Universal
The most useful finding was that different tasks have different optimal session lengths, and forcing everything into 25 minutes hurt my output on certain work.
For coding, 25 minutes was often too short. It takes time to load a problem into working memory and start making progress. I'd hit the timer just as I was getting into flow. When I switched to 50-minute blocks for coding, my completion rate on meaningful pull requests went up. I was finishing features in one session instead of spreading them across three.
For email triage and code review, 25 minutes was too long. I'd finish in 12 to 15 minutes and fill the rest with low-value browsing. Switching to 15-minute blocks for shallow tasks eliminated that dead time.
For documentation, 25 minutes was about right. Long enough to write a coherent section, short enough to avoid over-editing.
The Context Switching Tax
Gloria Mark's research at UC Irvine found it takes an average of 23 minutes to fully return to a task after an interruption. My data supported this.
When I logged interruptions (a Slack message I responded to, someone stopping by, checking my phone), the sessions after those interruptions took longer to produce the same output. I started tracking "first productive minute," meaning how long into the session before I was actually doing the task rather than re-orienting. After an interruption, that number averaged about 8 minutes. Without a prior interruption, it was 2 to 3 minutes.
This is why protecting the session matters more than the specific duration. When I treated the timer as permission to ignore Slack, my output per session improved measurably.
The DeskTime 52/17 Alternative
A study from DeskTime, a time-tracking company, analyzed their most productive users and found they worked in roughly 52-minute blocks followed by 17-minute breaks. The 52/17 pattern comes up frequently in productivity discussions as an alternative to Pomodoro.
I tried it for three weeks. For deep coding work, it was better than 25/5. But for a mixed workday with meetings and shallow tasks, the 52-minute commitment was too rigid. I'd have a 30-minute gap between meetings and couldn't fit a session in.
What I settled on was flexible Pomodoro: 50-minute blocks for deep coding, 25-minute blocks for documentation, and 15-minute blocks for email and review.
The Planning Fallacy
One pattern in my data that I didn't anticipate: I consistently underestimated how many sessions a task would take. I'd estimate 3 sessions for a feature and it would take 6. I'd estimate 2 for a bug fix and it would take 4.
Over six months, my estimates were low by an average factor of 1.8. This is the planning fallacy that Daniel Kahneman documented, and seeing it in my own data was more convincing than reading about it in a book. I started multiplying my estimates by 2 and my predictions became much more accurate.
The Tool and the Takeaway
I use a Pomodoro timer I built at zovo.one. It handles the timing, tracks sessions, and lets me categorize work types, which was essential for the kind of analysis I described above.
But the timer is the least interesting part of this experiment. The tracking changed how I work. If you're going to try Pomodoro, log what you work on, how many sessions it takes, and when you break focus. After a month, you'll have data about your own productivity that no article can give you.
I'm Michael Lip. I build free developer tools at zovo.one. 350+ tools, all private, all free.
Top comments (0)