Imagine this: your team has recently become hyper-productive, even though it is small. Great situation, right?

Unfortunately, it also means your best senior developer is slowly being crushed by the queue of things that need reviewing. The rest of the team does not know the domain quite as well as she does, so if the review is supposed to carry real weight, the code needs to pass by her.

It is not the most enjoyable position for your senior developer to be in. She regularly sighs over the career choices that somehow led her here, but she does her duty and gives thorough feedback on all the code.

So what do we do as a team?

We could start by looking at why we review in the first place. Is the review a quality assurance activity meant to prevent bugs? Are we checking whether our coding standards have been followed? Is the review about knowledge sharing, so the team can maintain a shared overview? Or is it an approval process?

Are we checking that the code actually addresses the problem and that there have not been any misunderstandings about the domain or the problem itself? Are we checking the Definition of Done? The architecture? Non-functional requirements? Whether we still respect our API contracts? Security issues? Have we introduced a new way of doing things that needs to be discussed?

When we know what we need from the review, it becomes much easier to optimize it.

A good place to start is to see whether some reviews can be skipped. Is this a prototype? Is it a very simple, limited change that could have been made by a four-year-old? Was the code written through pair programming or mob programming, and therefore perhaps already reviewed? Make a risk assessment and decide whether the review is actually needed.

But many reviews probably cannot be skipped, so what do we do with them? We can look at the reason for the review and see whether that concern can be addressed in other, preferably automated, ways.

If we review to avoid bugs, then a strong test suite may be part of the answer, along with a shared culture of quality. Do we trust our tests? Have we invested time in them? Are the primary flows well covered?

Static code analysis can also address a good number of review concerns. It can find dead code, incorrect API usage, common security issues such as SQL injection, duplicated code, long methods, broken naming conventions, poor formatting, and even some performance problems.

In general, humans should not be used to check things that machines can check.

We can also look at whether we can help earlier in the process, for example through pair programming, so misunderstandings are caught sooner.

Then there is the process around the review itself. Does it have to be the senior developer who reviews? Can someone else do a partial review? Does the senior developer have to review alone? Can we review together, so everyone in the team gains understanding? Can a junior developer review before a senior developer and ask questions – of varying quality – that may still catch something important?

A junior developer may have exactly the right eyes to see whether the code is understandable. If not all team members can understand the code, is it good code?

Can we use AI for a first-pass review? Can we make sure that a pull request has a reasonable size and does not touch 100 different files while addressing four different issues? And how do we handle a review when we actually do need to upgrade a library and therefore touch 100 different files, even though we are only addressing one issue? Perhaps we handle that together.

In other words, we can catch many things before the review process reaches the senior developer we met at the beginning. We can serve the code on a silver platter, so she only has to review the domain understanding that may not have been caught earlier.

And not just the code. Make the whole review process easy and fast. It should not require moving through several different systems or writing a report based on the review. Maybe the review is more of an informal conversation. Do what works for your team.

If other measures have been taken first, the senior developer can trust the code on a wide range of points. That makes the review shorter and pulls her out of flow for less time. And if she brings the whole team into the review process, we may even get to a place where everyone on the team can review with the same level of trust.

It is not quite as cold at the top if we stand there together.

So, to summarize:
Do not use humans to check what can be checked automatically.
Bring more team members along for the journey. It is also more fun.
Optimize the review process by serving the task on a silver platter and keeping it lightweight.

Would love to hear more strategies. What do YOU do about the review queue?