On the Pain of Task Switching
Why Context Fragmentation Breaks Developers Before Systems
This enchiridion entry follows on from the short story, “The Developer Who Lost the Thread”:
The Developer Who Lost the Thread
In the far corner of an open-plan office, a place where noise travels faster than thought, sat a woman in a grey hoodie. Her name was Mara, though most people simply called her “Ping,” because every time someone needed something, it was her Slack icon that was the first to light up.
There’s a moment every engineer knows but rarely talks about. It’s not the moment before a deploy, or the moment after a pager alert. It’s the moment after you’ve opened your sixth tab of the hour, when your eyes blur, your shoulders instinctively rise towards your ears, and you realise you can’t remember what you were doing just five minutes ago.
It’s the moment where the work stops being work, and becomes interruption management.
Developers live in one of the most cognitively hostile habitats ever designed by humans: Slack pings like falling hailstones; ticket queues grow like mould; architectural decisions lurk half-made in five different systems; documentation multiplies like rabbits; and somewhere, buried under all of this, sits the fragile thread of your actual task — the thing that requires real thinking, the thing that needs immersion, the thing you could do brilliantly if only the world would leave you alone long enough to enter it.
But the world doesn’t. Not because it is cruel — though it often feels that way — but because software organisations have quietly accepted a faith that borders on superstition: That developers can handle infinite context without consequence.
They can’t.
And so the craft fractures. The developer is split into brittle fragments, each one representing the last thing someone asked them to remember. A Slack thread here. A half-read log line there. A half-built mental model everywhere.
Going back to 1578, in the printing houses of Plantin’s Antwerp, compositors were protected from distraction — not out of kindness, but because distraction caused typographical errors, wasted ink, lost days, and reputational ruin. A compositor was allowed to do one thing: compose the page. Even in the first century BCE, people knew that deep thinking required walls:
“A man who tries to do two things at once does neither. — Publilius Syrus
Today, paradoxically, in an age when cognitive load science is well understood, we’ve engineered workplaces that behave like psychological shredders. We glorify agility, but what we often deliver is fragmentation. We preach flow, yet architect for frenzy. And we mistake a developer’s silent suffering for resilience.
The unseen cost is mental health. Chronic context switching isn’t an inconvenience — it is a quiet, daily form of self-harm inflicted by systems that confuse busyness with effectiveness. Every switch forces your brain to dump state, rebuild models, and claw its way back into meaning. That burn is cumulative. The body keeps the score; so does the mind.
The good news is that this pain is not inevitable. Developers, teams, and platform engineers can design habitats that respect cognition instead of assaulting it. We can build platforms that hold context, not scatter it; workflows that concentrate attention, not dissolve it.
To do that, we need habits. Because habits are what save you when everything else is noise.
Protect the thread of thought — for once broken, it takes tenfold effort to repair
Task switching is not multitasking; it is mental gear-grinding.
The brain must unload one mental model (variables, domain concepts, stack traces, architecture, intent) and reload another. Research shows this costs between 20–80% of actual productive time, but the real cost is the invisible one: the strain on working memory, the erosion of flow, and the gradual burnout that comes from never completing a thought.
Platform engineering exists, in part, to minimise this burden: by reducing tool sprawl, centralising standards, creating golden paths, and automating the toil that adds nothing but fragmentation. Good platforms are supportive cognitive load balancers.
Some practices to consider
Guard the “Golden Hour”: Protect one deep-work block daily. No meetings. No Slack. No guilt.
Collapse Tooling Entropy: Use platform patterns — golden paths, unified pipelines, standard templates — to prevent cognitive context from scattering.
Keep State Outside the Mind: Use notebooks, scratchpads, traces, AI copilots, typed domain models. Free your working memory.
“One Piece Flow” for Mental Models: If you start building a mental model (debugging, refactoring, mapping), finish the shape before switching.
Close Loops, Don’t Multiply Them: Every open loop steals attention. Decide, delegate, or drop.
Design AI-Augmented Workflows Intentionally: Agents can hold context across tasks — but only if you train them to with valuable context and specifications. Use them as state stabilisers.
Build Psychological Guardrails into the Habitat: Quiet hours. Team norms. No “reply-instantly” culture. Platform-supported async first.
Reduce Multichannels to One Narrative: Don’t let decisions fragment across Slack, Jira, email, Miro. Create a single source of narrative truth.
Some things to avoid
Mistaking busyness for throughput
Celebrating responsiveness instead of effectiveness
Allowing every “quick question” to become a cognitive tax
Splitting work across too many WIP items
Using AI to accelerate switching rather than reduce it
Believing senior developers “should be able to handle it”
Designing platforms that amplify tool-sprawl instead of reducing it
It all comes down to understanding and being intentional about your software development habitat. In a bad habitat, a developer updates Terraform, tests a feature flag, scans a Jira board, responds to Slack, glances at Grafana, and reviews a PR — all before lunch. The outcome is six half-built mental models, zero meaningful progress.
In a good habitat a developer works from a golden path pipeline and a single domain model, with async updates and a dedicated deep-work block. The outcome this time is fewer switches, fewer errors, higher energy, lower stress.
In a good and AI-assisted habitat, a developer hands evolving context to an agent which tracks state, diffs changes, surfaces decisions, and narrates the work. The potential outcome here is contextual continuity — the real antidote to fragmentation.
Choose your habitat wisely, it’ll mean more than any tool investment.
You can also catch me on the road at various conferences and events
Further Reading
Deep Work — Cal Newport
A Philosophy of Software Design — John Ousterhout
The Programmer’s Brain — Felienne Hermans
Thinking, Fast and Slow — Daniel Kahneman
The Notebook: A History of Thinking on Paper — Roland Allen