27
Context Switching: Why It Hurts Code Reviews And What We Are Doing About It
Context switching, not fear, is the mind-killer. One of the main obstacles to quality code reviews is the simple fact that developers have a lot to do. The cost of going back and forth during code reviews and between code reviews and other tasks is standing between us and excellence.
But we can help.
In several ways, actually. There are several types of context switching, and they are all harmful in their own specific manner.
One of Reviewpad’s main goals is to reduce the amount of context switching you are doing today.
So, what exactly do we mean by context switching?
A bold claim, right? But it’s true. Cognitive load theory is a useful framework to understand how our brain processes information. There’s a lot of science about this.
The basic idea is that we store knowledge in the long-term memory of our brains, yet we are only consciously aware of a chunk of this memory. The so-called working memory. In other words, our brains (much in the same way as a computer that has limited RAM) can only store and manipulate a certain amount of information at any given time. If you exceed that amount, you generate errors, stereotyping, or both.
No two brains are the same. However, according to Miller’s law, an average human can only concurrently store and manipulate seven different elements in their working memory. This is what we call cognitive load.
Whether the magic number is 7, 9 or 4, several studies have suggested that humans are particularly poor at complex reasoning using totally new information in working memory. Still, this memory is fundamental to form knowledge that will be stored in long-term memory.
According to cognitive load theory, working memory load can be affected by three kinds of cognitive load.
- Intrinsic cognitive load: How difficult the subject matter actually is. (2+2 is easier to understand than E=mc2).
- Extraneous cognitive load: How much the format is helping or hindering you. (It’s easier to read in your native language than your second language).
- Germane cognitive load: How efficient you are at structuring your thoughts. (A trained mathematician will learn new math faster than an equally skilled linguist).
What happens when you’re reading a novel and you stop to reply to a tweet? Even if you were paying the utmost attention to what you were reading, you will replace whatever elements were in your working memory. When you get back, you will have to reread a couple of words, maybe a couple of sentences, to find your place. It may take you a couple of minutes to refocus on what you were doing.
This is pretty much how we’re doing code reviews at all times.
We have context-dependent memories. We have, as we mentioned above, limited cognitive loads. Modern work environments aren’t ideal for total focus. Especially in the kind of fast-paced environments that most developers find themselves in. Context switching is constant. Email, Slack, IDE, Jira, Teams, Zoom, meetings, clients. Every time you go from one environment to another, your brain needs to gather context so it can refocus. The effects of this are known, and they’re not ideal.
Code reviews, in particular, are heavily affected by this.
Code reviews often are context switches. If a developer is squeezing code reviews into a busy schedule, then the code review itself will constitute a switch in context.
So why would we prioritize code reviews?
Shouldn’t we let code review requests accumulate and then handle them all at once?
Absolutely not.
As I have discussed in my previous post, the complexity of reviews increases exponentially with the number of changes, the maturity of the codebase and the expertise of the reviewer. For a team to move forward with a project with a lot of unreviewed code is a costly thing to do. It will lead to mistakes and bugs that will be costlier to fix with every passing day.
It goes without saying that for any elements of your team to be stuck waiting for code reviews isn’t ideal either. Even if they do have other tasks they can get to in the meantime, that’s just extra context switches.
There are solutions for this. Greg Sanford, from Slack, advocates for checking (and resolving) your code review requests whenever you interrupt work. Allan Stewart, of Pluralsight, advocates for continuous code reviews, with developers working in pairs. We’ll write about how we cope with it in a future post.
Teams need to find strategies to reduce the amount of context switching between development and code reviews.
But that’s not the only kind of context switching.
And that’s where we come in.
When developers are doing code reviews, they are using an excessive number of tools.
Slack, or another messaging app, will be there, to get a notification and reach the original author of the code.
Then you move to a review interface to understand the differences and provide feedback. This typically will be the Web UI of GitHub, GitLab, Bitbucket or some other code host.
After that, there will be some juggling with a project management tool, such as Jira, to understand the scope of the changes, and with the IDE to understand some parts of the code.
This is a veritable Babel tower of context switching. Reviewers will be switching between a series of environments to help understand the code and its scope.And then, they will switch between tools to communicate the review. A typical code review requires the developer to switch context endless times and none of these tools was actually designed from the ground-up for the review process. What ends up happening is that you spend a big chunk of your review time context switching. After a while, your brain will be screaming “LGTM”.
This is detrimental not only to the review itself but to all the other tasks being carried out alongside them. Can you imagine what happens to your short-term memory with that much extraneous cognitive load? It’s not a coincidence that you get a coffee before and after doing a complex review.
I acknowledge that context switching between tasks isn’t something Reviewpad can fix. That’s a question of team culture that companies have to tackle (we hope they will!). But we can help with both the tools used to understand the code and those used to communicate.
Code reviewers shouldn’t be switching between these many tools. At Reviewpad, we believe that your browser can replace most of the suite of apps we described above.
We are integrating the entire review cycle into one tool.
First of all, you shouldn’t need an IDE anymore. IDEs are for coding –that’s a different cognitive task than understanding code or suggesting edits in a review. Reviewpad will provide you with the semantic context that you need to understand the code changes and identify functional bugs and security vulnerabilities. You will also be able to review changes easily by iteration (push or commit) to break down complex reviews into manageable chunks. We’re designing Reviewpad while aware of the limits in cognitive load so that you don’t feel overwhelmed with information.
How about communication?
Reviewpad provides new ways of giving and receiving feedback during reviews. It achieves this without comments being lost (because you modified a line of code) or having to go into a meeting to understand the overall structure of the changes. Everything is integrated with current code hosts so that you can have a smooth transition process.
If this looks good to you, you should book a demo with us. We would love to show you how much time Reviewpad can save you and your team.
If you are facing problems with code reviews, please share them with us – we’re here to help.
27