Free AI web copilot to create summaries, insights and extended knowledge, download it at here

Abstract

e team, since it could be interpreted as nagging if it’s coming from a peer. During weekly or daily stand-ups, the manager can ask everyone to explicitly include the PRs they plan to or have reviewed.</p><h1 id="4358">Say Thanks</h1><p id="5b2b">After the team as a whole has had a discussion about PR review participation, an elegant way for a software developer on the team to politely and subtly encourage pull request review participation would be to mention it in the team’s chat. Saying something as simple as, “Thanks to Miranda and Payton for reviewing my PR!” can make your coworkers feel more appreciated for having taken the time to review your PR.</p><p id="1c4e">Associating more positive feelings with reviewing PRs is a good hack for increasing team morale and encouraging team members to be more generous with their time and expertise. Just <a href="https://smartmarketingcommunications.com/saying-thank-you/">saying thank you</a> to those who review your pull requests in a public matter can encourage those who reviewed the PR to want to continue reviewing PRs and will hopefully nudge those who reviewer fewer PRs to understand that it’s something their team members need more support with and is also something that will make their coworkers feel thankful for.</p><h1 id="7d9b">Two Reviewers per Pull Request</h1><p id="d24b">There are several psychological factors at play when it comes to why your team members may not be participating enough in PR reviews. One of these might be that certain team members don’t feel fully comfortable or confident reviewing PRs. Some people feel a lot of pressure to be the only thing standing between this code and production.</p><p id="2e12">Maybe they’re a junior developer, and they might feel like they don’t have enough expertise. They might think that it’s better to leave it for a more senior person to review. Even if they’re not a junior developer, maybe they work mainly on the backend and don’t feel confident reviewing frontend PRs. It depends on how your team distributes work, how many different products or repositories your team works across, and generally how siloed your team members work.</p><p id="fbba">Sharing the responsibility of reviewing code before it’s merged into the main branch can help to mitigate several of these potential root causes. By requiring at least two reviewers per pull request, you can trust that in addition to your review, someone else will also use their knowledge and experience to the best of their abilities to review this code.</p><p id="6ed2">Junior developers or those new on the team might feel more comfortable reviewing the PR if they know the responsibility is shared with someone else. Another advantage of requiring two reviewers is that instead of waiting for some kind of experience threshold while onboarding, anyone can start reviewing PRs from their first day onwards to start learning from the other programmers and about the product.</p><h1 id="9ab5">Assign It</h1><p id="cab1">This strategy really only works coming from the manager or the tech lead to ensure there aren’t any toes that get stepped on. Reviewing pull requests is part of the job of a software developer, regardless of the level of experience, industry, etc. With that in mind, I think it’s very reasonable to assign reviewing pull requests just as you would features.</p><p id="3aab">One approach would be to set up a rotating review. Every week, you are responsible for reviewing the pull requests of a specific person on your team, Person 1. The next week, you review all the PRs from Person 2. If you rotate the list of reviewers every week and skip the week where every person is assigned to review their own PRs, then you’ve got a straightforward rotation for the whole team.</p><figure id="89a5"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*H8kquXLNN1E6xs2e8Ift0w.png"><figcaption>Example Review Rotation Schedule, by author</figcaption></figure><p id="9366">Otherwise if you don’t want to have a set schedule, the manager of the team could assign each person the task of reviewing certain PRs. This kind of task can easily be added to a task board, if your team uses something like that.</p><h1 id="5342">Let Technology Help</h1><p id="df57">There exist a wide array of tools which can help improve the

Options

