Introduction
Does this sound familiar? You're in the middle of a complex task, you've just grasped a crucial thought — and then the phone rings. After the call you stare at the screen and wonder: "Where was I again?" As a developer, I experience this almost daily, and it's one of the most frustrating aspects of my work. In this article I explain why interruptions are particularly devastating for software developers — and how you, as a client, colleague or manager, can help protect productivity.
The Invisible Mental Architecture
While I'm programming, I build a complex mental model in my head. Imagine a multi-storey building made entirely of thoughts:
- Ground floor: The current function I'm working on
- First floor: Which data flows where
- Second floor: How this function relates to other parts of the system
- Third floor: Which edge cases and potential errors exist
- Top floor: The overarching solution path and next steps
This mental architecture is completely invisible. It exists only in my working memory — and it is extremely fragile.
An interruption is like an earthquake for this mental architecture. It collapses, and I have to rebuild it from scratch.
Why Developers Are Particularly Affected
Of course, other knowledge workers need concentration too. Lawyers, architects, doctors — everyone benefits from uninterrupted working time. But programming has one particular characteristic that sets it apart from other activities:
1. The Entire State Is Invisible and Transient
An architect has plans on the table. A doctor has the patient's notes in front of them. A tradesperson can see where the last nail was hammered in. A developer has... nothing visible. Everything exists only in the mind.
2. High Cognitive Complexity
Programming requires simultaneously juggling many abstract concepts. It's less like writing a text and more like solving a three-dimensional chess problem — while adapting the rules of the game at the same time.
3. Deep Contextual Dependency
Every code project has its own "world" — its own conventions, structures, dependencies. You need to have this world entirely in your head to work productively. After an interruption, you first have to "log back in" to that world.
What the Research Says
The negative effects of interruptions on knowledge workers are well documented scientifically:
- Gloria Mark (UC Irvine) found that knowledge workers need an average of 23 minutes to return to their original task after an interruption.
- Chris Parnin (Georgia Tech) showed in his research that developers often need 10–15 minutes after an interruption just to understand their editor again and reorient themselves.
- The classics DeMarco & Lister describe in their book "Peopleware" that developers need roughly 15 minutes of "immersion time" before they can even begin to work productively.
In professional parlance, the time needed to become productive again after an interruption is called "resumption lag". For complex programming tasks, this lag can be 20–30 minutes — even after a brief phone call.
The Flow State: When Everything Just Works
The opposite of interruption is the so-called "flow state" — a concept coined by the psychologist Mihály Csíkszentmihályi. In flow:
- You lose track of time and surroundings
- You work with apparent effortlessness
- Creative solutions emerge almost spontaneously
- Productivity is many times higher than normal
Developers often call this state "being in the zone". You're completely immersed in the work, the outside world fades away, and the code flows almost from your fingertips.
The problem: reaching the flow state takes time — typically 15–30 minutes of concentrated work. A single interruption destroys it immediately, and you have to start over.
Metaphors That Non-Developers Can Understand
How do you explain the problem to someone who has never programmed? Here are three metaphors that work:
The House of Cards Metaphor
Imagine building a house of cards with 50 cards — but with your eyes closed, purely from memory. You know exactly which card is where and which one comes next. Then the phone rings. When you hang up, all the cards are on the floor, and you can't even remember how many there were.
The Sudoku Metaphor
Imagine solving a very difficult Sudoku. You've just worked out which number belongs in a crucial cell — and then someone interrupts you for five minutes. Afterwards, you have to re-analyse the entire puzzle, because you've forgotten which possibilities you had already ruled out.
The Maths Metaphor
Programming is like solving complex mathematics in your head. If you interrupt me, I don't just lose the current thought — I lose the entire chain of reasoning.
Practical Implications for Day-to-Day Work
What does this mean for working with developers? Here are some concrete recommendations:
For Clients and Project Managers
- Batch your questions: Instead of five brief calls spread throughout the day, collect your questions and discuss everything in one block.
- Use asynchronous communication: Emails or chat messages can be answered when the developer is not currently in a flow state.
- Respect "focus time": If a developer communicates that they are currently working in a concentrated manner, that is not rudeness — it protects your investment in their project.
For Developers Themselves
- Communicate proactively: Let colleagues and clients know about your focus periods.
- Use visual signals: Headphones (even without music) signal that you would prefer not to be disturbed.
- Write brief notes: Before taking a break or accepting an interruption, jot down a few keywords noting where you are.
- Plan administrative tasks strategically: Group emails, phone calls and meetings into blocks rather than scattering them throughout the day.
For Teams and Organisations
- Establish "deep work" periods: Certain hours during which no meetings take place and interruptions are minimised.
- Question meeting culture: Does the developer really need to attend every meeting? Would a summary suffice?
- Create quiet working areas: Open-plan offices are suboptimal for concentrated work.
My Personal Approach
As a freelance developer, I've learnt to protect my productive phases. My phone is often on silent during core working hours. Not out of rudeness, but because I know: a thirty-minute flow block is more productive than three hours with constant interruptions.
I communicate this openly with my clients. Most understand it once I explain it — and actually appreciate it, because they know their project time is being used efficiently.
Conclusion
The frustration developers feel when interrupted is not oversensitivity or a lack of flexibility. It is a direct consequence of the cognitive demands of our work. The invisible mental architecture we construct is as real as it is fragile.
If you work with developers — whether as a client, colleague or manager — understanding this phenomenon is valuable. It benefits not only productivity but also the working relationship. Because a developer who can work without interruption delivers better results — and is happier in the process.
Have you had similar experiences — whether as a developer or in another activity requiring deep concentration? I'd be glad to hear your thoughts. Contact me for an exchange.
