Everyone knows meetings break up the day. What is easy to miss is how long the recovery takes after every interruption, and how much of an engineer's week that recovery quietly eats. There is a decent body of research on this, so instead of guessing, here is what the studies actually found, why programming is unusually sensitive to it, and the handful of changes that help.
The 60-second version
- After an interruption, workers take about 23 minutes to return to the original task (Gloria Mark, UC Irvine).
- Programmers specifically take 10 to 15 minutes to start editing code again, and resume in under a minute only 10% of the time when interrupted mid-edit (Chris Parnin).
- The cost is rebuilding a mental model, which the DevEx research frames as flow state and cognitive load.
- Status-checking counts too: refreshing a pipeline or hunting for an MR link is a self-inflicted switch.
- Cutting it is mostly process: protect focus blocks, batch interruptions, and stop making people poll for status.
What the research actually measured
The number people quote most comes from Gloria Mark's team at UC Irvine. In The Cost of Interrupted Work: More Speed and Stress, they observed information workers and found that a worker took an average of 23 minutes and 15 seconds to return to a task after being interrupted. Worth being precise about what that measures: it is the time to get back to the original task, and in practice people were often pulled through a chain of other tasks before circling back, so the 23 minutes includes that detour. The same study found interrupted people tended to work faster to compensate, but reported more stress, higher frustration, and more effort. Speeding up was a coping response, not a productivity gain.
For programming specifically, the reference is Chris Parnin's Programmer, Interrupted, which drew on roughly 10,000 recorded programming sessions and a survey of 414 developers. The findings are blunt. A programmer takes 10 to 15 minutes to start editing code again after resuming from an interruption. When interrupted in the middle of editing a method, they resumed in under a minute only 10% of the time. And on a normal day, a developer is likely to get just one uninterrupted two-hour stretch. Parnin also notes the general research pattern that interrupted tasks can take about twice as long and carry about twice the errors.
Why engineers pay more than most jobs
The reason the recovery is so long for developers is what you have to hold in your head to write code at all. The call stack, which variables hold what, the branch you were tracing, the reason you were tracing it, the half-formed plan for the next three edits. None of that is written down. It lives in working memory, and an interruption dumps it. Resuming is not picking up where you left off; it is reconstructing the model from scratch, which is why Parnin's programmers navigated to several locations just to rebuild context before they could type anything useful.
This is the same idea the developer-experience research puts a frame around. DevEx: What Actually Drives Productivity, by DX with Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler, names three dimensions that drive how productive developers actually feel: feedback loops, cognitive load, and flow state. It defines flow state as the ability to focus deeply without interruptions. Context switching hits two of the three at once. It breaks flow directly, and it raises cognitive load because you now have to reload everything you were holding. A workday chopped into 40-minute fragments never lets either recover.
The switches you do not count
Meetings and taps on the shoulder are the obvious interruptions. The sneaky ones are the micro-switches you inflict on yourself, and for engineers a lot of them are status checks. Refreshing a pipeline to see whether CI went green. Flipping to GitLab to check if your merge request got reviewed yet. Digging back through Slack scrollback for the MR link someone pasted this morning. Each one feels free, a few seconds of attention. The cost is not the glance; it is that the glance pulls you out, and the reload afterward is the same 10 to 15 minutes whether the interruption was a meeting or your own tab.
Polling a system for a status that has not changed yet is the purest form of this. You check, nothing has happened, you switch back, and you have paid the reload tax for zero information. Any status you have to go and pull is a switch waiting to happen; a status that gets pushed to you when it changes is not.
Where we sit in this: we build PRFlow, which posts each GitLab merge request to Slack as one message that updates in place with CI/CD status and review comments. The point, for this topic, is that it removes one category of self-inflicted switch: you stop refreshing GitLab to see whether the pipeline passed or the review landed, because the message changes when the state does. It will not fix your meeting calendar. It does take a common polling habit off the table. If your team lives in pasted links, the sharing merge requests workflow is the closest fit.
How to cut the cost of context switching
None of these are exotic. They are the boring levers that actually move the number.
- Protect real focus blocks. A two-hour uninterrupted stretch is roughly what a developer gets in a good day, per Parnin, so treat it as scarce. No-meeting mornings and a culture where a closed door or a status dot is respected buy back the one thing the research says matters most.
- Batch interruptions instead of scattering them. Async by default, questions collected and answered at set times, and a norm that most things can wait an hour. Five questions at 2pm cost one reload; five questions across the afternoon cost five.
- Stop making people poll for status. If engineers are refreshing pipelines or checking whether an MR moved, that is a switch you can design away by pushing the status to them when it changes.
- Keep reviews small and fast. A review that sits for two days has to be reloaded by a reviewer who has forgotten it and an author who has moved on. Smaller changes and quicker turnaround shrink how much context has to be rebuilt on both sides.
- Make the queue visible so nobody hunts. When the work waiting on someone is obvious, they are not switching in and out of a tool to go looking for it. A visible queue is also how review stops becoming the bottleneck on everything the team ships.
Bottom line
The cost of context switching is real, it is measured in tens of minutes per interruption, and almost none of it shows up on a dashboard. You cannot delete interruptions, but you can stop manufacturing them: guard the deep-work blocks, batch the questions, and remove the status checks people do by hand. Start by counting how often your engineers flip to GitLab just to see whether something changed. That number is usually higher than anyone expects, and it is the easiest one to bring down.