quality of the code and therefore the quality of the pull requests. Using things like linters and other static analyzers help to reduce the amount of “nit” comments that get put on PRs. <a href="https://www.testim.io/blog/what-is-a-linter-heres-a-definition-and-quick-start-guide/">Linters</a> can help developers follow a defined style guide, catch syntax errors during implementation, and some even help identify potential security problems (like saving test passwords in the code).</p><p id="1c97"><a href="https://www.codiga.io/blog/static-code-analysis/">Static code analyzers</a> can generally help identify a lot of potential issues in the code before it gets to the pull request stage. Depending on the tool you choose to use, a static code analyzer can help catch performance, security, and safety problems. They help to catch the generic symptoms of <a href="https://refactoring.guru/refactoring/smells">smelly code</a>. By using tools to catch some of the problems, pull requests become easier to review. The better the code, the easier it is to read it and understand that it is performant and correct.</p><p id="4ad3">The better and the cleaner the code is, the easier and faster it is to review the PR. If you know that a certain developer on your team always has sloppy indentation, inconsistent new line styling, and other superficial things that do actually make the code harder to understand, it’s logical to dread or avoid reviewing their PRs. You don’t want to have to always make the same handful of comments about style and some simple improvements. If a clean pass from a linter is a requirement to merge the PR, then the linter or static code analyzer will catch these pesky improvements before you ever take a look at the PR.</p><h1 id="82fe">What Not to Do</h1><p id="25e5">I’ve heard from contacts of mine working in different companies across the industry on how their team encourages pull request participation. Some implemented strategies I’ve mentioned above, but some companies choose to encourage their employees not with the carrot, but with the stick.</p><p id="c3e1">These companies may choose to implement policies like punishing you for the number of comments left on your pull requests. They literally count the number of comments left on all of your pull requests cumulatively over time. If you have a high ratio of comments per PR, this degrades your standing in the company and makes you less likely to get promoted.</p><p id="ce84">Methods like this should absolutely not be used. It discourages open, honest discussions about different approaches for implementation. It also quickly creates a caustic, petty environment amongst team members. If you have a team member that leaves a lot of nit-picking comments, it’s too easy to hold that against them.</p><p id="ecd2">It’s much healthier to recognize participation positively or simply enforce accountability than it is to punish people for not reviewing or punish them for how they review pull requests.</p><h1 id="70a2">Pull Request Reviews Are Necessary</h1><p id="1c21">Most developers will optimize for their own benefit, as is human. Although reviewing code is part of the job description, if your manager doesn’t pay much attention to it, then it’s more beneficial for a developer to focus on their own feature work and ignore pull requests. Since they get more recognition for their feature work and that counts towards their bonuses or promotion, it makes sense for them to focus more on that.</p><p id="f9d5">Developers can get quite good at optimizing their work to follow whatever it is their manager focuses on. Rewards and promotions are generally based on how well your manager thinks you performed, so it’s logical to concentrate on the aspects of your work that your manager pays the most attention to.</p><p id="a84d">As a manager, it’s important that you also pay attention to pull request reviews. It’s an important part of creating and maintaining a healthy, performant software product, and the developers who actively review pull requests should benefit from their contribution to the team’s product.</p><p id="0793"><i>Open for freelance writing and ghostwriting work: </i>[email protected]<i>. I focus on front-end programming, data science, and software development.</i></p></article></body>

Top Strategies to Encourage Pull Request Participation

And why it’s crucial that everyone pulls their weight

If you work in software development, you’re likely familiar with pull requests (PRs) or code reviews (CRs). Reviewing pull requests is an important part of the work of a software developer, but not everyone always feels like doing them. There are a lot of reasons why a team might struggle to have good PR participation, such as intimidated junior developers, burnt out senior developers, or just plain forgetfulness.

Good pull request review participation would mean that everyone on the team actively reviews the code of others. There should be a good balance, without one or a few people doing the majority of the reviews. Reviews should be done consciously and carefully. The reviewer needs to take the time to understand the code in order to identify any potential bugs or improvements.

Oftentimes, senior developers tend to review more than junior developers. It can also happen where you have one person reviewing the majority of the pull requests, leaving them feeling burnt out from reviews. Encouraging PR participation is a tricky can of worms, and there’s no solution that will be the right one for every team.

Here is a collection of strategies to increase pull review participation in your team.

Find the Root Cause

Another handy tactic to address the problem of not having enough PR review participation is undergoing a little investigation. If the manager of the team asks each individual why they don’t review many PRs or what they think holds the team back from a more engaged PR review process, it will be more straightforward to follow the dotted line.

There are a lot of reasons a team has poor PR review participation. It’s possible that there’s an individual or a small group on the team that immediately reviews PRs as soon as they come out. They may just be too fast to allow others on the team to review the PR throughout their work day.

If you’ve ever reviewed a pull request, you know there are several aspects of a PR that can make it more or less comfortable to review. If the PR has a detailed description as to why this change is being made, the variables in the code are named in a logical and helpful manner that increases the code’s readability, the length of the PR is appropriate, and it takes less than 15 minutes to review the whole PR, then it’s barely even a bother to review the pull request. If, however, any of these aspects are reversed, so the PR has no description, variable names are confusing, the PR touches hundreds of files in a non-trivial way, and you have to dedicate an hour to properly review the pull request, then it’s hard to muster up the motivation to review that pull request.

It’s the responsibility of the author of the pull request to create PRs which are comfortable to review. Implementing your features in a way that makes it comfortable to review the changes is a skill that requires practice. Maybe a short training or brown bag session on how to organize your work to create good pull requests might be helpful.

Bring Attention to It

As a software developer, there’s always a lot going on. It’s common to have several features underway, so there are simultaneously design documents to write, code to implement, tests to write, production builds to release, on-call duties, interviewing candidates, and more. All that to say, it’s easy to let a task or two slip through the cracks.

The software developers on your team might simply be forgetting to prioritize reviewing pull requests. An easy, low-effort, and low-cost strategy to increase pull request participation is to bring attention to it. This is something best done by the manager or tech lead of the team, since it could be interpreted as nagging if it’s coming from a peer. During weekly or daily stand-ups, the manager can ask everyone to explicitly include the PRs they plan to or have reviewed.

Say Thanks

After the team as a whole has had a discussion about PR review participation, an elegant way for a software developer on the team to politely and subtly encourage pull request review participation would be to mention it in the team’s chat. Saying something as simple as, “Thanks to Miranda and Payton for reviewing my PR!” can make your coworkers feel more appreciated for having taken the time to review your PR.

