A three-second interruption is enough to double your mistakes.
Not a meeting. Not a long Slack thread. Three seconds. Roughly the time it takes to glance at a notification and decide it can wait.
If you've ever come back from "just checking something" and stared at your own half-written function like it belonged to a stranger, this is for you.
The study that measured a blink
In 2014, Erik Altmann and David Hambrick at Michigan State University, with Greg Trafton at the U.S. Naval Research Laboratory, published a paper with a title that reads like a developer's diary: Momentary interruptions can derail the train of thought (Journal of Experimental Psychology: General).
About 300 people worked through a procedure on a computer. Each step had its own small rule, and the steps had to be done in order. Think of it as a checklist your head has to hold: step four, then five, then six.
Every so often, the program stopped them and asked them to type two letters. That's it. The interruptions averaged 2.8 seconds, about as long as one step of the task itself.
Afterwards, people were twice as likely to lose their place in the sequence. In a version with slightly longer breaks, around 4.4 seconds, sequence errors tripled.
Here's the part I find most interesting. The errors didn't show up everywhere. People still did each individual step correctly. What broke was knowing which step came next. Altmann said he was surprised such short breaks had such a large effect (EurekAlert summary).
The authors' explanation is about how working memory moves forward. While a step is in focus, activation spreads to the next one, quietly priming it. Pull your focus away, even briefly, and that flow gets cut off. The next step starts to fade. You come back, and the thread you were following is just gone.
Sound familiar? That's debugging. You're holding a call chain in your head: this handler calls that service, which reads this config, which is null because... and then a toast pops up in the corner.
Your brain doesn't fully leave the last task
So the interrupted task suffers. But what about the thing you switched to?
Sophie Leroy, then at the University of Minnesota, studied exactly that. In a 2009 paper in Organizational Behavior and Human Decision Processes, she gave it a name: attention residue.
Across two experiments, people who left a task unfinished kept thinking about it, and they did worse on the next task. Part of their attention stayed behind.
The twist is that simply finishing the first task wasn't enough to clear it. What helped was finishing it under some time pressure, which seemed to give people a clean break.
Developers live in this. You get pulled from a gnarly refactor into a code review. You approve the PR, but half your brain was still renaming variables in the other branch. The review is worse, and the refactor didn't move either.
What programmers actually do when they come back
Chris Parnin and Spencer Rugaber at Georgia Tech went looking for real numbers. They analyzed about 10,000 recorded programming sessions from 86 developers, plus a survey of 414 programmers, and published it as Resumption strategies for interrupted programming tasks (Software Quality Journal, 2011).
Only about 10% of sessions had someone editing code within a minute of coming back. And in only 7% did they start editing without first navigating around to other files or methods.
In other words, almost nobody sits down and picks up where they left off. They wander the codebase first, rebuilding the mental model they had a moment ago. Parnin's survey found developers lean on cues to do this: leaving the last file open, a highlighted line, notes, even a deliberate compile error as a bookmark.
A small catch: it doesn't always feel slower
One honest complication. In a 2008 study at UC Irvine, Gloria Mark, Daniela Gudith and Ulrich Klocke interrupted people while they answered emails (The Cost of Interrupted Work, CHI 2008).
The interrupted people actually finished faster, with no drop in quality on that task. But they wrote shorter emails and reported more stress, frustration, time pressure and effort.
So the cost isn't always visible on the clock. Sometimes you just pay it in tension. And email isn't a 40-step call chain. The Altmann result suggests sequence-heavy work, which is most of programming, is where the damage concentrates.
(You'll also see a "23 minutes to refocus" number floating around online. I couldn't trace it to the CHI paper above, so I'm leaving it out.)
The fix is almost embarrassingly small
In 2018, Leroy and Theresa Glomb tested a simple intervention in Organization Science. They called it a "ready-to-resume" plan.
When you get interrupted, take a minute and jot down where you were, what's left, and what you'll do next. That's the whole thing.
Across four studies, people who did this showed less attention residue and performed better on the interrupting task. In the lab versions, they reviewed résumés as if hiring, and the plan-makers made better decisions and recalled more of what they'd read (UW News). Leroy described it as giving the brain "temporary closure" so it can actually switch.
To be fair to the research: those studies measured performance on the new task, not on returning to the old one. Leroy said the plan likely helps there too, but that hadn't been tested yet.
What to try today
Next time someone taps you on the shoulder mid-bug, don't just swivel. Give it thirty seconds.
Write a one-line note in the file, or in a scratch buffer, like:
// was checking why userId is null in AuthService.refresh(). Next: log token payload before decode.
That's a ready-to-resume plan. It also happens to be the exact kind of cue Parnin's developers used to rebuild context.
A few other things that line up with the research:
- Batch the tiny stuff. If three-second breaks matter, notifications during deep work are not harmless.
- Finish a chunk before switching, and give yourself a small deadline to do it. That's Leroy's 2009 finding in practice.
- When you come back, read your note first. Then the code.
Where I use this outside code
I build a small app called Recl, and it came from a similar problem: I'd save talks and articles mid-task, then lose the thread on them completely. Recl turns what you save into a short summary with key takeaways and later brings it back as a question, so picking the idea back up doesn't start from zero. You can browse some example saves in the public library.
But the cheapest version is a single comment line before you look away.
Your train of thought is fragile. Leave yourself a ticket back.
I'm Asutosh. I write about how memory and learning work, and I build Recl, a tool for remembering what you watch and read.
Top comments (0)