At PullRequest, we review a lot of code.

We’ve seen projects of all types from teams of all sizes and compositions. We help our clients by providing on-demand code review by experts in our reviewer network, and in doing so, we’ve adapted to countless, unique code review processes. Over the years, we’ve made some important observations regarding these processes that I find to be broadly under-noted in the development community. And I believe they’re significant to share.

In this article, I’ll cover one of the most common and recurring problems we see in peer code review processes: why some teams avoid doing it.

I’ve included several actionable best practices we’ve seen to be effective.

DISCLAIMER: Every team, every product, every company, and every software engineer, is different. There’s no one-size-fits-all approach for creating and maintaining a healthy and functional code review culture. Some of the recommendations I list may not be the best option for you and your team. My objective is to provide readers with useful information based on PullRequest’s unique position as a code review service, not to propose making sweeping changes to your existing processes (especially if it’s already working for you).

It’s a (very) common problem

One of the top five complaints I hear from engineering team leaders is that they can’t get their developers to review code. So pull requests sit quietly. And sit. For days… until the team lead, frustrated that no one else from the team has looked at them, reviews the code themself.

“How do I get my team to review pull requests?” is a question I get almost daily.

Like all difficult problems, there is no “magic bullet” solution. But there are some practical ways to combat it. Before diving into these approaches, it’s important to understand a few things.

Open pull requests aren’t unnoticed; they’re usually avoided

Some team leaders assume that pull requests are going unreviewed because they’re not loudly surfaced, so they’ll try things like introducing notifications for open pull requests in Slack, even building shared dashboards. But the issue persists. Their open pull request queue continues to compound in size.

It’s not that the pull requests are hidden from sight. It’s usually that pull requests are opened, sometimes multiple times, and quietly abandoned.

Why do some developers avoid reviewing code?

Teams don’t avoid reviewing pull requests for one sole reason. Rather, it’s almost always a variety of reasons, which collectively creates a barrier for doing review. Further, these reasons tend to vary over time and from person to person. That’s part of why it’s such a hard problem to solve. I’ll break these into two categories: those frequently discussed and those which are less frequently discussed.

Frequently Discussed Reasons

These have been spoken about at length in dozens of popular, very excellent articles and blogs on the topic of fostering a good code review culture, so I won’t dive into detail for each here. They include:

• Developers tend to find satisfaction in building things and solving problems, and code review feels like neither.
• It’s time-consuming and hinders velocity.
• It can be perceived as “extra work.”
• It can get political and impact interpersonal relationships.
• The bigger the pull request, the harder it will be to get teammates to review it.

Note that the reason these are frequently discussed is because they’re frequently valid. I strongly recommend reading into them further if you’re new to the subject.

Less Frequently Discussed Reasons

Perceived lack of skill

Many developers don’t believe they’re skilled enough to be able to review their teammate’s code. In many cases, code review skills are acknowledged almost as strongly as the quality of code a developer will produce. This is expected since the most experienced engineers will almost always be the most experienced reviewers.

When a junior developer opens a pull request reviewed by more senior team members, it can feel like a basketball novice walking onto the court to play alongside an NBA team. Their gut reaction will almost always be to leave the court (or close the browser tab). So they’ll tend not to participate in code review alongside teammates.

Using the same analogy, those developers won’t even step foot on an empty basketball court (stale, open pull request), knowing that NBA players (more senior team members) may show up later. Their thought tendency is “someone better than me will review it.” And the pull request will remain untouched.

Perceived lack of context

Some developers have a tendency to conflate any level of immediate unfamiliarity with the changes presented with a sweeping disqualification. You’ll hear this manifested in phrases like, “I wasn’t involved in the meetings discussing that,” or, “Lisa and Ankur were working more on that so they should review it instead of me.”

Like skill perception, this issue is especially prominent amongst junior developers.

Any sense of unfamiliarity, no matter how small or trivial, will have a crippling effect on their confidence. And they’ll begin to perceive reviewing a pull request as an opportunity for them to make an embarrassing, public misstep in front of their teammates rather than an opportunity to help push things along. It’s not necessarily that a developer is trying to find an excuse not to review a pull request, it’s that they’re afraid of posting something “wrong” or speaking out of place.

Being the first to review a pull request is harder than being the second

When a developer opens a pull request in a state of tabula rasa, one that hasn’t been commented on by any other team member, it’s a much more jarring experience than jumping into a pull request with pre-existing dialog and analysis. Not only will the developer have material to contribute to, small things like how comments are formatted by others (phrasing, grammar, formatting, etc.) will provide them with a conversation model to pattern-match.

Being the second (third, fourth…) reviewer on a pull request puts that reviewer at an advantage because they’re able to build on the review work (and it IS work) that’s already been completed by others. So some developers will be much more likely to contribute to a pull request review if they’re not the first to post something. These developers are also likely to click on a pull request they avoided reviewing prior after they’ve seen that comments from others have been posted.

Code review is assumed to be the responsibility of a few

And these “few” will tend to be your most senior-level team members. These are the folks I end up on the phone with, asking, “My team won’t review each others’ pull requests, how do I get them to?”

