Programming has an unusually high cost of interruption compared to a lot of other knowledge work — understanding why makes it easier to justify actually protecting focus time.
Why context-switching hits programming especially hard
Writing or debugging code requires holding a lot of context in working memory simultaneously — the shape of the data, the state of several variables, why you chose this approach over an alternative, what you were about to check next. A single Slack notification doesn't just cost the time spent reading it; it costs the time to rebuild that mental context afterward, which research on task-switching consistently puts well above the interruption's apparent length. A "quick 30-second question" can realistically cost 15-20 minutes of actual productive time once the rebuild cost is included.
This is fairly specific to work requiring sustained, complex mental state — it's a much smaller cost for tasks that don't require holding much context (replying to email, triaging tickets), which is part of why "just be more disciplined" advice generalized from other kinds of work doesn't map cleanly onto programming.
Batch communication instead of responding in real time
Checking Slack/email continuously throughout the day means being interruptible continuously throughout the day. Checking it at set intervals (e.g., top of each hour, or a few fixed windows) contains the interruption cost to those specific moments instead of spreading it across everything else. Most messages genuinely aren't urgent enough to justify breaking focus the instant they arrive — and for the ones that are, most teams have (or should have) a separate, louder channel for genuine emergencies.
Protect your highest-focus hours for your hardest problems
Most people have a period of the day where they think most clearly — for a lot of people, this is earlier rather than later. Whenever that window is for you, defend it specifically for the work that most needs deep, uninterrupted thought (a hard bug, a design decision, writing genuinely new code) — and push lower-stakes work (code review, replying to messages, routine tickets) into your lower-energy hours instead. The mistake is treating all hours as interchangeable and letting whatever's most urgent (rarely the same as most important) claim the best ones by default.
Time-box exploration, not just execution
Open-ended "figure this out" work (researching an unfamiliar library, debugging an unclear issue) can expand to fill unlimited time without a boundary. Setting a rough time box — "I'll spend 45 minutes trying to understand this before asking for help or trying a different approach" — forces a checkpoint instead of an unbounded rabbit hole, and it's usually a psychologically easier way to ask for help too: "I've spent 45 minutes and I'm stuck" is a much easier sentence than admitting you've silently lost half a day to something.
A single practical change to start with
If none of the rest sticks, this one is worth trying alone: turn off non-essential notifications during your best focus block of the day, and batch-check messages at the boundaries of that block instead of continuously through it. It's a small, reversible experiment, and it isolates the single highest-cost interruption source (real-time messaging) without requiring a full overhaul of how your day is structured.