Associating more positive feelings with reviewing PRs is a good hack for increasing team morale and encouraging team members to be more generous with their time and expertise. Just saying thank you to those who review your pull requests in a public matter can encourage those who reviewed the PR to want to continue reviewing PRs and will hopefully nudge those who reviewer fewer PRs to understand that it’s something their team members need more support with and is also something that will make their coworkers feel thankful for.

Two Reviewers per Pull Request

There are several psychological factors at play when it comes to why your team members may not be participating enough in PR reviews. One of these might be that certain team members don’t feel fully comfortable or confident reviewing PRs. Some people feel a lot of pressure to be the only thing standing between this code and production.

Maybe they’re a junior developer, and they might feel like they don’t have enough expertise. They might think that it’s better to leave it for a more senior person to review. Even if they’re not a junior developer, maybe they work mainly on the backend and don’t feel confident reviewing frontend PRs. It depends on how your team distributes work, how many different products or repositories your team works across, and generally how siloed your team members work.

Sharing the responsibility of reviewing code before it’s merged into the main branch can help to mitigate several of these potential root causes. By requiring at least two reviewers per pull request, you can trust that in addition to your review, someone else will also use their knowledge and experience to the best of their abilities to review this code.

Junior developers or those new on the team might feel more comfortable reviewing the PR if they know the responsibility is shared with someone else. Another advantage of requiring two reviewers is that instead of waiting for some kind of experience threshold while onboarding, anyone can start reviewing PRs from their first day onwards to start learning from the other programmers and about the product.

Assign It

This strategy really only works coming from the manager or the tech lead to ensure there aren’t any toes that get stepped on. Reviewing pull requests is part of the job of a software developer, regardless of the level of experience, industry, etc. With that in mind, I think it’s very reasonable to assign reviewing pull requests just as you would features.

One approach would be to set up a rotating review. Every week, you are responsible for reviewing the pull requests of a specific person on your team, Person 1. The next week, you review all the PRs from Person 2. If you rotate the list of reviewers every week and skip the week where every person is assigned to review their own PRs, then you’ve got a straightforward rotation for the whole team.

Example Review Rotation Schedule, by author

Otherwise if you don’t want to have a set schedule, the manager of the team could assign each person the task of reviewing certain PRs. This kind of task can easily be added to a task board, if your team uses something like that.

Let Technology Help

There exist a wide array of tools which can help improve the quality of the code and therefore the quality of the pull requests. Using things like linters and other static analyzers help to reduce the amount of “nit” comments that get put on PRs. Linters can help developers follow a defined style guide, catch syntax errors during implementation, and some even help identify potential security problems (like saving test passwords in the code).

Static code analyzers can generally help identify a lot of potential issues in the code before it gets to the pull request stage. Depending on the tool you choose to use, a static code analyzer can help catch performance, security, and safety problems. They help to catch the generic symptoms of smelly code. By using tools to catch some of the problems, pull requests become easier to review. The better the code, the easier it is to read it and understand that it is performant and correct.

The better and the cleaner the code is, the easier and faster it is to review the PR. If you know that a certain developer on your team always has sloppy indentation, inconsistent new line styling, and other superficial things that do actually make the code harder to understand, it’s logical to dread or avoid reviewing their PRs. You don’t want to have to always make the same handful of comments about style and some simple improvements. If a clean pass from a linter is a requirement to merge the PR, then the linter or static code analyzer will catch these pesky improvements before you ever take a look at the PR.

What Not to Do

I’ve heard from contacts of mine working in different companies across the industry on how their team encourages pull request participation. Some implemented strategies I’ve mentioned above, but some companies choose to encourage their employees not with the carrot, but with the stick.

These companies may choose to implement policies like punishing you for the number of comments left on your pull requests. They literally count the number of comments left on all of your pull requests cumulatively over time. If you have a high ratio of comments per PR, this degrades your standing in the company and makes you less likely to get promoted.

Methods like this should absolutely not be used. It discourages open, honest discussions about different approaches for implementation. It also quickly creates a caustic, petty environment amongst team members. If you have a team member that leaves a lot of nit-picking comments, it’s too easy to hold that against them.

It’s much healthier to recognize participation positively or simply enforce accountability than it is to punish people for not reviewing or punish them for how they review pull requests.

Pull Request Reviews Are Necessary

Most developers will optimize for their own benefit, as is human. Although reviewing code is part of the job description, if your manager doesn’t pay much attention to it, then it’s more beneficial for a developer to focus on their own feature work and ignore pull requests. Since they get more recognition for their feature work and that counts towards their bonuses or promotion, it makes sense for them to focus more on that.

Developers can get quite good at optimizing their work to follow whatever it is their manager focuses on. Rewards and promotions are generally based on how well your manager thinks you performed, so it’s logical to concentrate on the aspects of your work that your manager pays the most attention to.

As a manager, it’s important that you also pay attention to pull request reviews. It’s an important part of creating and maintaining a healthy, performant software product, and the developers who actively review pull requests should benefit from their contribution to the team’s product.

Open for freelance writing and ghostwriting work: [email protected]. I focus on front-end programming, data science, and software development.