Six tips for setting up a culture and system for strong code reviews on a team.
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:
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.
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 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.
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:
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.
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!
Also Published here