Context Switching Between Slack and Code: the Hidden Tax on Deep Work
Context switching between Slack and code costs developers hours of deep work weekly. Here's how to measure it, reduce it, and stop losing flow state.
By Ellis Keane · 2026-03-13
How many minutes of deep work did you actually get today? Not time-at-desk. Not time-with-IDE-open. Actual, sustained, uninterrupted focus on one problem. If you can answer that confidently, you're either lying or you've never experienced context switching between Slack and code – in which case, genuinely, teach me your ways.
I ask because I genuinely don't know my own number most days. I know I sat down at 9am to work on a database migration. I know I looked up at some point and it was 1pm. And I know that somewhere in between, I'd opened Slack maybe two dozen times – not because anyone needed me, but because that little red badge has a gravitational pull that would embarrass a small moon. The migration, which should've taken a morning, bled into Wednesday.
The 23-minute myth (and what's actually true)
You've probably seen the statistic: "it takes 23 minutes to refocus after a context switch." That comes from Gloria Mark's research at UC Irvine, and while the research is real, the number gets misquoted so often it's essentially become vibes. The 23-minute figure refers to the time to return to the original task – not the time to return to the same depth of focus – and it was measured across knowledge workers broadly, not developers specifically.
For developers, the real cost depends entirely on what you're holding in your head. Debugging a subtle race condition where you've finally, after twenty minutes of staring, built a mental model of three interlocking state machines? Losing that model costs you the full twenty minutes again. Fixing a typo in a config file? Seconds. The point isn't the exact number. It's that context switching between Slack and code has a cost that's completely invisible in the moment but shows up, clear as anything, in your sprint velocity at the end of the week.
The Lokalise Tool Fatigue Report found that workers switch between apps 33 times a day on average, with 17% switching more than 100 times. We've built an entire ecosystem of "productivity" software whose primary measurable effect is interrupting productivity. Somewhere, a product manager is celebrating DAU numbers that consist entirely of people checking whether they can go back to work yet.
Why context switching between Slack and code is uniquely expensive
I want to be fair to Slack here. It's a genuinely good tool, and I'm not about to argue that engineering teams should go back to IRC (though some days the thought crosses my mind). But the Slack-to-IDE context switch is categorically more expensive than switching between two browser tabs, and it's worth understanding why.
The mental model mismatch. When you're deep in code, you're holding a complex model in your head – variable states, function call chains, the overall shape of the system you're modifying, and the particular sequence of changes you need to make in a particular order. Slack operates in a completely different cognitive mode: social context, conversational threading, figuring out who's talking about what and whether it's relevant to you. Switching between these two modes isn't like toggling between tabs. It's like switching between two entirely different types of thinking, and your brain doesn't have a "save state" button for either one.
The uncertainty tax. Here's what actually kills your focus: it's not the interruption itself, it's the possibility of the interruption. When a notification badge appears, you don't know if it's important until you check. That uncertainty lodges itself in your working memory as an unresolved question, nibbling at your attention even if you resist the switch. And, look, I'm as bad at resisting this as anyone – I've caught myself ⌘-Tabbing to Slack mid-sentence in a commit message because the badge appeared in my peripheral vision. The commit message was about removing dead code. The Slack notification was someone reacting to a gif with a gif. Productive afternoon all round.
The thread trap. You open Slack, see a notification, click into a thread, read three messages, realise it doesn't need your input, back out, notice another channel has a badge, check that one too – and suddenly five minutes have evaporated and your migration logic is a distant memory. The irony is that Slack's threading model, which was designed to reduce noise, actually increases the number of clicks between "I saw a badge" and "I've confirmed nothing needs me." Threads within threads. It's turtles all the way down.
The cost of context switching between Slack and code isn't the seconds spent in Slack. It's the cognitive overhead of switching between two fundamentally different modes of thinking, compounded by the uncertainty of not knowing whether the notification was worth the interruption.
What actually helps (and what doesn't)
I've tried most of the standard advice – and I mean properly tried, not "read the blog post and nodded" tried. Here's where I landed after about six months of actively watching my own interruption patterns.
What works
- Scheduled Slack windows. Check Slack at 9am, noon, and 3pm on deep-work days, and close the app (fully close – not minimise, close) in between. Drops the switch count from the mid-twenties to single digits. Hiding the dock icon entirely on focus days is absurd but effective.
- DND with keyword exceptions. Slack's Do Not Disturb mode, configured to let through messages containing specific terms or from specific people. Silence from the noise, alerts for genuine urgency. Imperfect, but better than binary.
- Batching outbound messages. Jot Slack messages in a scratchpad and send them in batches. Reduces interruptions for other people on the team, and eliminates "wait, ignore that last message" follow-ups.
What sounds reasonable but doesn't survive contact with reality
- "Just turn off notifications." Protects flow state beautifully. Also means you miss the thread where your team changes the API contract you're currently implementing against. The cure creates its own disease.
- "Set your status to busy." People ignore statuses. The status carries no real information because everyone claims to be busy all the time – it's the workplace equivalent of "how are you?" / "fine."
Filtering at the system level
The scheduled-windows approach works, but it's a discipline solution – and discipline solutions have a shelf life. You maintain them for three weeks, something urgent breaks the pattern, and then you're back to checking Slack every time the badge twitches. I've been through this cycle enough times to know that the fix isn't more willpower. It's a better filter.
What would actually solve the context switching problem at the system level is something that understands both what you're working on and what's happening in Slack, and can tell the difference between "there's a decision in a thread that directly affects the code you're writing" and "someone is debating lunch options in #random."
That's what we're building with Sugarbug. It connects to Slack (and GitHub, Linear, Figma, among others), classifies every signal by type – decision, blocker, question, status update, noise – and links them to the tasks and people they relate to. You see which Slack activity is relevant to your current task without opening Slack. No badge. No uncertainty tax. No five-minute thread spelunking to discover that, no, that notification was not about you.
Concrete example from last week: I was deep in a vector search migration, and a teammate made a decision in a Slack thread about the embedding model we'd use going forward. Without filtering, I'd have either missed it entirely (DND mode) or stumbled across it hours later by scanning threads manually. Sugarbug's classifier surfaced it as a "decision – relevant to your current task" signal. One glance, back to the migration.
We haven't solved this perfectly – the classifier still misses edge cases, and we're iterating on how to present filtered signals without creating yet another notification surface (which would be a beautifully ironic own goal). But even imperfect filtering beats the binary of "all notifications" or "no notifications." On that migration day, I'd estimate at least twenty of my Slack visits were unnecessary – twenty context reloads that a decent filter would have prevented entirely.
Stop paying the context tax every time a badge appears. Sugarbug surfaces only the Slack signals that actually affect your current work.
Q: How much does context switching between Slack and code actually cost? A: Gloria Mark's research at UC Irvine found it takes about 23 minutes to return to your original task after an interruption, though the actual cost varies enormously with the complexity of what you were doing. For developers switching between Slack and their IDE dozens of times daily, that compounds into hours of lost deep work every week – and the mental model you'd painstakingly built up rarely survives the round trip intact.
Q: Does Sugarbug help reduce context switching between Slack and code? A: It does. Instead of switching to Slack to check whether anything needs your attention, Sugarbug classifies Slack messages by type and links them to the task you're working on. Decisions, blockers, and questions relevant to your current work surface without you having to go looking for them. The goal is to eliminate the "check just in case" switches – the ones where you open Slack, find nothing actionable, and then spend three minutes remembering what you were doing.
Q: Should I turn off Slack notifications to reduce context switching? A: Muting protects flow state but means you miss things that actually matter – like the thread where your team decides to change an API you're implementing against. The better approach is filtering: distinguish signals that need your attention now from noise that can wait. Scheduled Slack windows are a good manual version of this; Sugarbug is the automated version.
Q: What's the difference between context switching and multitasking? A: Multitasking is trying to do two things simultaneously (which humans are genuinely bad at). Context switching is moving between tasks sequentially – the cost is the time and cognitive energy to reload your mental model of the code. For a developer holding a complex system in their head, that reload can take anywhere from seconds to half an hour depending on the depth of the work.
Q: Can Sugarbug filter which Slack messages are worth interrupting for? A: Sugarbug classifies signals by type and links them to the tasks you're working on. So instead of opening Slack and scanning every channel, you see which activity is relevant to your current work. We're still iterating on the relevance scoring (it's not perfect), but it's meaningfully better than the all-or-nothing approach of DND mode.
---
If the Slack-to-IDE round trip is bleeding your deep-work hours dry – and if hiding the dock icon to avoid a notification badge sounds like a reasonable productivity strategy – that's the tax we built Sugarbug to reduce. Join the waitlist.