This happens because over time developers will notice that the most meaningful, helpful reviews will come from certain members of the team. And those members are almost always the most experienced; they’re the rockstar individual contributors and managers with more decision-making authority.

As a result, developers will start to form an implicit belief that it’s not their place to review code. And when a contributor broadcasts to the team, “Can I get some eyes on this?” They’ll start to assume that the request is directed to others, not them.

Code is reviewed “silently”

This is where a team member will review the changes, even very thoroughly, but not post anything to the pull request itself, leaving no trace they were ever there.

Why don’t they post anything? It’s usually a mix of the reasons above. If there were a very glaring and obvious issue, they’d call attention to it. But they tend to lack the confidence to post on anything questionable. And they’ll avoid posting “everything here looks great” for fear they’ve missed something that will be caught by a more senior team member, which could in turn reflect poorly on them.

Team members who exhibit this pattern also tend to over-think things. For example, if a developer spots several problems they think may be considered “trivial,” they’ll avoid posting them for fear it will earn them a reputation of being “naggy” or “nitpicky.” They may also hesitate to highlight something like a violation of the team’s agreed-upon conventions because they’ll start to fear the violation is actually an exception they’re not familiar with.

Takeaways

• Confidence plays a significant role in how willing a developer will be to review code.
• Avoidant patterns are observed in developers who are naturally less confident and/or less experienced. Junior developers are especially prone.
• It has less to do with avoiding work and more to do with anxiety.
• These developers understand that a growing pile of unreviewed pull requests is a problem, but their fear of posting a “bad” review overwhelms their willingness to help.
• Being the first reviewer on a pull request is usually more jarring than being the second.
• When you ask the team to review an open pull request, some members may assume the ask is not directed at them.

Best practices for correcting course

Make use of “assignment” features

Over the years, I’ve found it very surprising how many teams don’t actively assign pull requests; support is built into almost every version control provider. When a pull request is assigned to one of your engineers, it becomes a task with a goal. It helps them shift thinking from “can I, and should I, review this?” to “what do I need to do and know to make sure I review this thoroughly and contribute to the larger team effort?”

Assigning a pull request can be verbal

If making changes to the way you assign pull requests will impact your workflow, an “assignment” method could be as easy as asking them individually offline to review.

Keep in mind addressing the “team” as a whole can be ineffective (ie - “Can someone review this?") where asking individuals, specifically and by name, tends to be been far more effective. This may feel awkward; it may feel like you’re “targeting” certain individuals, especially in a public forum. You can minimize “targeting” tone by including why a teammate should review the pull request (ie - “Hey Victor can you review this? It’s similar to how you did…"). If this phrasing is not practical, message them individually.

Proactively involve all team members

It’s unlikely junior developers who rarely review pull requests will spontaneously start a regular habit of doing it one day. And many won’t vocally volunteer to be more involved. You can reduce friction and anxiety by having them review parts of pull requests they may be more familiar with, or @-mentioning them in conversation threads to verify the information.

Keep track of who participates in code reviews and who doesn’t, and try to find ways to rope in the teammates who are showing signs of avoidance.

Discourage conversations related to a pull request outside of the pull request

More junior developers will tend to ping the code author or their manager in a 1-1 to confirm something they notice before posting it as a comment. This is because, to them, posting the comment feels like publishing work they’re not confident in.

This may feel so natural to the developer that they don’t even realize that they should be interacting with the pull request instead.

When your senior team members start to assume the role of pull request review comment editors, you’re partially solving one problem by creating another. While it may be tempting to reply to developers one-on-one in these cases, try to encourage them to venture out of their comfort zone and post instead. When they do, be sure to…

Be welcoming of “non-issue” comments

Since many developers have anxiety about posting something that’s “wrong”, be sure to acknowledge that the act of posting something at all is the “right” behavior. This will help them understand that their reviews don’t need to be perfect.

Keep in mind that if a developer gets chastised by their team for one unhelpful review, it can completely undo all of the confidence they’ve built doing 100 helpful reviews.

Treat “silence” like a bug

A unique paradox, developers who exhibit confidence-related code review avoidant patterns almost always express that they want to do what they can to help the team. They’ll shy away from proactively reviewing open pull requests because their anxieties related to code review will overwhelm that eagerness to help.

Make sure your team understands that while providing a code review with wrong information can be harmful, silence is always harmful.

Consider code review activity as part of performance evaluations

But make sure it’s clear that team members aren’t evaluated based on how “perfect” their code review comments are, rather how active their participation is.

I’ve talked to some managers who struggle with this because they see it as “forcing” some members of their team to do something they don’t feel qualified or comfortable doing. It’s tough to see both the problem and be a sympathetic leader at the same time. Keep in mind that if your team is avoiding pull request code review, it is a problem that needs to be addressed. And challenging your team will pay off.

Conclusion

If you’re frustrated that pull requests are sitting around not getting reviewed by your development team, you’re not alone. At PullRequest, this is something we hear every day. We’ve seen the problem manifest itself in dozens of forms and we’ve helped teams of all sizes and compositions solve it.

It’s a complicated issue and there is no one-size-fits-all solution. As part of your remediation strategy, I ask that you consider the less frequently discussed reasons outlined here. The problem may have less to do with code review being time-consuming or political and more to do with confidence.