In 2008, Joel Spolsky wrote something that stuck with the software industry for years. He described programmers as needing to hold an enormous number of things in their heads simultaneously, and argued that any interruption destroys that mental state entirely. His estimate was that it takes a full 15 minutes to get back into “the zone” after an interruption. That number became gospel.
The problem is, it’s probably too optimistic.
The Setup
A mid-sized software consultancy, the kind that runs three or four concurrent client projects at any given time, noticed something strange in their postmortem data. Projects were shipping late. Not catastrophically late, not “we missed a quarter” late, but consistently 20-30% over their original estimates. The team was experienced. The estimates were made by people who had delivered similar projects before. The planning wasn’t sloppy.
They started digging.
The technical lead, who I’ll call Marco because he asked to remain anonymous, initially assumed the issue was scope creep. That’s the default hypothesis. But when they mapped the actual work against the timeline, scope hadn’t grown significantly on the delayed projects. What had grown was the number of context switches per developer per day.
They were tracking this, loosely, through task management software. Developers were being pulled between tickets across different client projects, often switching contexts three or four times in a single afternoon. A bug fix for Client A, then a code review for Client B, then back to a feature for Client A, then a planning call for Client C.
What Happened
Marco’s team ran a retrospective exercise. They asked developers to describe, in writing, what they had been thinking about immediately before a significant context switch, then asked them to write down what they remembered thinking about when they returned to that task. The gap was the interesting part.
What they found wasn’t just “I forgot where I was.” That’s the version of context switching everyone talks about, the re-loading time, the hunting through code to find your place again. That’s the 15-minute tax. What they found was subtler and more damaging.
Developers weren’t returning to the same mental model they’d left. They were returning to a simplified version of it. The nuance they’d been holding, the “I was about to try this approach but I had a nagging feeling it wouldn’t handle the edge case where the user has two active sessions” kind of thinking, was gone. Not suppressed. Gone. And because they didn’t know they’d lost it, they didn’t go looking for it.
This is what makes context switching genuinely different from other productivity problems. When you lose time to a bad meeting, you know you lost it. When your mental model gets quietly overwritten, you don’t get a notification. You just proceed with a slightly worse version of your understanding and wonder later why the code you wrote that afternoon needed so much rework.
The bugs they started finding in delayed projects had a specific character. They weren’t simple mistakes or typos. They were architectural oversights, cases where someone had clearly understood a constraint at one point and then made a decision that ignored it. The code was coherent in isolation but wrong in context. Marco called this “context-correct, system-wrong” bugs, and once he had a name for it, he started seeing it everywhere.
Research in cognitive psychology supports this mechanism. Working memory (the active mental workspace where you hold and manipulate information in the short term) has both capacity and fidelity limits. When you context-switch, you’re not just evicting data from working memory. You’re interrupting the consolidation process that moves nuanced understanding into a more stable form. The technical term is “proactive interference,” where new task demands degrade the retrievability of prior task representations. The 15-minute re-loading time measures how long it takes to feel oriented. It doesn’t measure how much of the original model you actually recover.
Why It Matters
This distinction matters a lot for how teams think about interruption cost. Most productivity frameworks treat context switching as a throughput problem. You lose X minutes per switch, multiply by Y switches per day, and you’ve calculated your lost developer-hours. That framing leads to reasonable interventions: batch your meetings, use async communication, protect focus blocks.
Those interventions help. But they’re solving for the wrong thing if the primary damage isn’t time loss, it’s model corruption. The cost of context switching isn’t just about stolen hours. You can give back the time and still end up shipping worse software, because the developer who returned to the task isn’t holding the same understanding as the one who left it.
Marco’s team found a practical approximation of this when they looked at code review rejection rates by time of day. Code written in the morning, in longer uninterrupted sessions, got rejected in review about half as often as code written in fragmented afternoon sessions. Same developers. Same types of tasks. The afternoon code wasn’t obviously worse when you looked at it in isolation. It was worse because it made assumptions that were locally reasonable but globally inconsistent with decisions made earlier.
What We Can Learn
The consultancy made three changes, and one of them was the surprising one.
First, they did the obvious thing: they restructured scheduling to give developers longer uninterrupted blocks and batched cross-project context switches to specific days rather than scattering them through the week. Standard stuff.
Second, they started requiring developers to write a “context note” before leaving a task mid-stream. Not a status update for the project manager. A note for their future self: what were you about to try, what were you unsure about, what edge cases were you holding in mind. This sounds like overhead, and for small interruptions it is. For anything longer than a couple hours, developers reported it was worth it. Coming back to a task with your own explicit model written down is meaningfully different from trying to reconstruct it from code alone.
Third, and this is the surprising one, they changed what they counted in retrospectives. They stopped treating context switches purely as a scheduling problem and started treating them as a quality risk. Before a developer was pulled off a task, someone would ask: “Is this task at a safe stopping point?” Safe didn’t mean finished. It meant the developer had reached a stable conceptual checkpoint, a place where the mental model they’d built was complete enough to be written down and recovered from.
This reframe had cultural weight. It changed the conversation from “can you just quickly jump on this” to “is this the right moment to switch.” The quick-jump request implies the switch is costless. The checkpoint question implies there’s something worth protecting.
Notifications compound this, because they don’t just interrupt tasks, they interrupt the specific micro-process of consolidation. The case for aggressive notification reduction becomes much stronger once you understand that the damage isn’t just distraction, it’s memory interference happening at exactly the wrong moment.
The deeper lesson from Marco’s team isn’t a workflow hack. It’s an epistemological one. You can’t introspect your way to knowing what you’ve forgotten. The mental model you had before the interruption doesn’t leave a ghost behind to tell you it’s gone. You return to a task feeling oriented, feeling like you remember what you were doing, and you’re right about the surface and wrong about the depth. The code compiles. The tests pass. The thing you were worried about, the thing you were just about to think through carefully, never gets thought through at all.
Building software is an act of sustained, fragile reasoning. Protecting it requires treating the reasoning itself as the artifact worth protecting, not just the time it takes.
