Studies indicate developers wait on average 4 days for a pull request review. That’s a lot of idle time.
But it’s not like you’re waiting around for someone else to review your work. Right?
Well most of us aren’t. We create a pull request and then move on to the next thing.
But the cognitive load needed to revisit code increases with each hour that passes after we create a new pull request. And it turns out that idle time and context switching, particularly in the pull request process, are developer productivity killers.
Table of Contents
- What is Context Switching?
- Why Is Context Switching Time Consuming?
- A Context Switching Example
- How to Reduce Context Switching
- Understand How to Counter Context Switching
What Is Context Switching?
Context switching is the process of shifting between multiple tasks unrelated to each other. The bigger the difference between the first task you are working on and the next task you switch to, the larger the context switch between the two tasks is.
Managing and improving context switches, especially around pull requests, can do more to increase your team’s productivity than almost anything else.
Why Is Context Switching Time Consuming?
The essential problem with context switching is that it ruins focus. Without focus, it is impossible to enter a flow state.
But we can’t just avoid context switches altogether. They’re inevitable.
Who hasn’t finally gotten into a flow state only to realize you’re five minutes late for a meeting? You attend the meeting, begrudgingly, and then spend another 30 minutes after the meeting trying to get back into your flow state. That’s a waste of 30 minutes.
Lack of focus leads to a lack of flow. And that leads to a lack of enjoyment, a lack of engagement, and a lack of productivity.
A Context Switching Example
Let’s look back at the study mentioned previously.
For the PR reviewer, they often have to switch between a series of environments to help understand the code and its scope. And then, they will switch between tools to communicate the review, especially if your team members are operating asynchronously.
A typical code review requires the developer to switch context endless times and none of the tools were designed for the review process.
What ends up happening is that your team spends a big chunk of their review time context switching. After a while, they’ll just shrug and comment “LGTM.”
This harms the review quality and specific tasks worked on alongside it.
For the developer issuing the 4-day old pull request, can you imagine what happens to their short-term memory with that much extraneous cognitive load?
If I need to answer questions or make changes four days later, it’s hard to get back into the flow state I was in. I end up having to re-read the whole thing before I can start coding again.
And this context switching hurts the code quality. When a problem occurs on code I wrote days ago, it’s more difficult to debug.
So can you eliminate context switching for your team? No. But you can reduce it.
How to Reduce Context Switching
By now you’re an expert at increasing productivity. You know how to stay focused, reduce distractions, eliminate meetings, and guide your teams in code review best practices, right? Well, maybe most days.
But as more teams operate asynchronously, it can be harder for team leads or engineering managers to pinpoint where context switching might be impacting productivity.
Do you know your team’s average pull request review time and how that impacts total cycle time and sprint planning accuracy? Better still, are you notified when a branch is merged without review or only a LGTM comment?
Connect your Git, project, release, and incident management tools to LinearB to see how your team’s review time stacks up to engineering metrics standards. Get automated notifications when high-risk work like PRs merged without review happen. Book a demo today!
There’s also an element of personal responsibility for developers to manage their own context switching.
Thankfully, your team can use tools to help them focus on a single task at a time and increase their productivity. In addition to tools that you can use to reduce context switching during the code review process, have them try the following interventions:
Eliminate Push Notifications
Does every Slack/MS Teams notification need your immediate attention? Probably not. Limit notifications to mentions. Better yet, mute channels during working hours that only need to be checked periodically.
Chunk Your Work
Devs need several hours of focused, productive time. This blog post from Stack Overflow says devs are lucky if they get one 2-hour session of focus time each day. Cluster meetings together. Block off chunks of time on your calendar to focus on similar tasks.
Complete Tasks Before Natural Breaks in the Day
Ever avoid starting a new task when you have 15 minutes to spare before your next meeting or before the end of the day? Try to be conscious of tasks that you can complete in those short windows of time, and save them for natural breaks in the day.
Additionally, don’t start a complex task until you have the estimated amount of time to focus on it.
Use Tools to Give Context to Context Switches
Imagine you could estimate how long a peer review would take you? Or that you knew it was connected to a high-priority feature or imminent release?
Our WorkerB for Pull Requests Chrome Extension is a free tool devs can use to promote PRs and give their teammates necessary context. It includes:
- Estimated review time
- Number of files changed, commits, and lines of code
- Related ticket, release, and other context
- A gif or meme to get their attention
Our WorkerB magic links can decrease the time that devs spend waiting and help them push code to production faster.
Understand How to Counter Context Switching
So many of us are battling the work/life balance working remotely. And many teams struggle with productivity and just try to push themselves harder and harder.
It can be far more effective to take a step back and look at the root cause of productivity struggles, like context switching. But remember you don’t have to handle context switching on your own.
And join thousands of other dev teams revolutionizing how pull requests are managed.