Context Switching: The #2 Killer of Developer Productivity

Modern developers are master multi-taskers. Right from handling client side of things, to co-partnering on product, business, and developing, and maintaining code - they are omnipresent across an organization’s work stream. 

However, multitasking usually comes along with  context switching, at the cost of decreased developer productivity, and a humbug engineering progress. Jumping between tasks might be a doable shortcut to getting things done faster, but is a perfect ingredient to accumulate higher communication and technical debt in the longer run. 

In this post, we will examine how context switching impacts developer productivity, and the overall software development lifecycle along with ways to reduce context switching so devs can deliver engineering excellence. .

What is Context Switching?

You open your laptop to merge a pull request. Halfway through, a colleague messages you about a code patch showing recurring error, and asks you to fix it immediately. As soon as the meeting ends, you jump to another call scheduled for project updates. While you attend the catchup, your mind is constantly fixated on the PR that has to be merged by today anyhow, and cannot concentrate on what’s happening within the meeting. After the meeting, your focus is gone, and you feel worn out from the multiple constant switching between tasks. 

That’s what context switching does to the developer and the entire engineering team! 

Context switching simply means when a developer constantly juggles through unrelated, multiple tasks, without fully accomplishing  any one of them.

Why Do Developers Context Switch?

In the software realm, developers and engineering teams are trained to switch context multiple times. Most teams consider the constant shifting as a natural process. But is it really so? 

Developers context switch, because they are required to do so. In a recent survey, 43% of devs accepted context switching to be a part of their daily workhours, especially as geographies change, remote and distributed teams grow; all leading to more fragmented  work. 

Modern software development is an iterative process, with constant changes being made to the system by all stakeholders - product or business teams, the end consumers, and at times engineering teams themselves. A developer, while building other projects in the background, has to listen, acknowledge and respond to these feedback in parallel. And that’s how teams end up context switching. 

The first and foremost reason behind this constant switching is the abundance of distractions in a developer’s workday. Most devs we know have a fragmented schedule. On an average, a dev attends 8 meetings a week. The numbers go higher, as devs get promoted to senior positions. These meetings too might not bear much results, as 41% of devs multitask in these meetings- writing and responding to emails, while listening to colleagues. Meetings are not the only distraction for a developer. 

The second distraction comes in the form of the ‘always online’ culture, and pressure on devs to have a green Slack dot all the time. A DND on Slack for finishing off core tasks means missing out on crucial updates, monitoring, and alerts. If left unconfigured, Slack can be a drag on your attention span, and reduce deep work hours. The burden of too many notifications can sometimes overwhelm developers, and make them switch between  work-Slack-Gmail-work again.   

Another reason why developers context switch is the necessity to handle different, and mostly unrelated projects at once. They need to balance their workload, prioritize tasks, and optimize work hours to consistently meet the hard deadlines. Context switching helps them to stay on top of their work, atleast in the short run. 

Sometimes, the reasons behind frequent context switching runs too deep within an engineering team and is often a side effect of inefficient dev workflows. Lack of automation, flaky builds, sub-optimal SDLC requiring devs to create tickets on an ongoing basis  can open teams to frequent context switches. Manual practices especially in testing, and environment provisioning means slow change approvals, breaking code changes, and escaping bugs in production. On top of it, fragile systems keep lights on for most devs as they have to constantly firefight, and respond to emergencies, in the middle of core tasks. 

Context switching multiplies especially during code reviews while teams approach project deadlines . Imagine a reviewer examining your pull request five days later than requested, and submitting back a series of changes. For a dev revisiting a 5-day old PR means higher cognitive load, especially if the work is not well-documented, or the developer is already dealing with attention residue of previous context switching. The submitted PR for rework snatches away a dev’s focus from his project, even leading to missed deadlines, and lack of work prioritization. If developers keep constantly switching between VCS, to email and Zoom, and have to be  always available, when will they get work done?

These distractions can make a developer’s life harder, leading to unproductive work, team frictions, and even developer burnout.  When faced with the same context switching routine, over and over again, developers start feeling alienated from their projects, even leading to low developer productivity. 

The Cost of Constant Context Switching

Context switching comes at the cost of low developer productivity, reduced focus time, and high cognitive residue- all impacting the code quality, and final product delivery. Let's see how context switching impacts engineering teams:

1. Low Developer Productivity

Context switching hurts developer productivity in more brutal ways than ever documented. Devs have to switch contexts constantly- even when they are reviewing PRs, they switch between multiple environments to get the hang of the written code. Even to communicate these PR changes, devs have to juggle through a lot- from pinging on Slack, to making changes in Git, and notifying the team. 

The process might look sustainable for a while, but after repeating the same schedule over and over, devs can feel overwhelmed and even burnt out. The process takes a toll on developer’s work hours, even reducing the overall coding hours available to developers.

2. Reduced Focus Time, and Growing Attention Residue

