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:
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.
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.
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? 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.
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.
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.
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.
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.
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.
Top comments (0)