Surviving the Open Office: How to Pay Less of the Interruption Tax

The other day I was debugging a production issue. I was close to understanding the code and about to trace into the next layer of dependencies when I heard from the next desk: "What was the name of that hotpot place you went to yesterday?"

I froze for a second, then looked back at my screen. The thread was gone.

That day, I opened the same file six times and still hadn't fully traced the original problem.

This wasn't my first breakdown in an open office.

When I first started out, I thought sitting in a more open, lively space was fine. It wasn't until I began working on core services, mentoring new hires, and debugging production issues that I realized every small interruption was yanking me out of deep focus.

The scariest part isn't the interruption itself—it's the cost of regaining attention.

Once interrupted, our brains need several minutes, sometimes over ten, to re-enter the context of the code. But in reality, before you can even recover that context, a new notification pops up.

Many people say programmers need to improve their focus, but what we're actually facing isn't poor focus—it's a work environment that doesn't allow you to be quiet.

We're not unfocused; we're dragged down by brains forced into multitasking.

You've definitely run into these situations countless times. You're writing code when Slack pings: "Can this API support pagination?" You reply, try to get back to that call chain, glance at the screen, and then hear: "What are we having for lunch?" Half an hour later, you have five browser tabs open and three threads stuck in your head, yet you haven't written a single line of code.

This isn't procrastination—it's the penalty of context switching.

Our brains aren't true concurrent systems; they're single-threaded engines that need time to cold-start.

Cognitive psychology calls this attention residue: even after you jump from task A to task B, leftover information from A still occupies mental resources, preventing you from working efficiently on B.

And programming is exactly the kind of work that requires maintaining a running mental model to produce anything:

Remembering which modules call which services
Tracking where state changes across layers
Verifying whether various edge cases hold in the current scenario

We're not lacking effort; our brain's cache keeps getting flushed. Being a CPU is great, but without enough memory, you often end up recomputing the same things over and over.

This isn't a willpower problem; it's an environment design problem.

At first, I tried to solve it with self-discipline:

Wearing noise-canceling headphones
Setting Pomodoro timers, 25 minutes on one task
Writing to-do lists in advance and focusing on one task at a time

But over time, I found these had diminishing returns.

Because the external environment is the top priority in determining where your attention goes.

You can keep pulling your attention back like restarting a thread, but the moment someone next to you suddenly speaks, a Slack red dot appears, or a meeting invite pops up... your self-discipline efforts go to waste.

So I stopped focusing solely on personal productivity tricks and shifted to building a system for attention protection.

It's not about me being more focused; it's about designing a work state that is undisturbed by default.

The methods I later adopted really saved my brain's cache.

Calendar blocking for "immersion time." Every day, I block out two "immersion time" slots on my calendar, marked as busy like meetings. Others won't book over them, and it reminds me to do only one thing during that time. Mornings are usually a "coding window," and afternoons are for "design or technical documentation."
Notifications off by default, with intentional rhythm-setting. I turned off most instant notifications, including Slack and email pop-ups, and set a schedule to check them once an hour. For truly urgent matters, I ask people to come find me in person (it turns out 90% of them aren't urgent).

Sometimes I even write on Slack: "I'm debugging for the next two hours. If you need something, just @ me and I'll reply as soon as I see it."

This isn't being uncooperative; it's proactively communicating my rhythm so others work with me instead of interrupting me.

Create a small, quiet workspace for yourself. When I can't control the larger office, I build a relatively independent space for myself: consistently wearing noise-canceling headphones with white noise, adjusting my desk layout, and blocking visual distractions as much as possible. It's like building a cognitive buffer for my brain—not for physical isolation, but to reduce the frequency of random information intrusions.

Our imagination of high efficiency is often writing code for four uninterrupted hours and finishing an entire refactor in one afternoon.

But the reality is, surrounded by open offices, fragmented messages, and synchronous meetings, we can only seek focus in the limited gaps.

So now I pay more attention to: Which time slots am I most likely to get into flow? Which distractions can I preemptively block? Which tasks can I break into small chunks suitable for fragmented time? Which collaboration methods can reduce the need for ad-hoc interruptions?

Instead of blaming myself for being easily distracted, I've come to accept: this is an era where attention commands a premium, and focus itself is worth designing for.

If you also feel exhausted in an open office, it's not because you're not working hard enough—it's because you've been silently paying the interruption tax.

And the first step we can take is to start carving out a little space for our attention.

Even if it's just one hour, even if it's just turning off one notification, even if it's just changing the angle of your seat.

Not to be faster, but to reclaim that feeling of flow where you lose track of time while writing.

When was the last time you felt that way?