How Much Does Context-Switching Cost Your Dev Team?

• Share on Facebook
• Share on LinkedIn
• Share on X

Everyone knows the signs that a dev doesn’t want to be interrupted.

Head down. Headphones on. General expression of concentration — or, if you ask them a question, mild confusion as they wonder who you are and why you aren’t a line of code.

A huge chunk of dev work is deep work. It demands your whole attention. Getting into it, and getting out of it, takes time. Which is why most devs don’t really like interruptions.  

The problem is that, for many devs, working life is interruptions. Meetings, urgent support tickets, emails, offhand questions from coworkers. The average day bristles with distractions.

And every distraction takes its toll. Chipping away at your productivity, the quality of your work, and your mental energy.

We call this practice of jumping from one task to another ‘context switching’ – and, even if you don’t know it, it’s probably undermining the quality of your output.

What is context switching?

Context switching means shifting from one task to another, unrelated task.

In other words, it’s forcing your brain to skip from one project or type of work to another. It’s the moment when a dev tears themself away from a coding task so that they can attend an hour-long meeting. Forcing their brain to switch out of ‘deep focus’ mode and into ‘interpersonal discussion mode’.

Context switching doesn’t always have to involve major distractions like these. It can be triggered by something as simple as a Slack message, or a passing question from a coworker.

Why does context switching happen?

Devs will always need to do some context-switching. We can’t eradicate it entirely.

It only becomes a problem when it starts to ramp up. When devs are struggling on a weekly – or even daily – basis to get the time they need to do good work.

There are a couple of structural issues that might cause this.

• Overwhelming workload. Overloaded devs find themselves pulled in a hundred different directions. When things get too busy, prioritization can go out of the window; devs find themselves trying to make incremental progress on lots of different tasks, instead of finishing one important task at a time.
• Too many meetings. It’s easy to see how a two-hour meeting cuts into a dev’s productive time. But you know what’s worse? A ‘fifteen-minute catch-up’ that pops up in the middle of a four-hour block of deep work. By the time you’ve prepared for the meeting, attended it, and then regained your focus, you’re probably left with about two hours of actual working time.

These kinds of issues tear devs away from their work, but it’s relatively clear how to solve them: devs need more manageable workloads, longer timelines, and more efficient ways of working. Solving these problems might not be simple, but issues like these have been on our minds since the word ‘burnout’ first entered our vocabulary.

But the most common cause of context switching is something much more complex.

More often than not, devs aren’t context-switching because they need to pick up another important task. They’re context-switching because they can’t physically continue working on their current build.

Long build times bring tasks grinding to a halt

Imagine it: you’re chipping away at a major project, diving into the details of your code for hours and hours. You’re feeling energized, inspired.

And then you run your build.

Sometimes, your build is fast enough that you can keep working while it’s running. You might have time to send a few emails or complete a quick, low-energy task while something processes. But you’re back in the game before you know it.

But most builds don’t run so smoothly.

Unfortunately, our “Big Dev Build Times” Survey Report found that devs spent an average of 57 minutes a day waiting for builds to finish.

When you’re stuck with one of these long builds, context switching actually seems like a good idea.

In fact, you feel extra productive. ‘Hey,’ you think. ‘I can use that lost time to complete other tasks on my to-do list, instead of staring at the ceiling or wandering off to make my fifteenth cup of coffee.’

The problem is that context switching doesn’t really solve the problem of long builds. If anything, it magnifies the wasted time.

The sneaky negative effects of context switching

In the moment, context-switching often feels pretty productive.

But every moment that you spend on a new task is making it harder to get back into your original task.

One study found that it takes an average of 23 minutes and 15 seconds to get back to their original task at hand after context-switching. That figure is true for any profession, but it’s especially true for devs, who spend so much time in deep focus work.

Imagine you’re pausing regularly throughout the day to wait for builds. Do that six times or so, and you’re losing nearly three hours of an eight-hour day. Based on StackOverflow’s estimate that the average developer’s time costs $83 (USD) an hour, that’s almost $250 a day per developer on context-switching alone.

It doesn’t stop there. Some older studies estimate that an interrupted task takes a dev twice as long, and can contain twice as many errors as an uninterrupted one.

And that’s just the business impact of context switching. Studies indicate that constant context-switching harms devs’ mental health.

In one University of California survey, developers who were interrupted more frequently were more stressed and more frustrated. They tried to compensate for interruptions by working harder and faster – which, in the process, chipped away at their mental health and introduced more errors. And more errors meant more stress…

In other words, if your team is using long build times as a chance to complete other tasks, you’re on the wrong track.

How to cut build times (and cut down on context switching)

If you really want to be more productive, you need to solve the underlying problem. Those build times need to get faster, so you can cut down on context switching as much as possible.

If that’s your goal, you should think about three key approaches:

• Try build caching. By storing multiple copies of build outputs and artifacts in a temporary location, you can reuse key components of your software builds later on. Build caching means no more starting from scratch every time you kick off a build. You’ll streamline your whole software development workflow, use resources more efficiently, and even resolve bugs faster.
• Write build-friendly code. Shortcuts that make code faster to write could be slowing down your builds. Start assessing your code and see if you can find opportunities to reduce dependencies, use compilers to simplify your code functions, or use precompiled headers.
• Be smart with your hardware and resources. You can definitely speed up your builds by adding extra hard drives CPUS, servers, and memory, or bumping up your cloud resources. But be careful; scaling up in this way can quickly become expensive. If you want to speed up builds while keeping costs under control, you’re better off finding ways to use your existing resources more efficiently. That might mean exploring ways to enable distributed builds, cost-effective cloud resource management, or a range of other tweaks to help your investment stretch further.

Switch smarter, and switch less

We’ve yet to see a dev role that involves no meetings, no one-on-ones, no ad hoc requests or emergency bug fixes. If that is how your job works, good for you — all your dev friends are probably pretty jealous of you right now.

But for most devs, context-switching is a fact of life. Even if it does affect productivity in the long run.

The key is to cut down on context switching as much as possible. Which makes finding a way to speed up build times kind of a no-brainer.

If you’re not sure how to start putting all our advice on build acceleration into practice, don’t worry. Check out our guide to cutting build times and improving dev times here — we’ll show you step by step how to implement build caching, write build-friendly code, and use your resources more efficiently.

So your team can stop wasting time waiting for builds to run, and start saving context switching for when they really need it.