Six tips for setting up a culture and system for strong code reviews on a team.
- Match the level of the Code Reviews to the context of your team and project
All software companies must take an intentional and structured approach to code reviews. Still, there is no "one-size-fits-all" approach for code reviews; it varies depending on the codebase, the company's size, and the team's preferences.
When a company is starting out, code reviews should look different than during rapid growth, or product maturity.
Here’s a quick guide to figuring it out for your team and development stage:
If a product is just starting to be built, at the earliest stages, such as during a hackathon or simplest minimum viable product, then code reviews are not necessary. At this stage, they only get in the way. The team should just figure out what functionality should be created and do their best.
After that stage, code reviews ramp up in importance. Early-stage companies might want to pick one person on the team to do all of the code reviews. This has the benefit of simplicity and speed but comes at the expense of a shared and varied learning experience.
As a company grows, more people should be performing code reviews. As a rule of thumb, all senior engineers should do code reviews when a company is in the rapid growth phase. In this phase, we are assuming that speed is still essential.
As the company matures, and as there is more capacity, code reviews should be carried out by seniors and mid-level engineers.
Finally, as the codebase becomes mature, and the team has more capacity, all engineers including junior engineers should participate in the code review process. Note that the juniors will not only need training, but their reviews will also likely need a second evaluation by someone more experienced. Here, a major goal of code reviews is as a teaching tool for junior engineers.
- Clear coding standards, readily available
Next, if your organization has documentation about coding guidelines or content specific to your code, make sure it is readily available and accessible to the code reviewers so that they don't have to search everywhere for what to include. See a discussion of linters, below.
- Give code reviews gravity
Make sure that code review work is as valued as coding — both activities should have equal weightage and visibility.
There are many ways to do this: from celebrating engineers who have done a lot of code reviews, to discussing code reviews at informal check-ins, to including contributions to code reviews as part of the annual performance process.
If code reviews are not important based on recognition, rewards, and other consequences, it doesn’t matter what is said on paper.
Do you have a “great developer” who refuses to do code reviews or refuses to act on feedback from others? What happens to them? That’s one of the clearest signals to the rest of the organization about how much code reviews actually matter.
- Psychological safety
Psychological safety is about colleagues feeling safe and trusted, knowing there is room for mistakes and that bad news can be shared, and generally feeling confident that the organization has your back. Studies at Google and elsewhere have demonstrated that psychological safety is one of the most important factors to make teams successful.
It makes sense– if you are constantly worrying about whether someone’s out to get you, you are going to be investing significant time and emotional energy in protecting yourself, rather than creating. And you’ll be suggesting far fewer ideas, or taking far fewer risks, that could advance the team.
Everything you are doing to work towards greater psychological safety in general at your organization and your team has applicability to code reviews, too:
Reduce the negative consequences of delivering code that needs to be fixed. We can’t say “eliminate” the negative consequences; after all, teams are here to build great code that meets requirements. But framing cost reviews as teaching moments, not judgment moments, make it
Regularly canvas the team, especially junior developers and others who might be worried they have less standing, to understand how the code reviews are making them feel.
Review a sampling of code reviews regularly across all reviewer-coder pairings, to look for positive or worrisome trends based on their tone and conclusions.
Offer training and support, not judgment, to colleagues who may need more training and support in creating code reviews that protect psychological safety.
Finally, we recommend that continuous violators of psychological safety, in code reviews and elsewhere, should be asked to leave the team. We don’t believe that any single coder or colleague is more important than making sure that everyone feels enabled to do their best work.
- Clear process
Make sure that the process for code reviews is articulated, clear, codified, taught, followed, and reinforced.
Especially while teams are dispersed, it might be helpful to have a “cheat sheet” of the basics of your code review process easily available – such as, pinned to the development Slack channel.
On top of that, the organization should be clear about when code reviews should be done and who should do them – see below.
- Fast turnaround
Code reviews are a responsibility that should always be taken seriously — and take first priority. Someone's first task is always to review other people's code before writing one's own.
The reason for that is that unblocking someone else's work makes others on the team more effective. If you are working on your code, instead of reviewing someone else's, then it becomes a blocker. If you review their code, then work on your own code, you are unlocking your team’s potential. Remember — it’s a craft, not a competition!
Top comments (0)