When a developer switches context, they must first disengage from the task at hand and then shift their focus to the new task. This whole process takes time and can drain devs mentally. It takes a developer 25 minutes to refocus after a context switch. So, if a dev is shifting to four tasks in a workday, that’s two additional hours wasted in focusing back to their original task. 

Biologically, context switching has a cumulative effect on developer well-being, with each switch requiring more time and energy than the previous one. A University of California study confirmed that developers who were interrupted more frequently reported higher levels of stress, frustration, and time pressure. 

Frequent multi-tasking between different tasks creates an attention residue, severely impacting the focus muscle of developers. 

3. Dwindling Code Quality

Frequent context switching disrupts the whole idea of code reviews for most teams. The reviewers too are developers working on multiple tasks at once. Analyzing a codeblock for bugs requires extra focus on parts of a reviewer. But with the constant juggle between tasks, the review quality goes down, and bugs defect to production.

Carnegie Mellon University has already established how context switching negatively impacts quality of code, with higher bugs, less efficiency, low effectiveness, and more pressure filtering down on developers. How are developers expected to write bug-free code, when they have too much cognitive residue from parallel tasks? 

So how to eliminate context switching for your developers? The answer is disappointing- Context switching is here to stay, and is inevitable, especially as a developer’s job becomes harder, and the products they create, more complex. But with the right tools, and practices, it is easier to reduce frequent shifting. 

How Can Developers Reduce Context Switching?

Higher context switching might snowball into a high product backlog, low quality, and difficult customer retention- negatively affecting the brand consensus- all impacting developers negatively.

So, how to reduce context switching so it doesn’t kill productivity? Here we discuss the ways developers can adopt to reduce context switching to maximize productivity.

1. Reserve Your Focus Time

The best way to start with the burning issue is minimizing distractions in the shorter run. For starters, it is best to reserve your work hours into focus time, and communication time. Even the Clockwise report speaks for the same- 90% of developers who reserved 2-hour focus time for deep work recorded higher work productivity and better code quality.

2. Plan Productive 1:1 Meetings

It isn’t meetings specifically that bogs developers down, but the load of unproductive meetings, with no results, and actions. The answer to this side of issue is end to end visibility into developer workflow. When engineering managers have mapped their dev’s workday to the tasklist, it becomes easier for both parties to have productive 1:1s.

3. Set Specific Hours for Communications

On a more personal note, developers should set specific hours for communications, apart from meetings. Instead of constantly sneering through the inbox, it’s better to schedule 20 minutes after lunch to reply to emails, check Slack notifications, and manage incidents. Use website blockers, if necessary to block any unwarranted distraction. This can help you to achieve back your flow state, and limit the never-ending temptation to shift contexts.

4. Set Specific Hours Per Developer for Code Reviews

When it comes to code reviews and debugging, EMs can set specific time per developer for these ad-hoc, but important tasks in sprints. And then offering devs autonomy to schedule their code reviews with the reviewer. Use calendar markings if needed.

5. Use Engineering Analytics Platform

An engineering analytics platform can help teams take care of their context-switching problems with ease. Hatica supports developers in maintaining their flow state using the maker time metrics.

By looking at the meeting statistics and activity heatmap from communication activity, teams know how frequently they are context switching from their core tasks. It gives teams the chance to figure out better ways to optimize workflows, and ensure 120-minutes of deep work everyday without meetings and distractions. 

Moreover, Hatica takes care of team 1:1s by offering managers visibility into their team's work activities. The activity log dashboard helps visualize a developer’s workday to engineering managers, so your next 1:1 becomes a discussion on blockers, rather than just an ordinary status update.  

Unlock Meta Productivity with Hatica

While Hatica cannot stop constant notifications and requests into your inbox, we can help streamline a developer's work hours so they can generate productive work, don't feel blocked, work with focus, and unlock meta productivity.   

Subscribe to the Hatica blog today to read more about unblocking developers, and boosting productivity with engineering analytics.

FAQs

1. Why is context switching bad for productivity?

Context switching reduces productivity since it pays a cognitive cost. When we go from one activity to another, our brain requires time to disengage from the prior context and reorient itself to the new one. This transition time can lead to a lack of attention, lower efficiency, and decreased overall production.

2. How much time is wasted in context switching?

The amount of time spent by context switching varies based on numerous factors, including job difficulty, individual skill, and switching frequency. According to recent research, it takes an average of 23 minutes and 15 seconds to completely restore concentration and immerse oneself in a work following an interruption or context transition.

3. Why is context switching the mind killer?

Context switching is commonly referred to as the "mind killer" because it dramatically degrades cognitive ability and mental attention. When we switch from one task to another, our brain needs to disengage from the previous context, redirect attention, and reorient itself to the new task. This change disturbs our cognitive flow and consumes valuable mental resources.

4. Why is it important to reduce context switch time?

Reducing context switch time is important because it helps individuals to maintain focus, maximize productivity, and optimize efficiency. Context switching hampers workflow, requiring mental readjustment and wasting valuable time.