Code review can be an important part of a team’s culture, so it is worth thinking about. If you
asked me about code review two years ago, I would’ve said its key to maintaining code quality and
mentoring less experienced programmers. Now I know better. Code review is much about making the
code better as it is about making the team happier. How the team runs code reviews should be based
on the team’s values and culture.
The obvious things
Let’s talk about the obvious things first. What are we looking for out of code reviews?
Because good code reviews allow a team to maintain high code quality.
Where you have a non-trivial group of engineers writing code together, it is important to develop
consistency. This applies to both style (tabs, naming conventions, patterns & anti-patterns) and
tooling (test frameworks, code generation, build tools). When there is consistency, everyone’s
The “best” in best practices is misleading. But “At Least It’s Not Bad” practice doesn’t roll off
the tongue (try selling that to management). There are some good rules of thumb in programming and
it’s important to get everyone to follow them. Code reviews help ensure everyone generally do the
I’d consider these the minimal goals when you are fostering a code review culture.
What are your values?
Show me your code review guidelines and I’ll know what your team is like.
If you think about it, code review is all about conversations. It starts with “I have good code and
I want to share it with the team” and ends with the saying, either “No. This code is shit!” or “Hey,
let’s talk about this.”
Whether you’re trying to fix a broken code review process or introduce it in your org, your team
should have some ground rules around how to have these conversations. Of course, there no wrong way
to have these conversations. They may be brutally honest (euphemism for “we don’t care about each
other’s feelings”) or polite to a fault, but they are always a reflection of the team. If you’re in
management, they are a reflection of how you’ve shaped your team.
Just like every family has its unique characteristics that make them special, every team conducts code reviews
differently. There are some key areas with very different variations:
- How to take people’s feelings and assumptions into account?
- How to signal a strong objection vs a weak one?
- How should people resolve disagreements?
- Do they value individual code ownership or group ownership?
A clear set of principles help the process run smoothly and amplify your strengths. They will change as the team
grows. So keep in mind to revisit these discussions as necessary.
Some of the important cultural elements of code reviews:
A good way to say ‘nitpick’
How does the team deal with nitpicks? From silence to ‘nit’, each team has its own unique
ettiquette. One method to silent nitpicking is by having linters and static analyzers do the
nitpicking. When’s the last time you got upset by your spellchecker pointing out your mistakes?
What is the acceptable level of code coverage?
Some teams value test coverage. Some teams don’t care a bit. Some teams care but don’t make them
blockers. Even worse, this decision can vary based on the specific parts of the codebase. It might
be that your team expects high coverage on code written for a new system but is ok with lower
coverage on a legacy system. This is very subjective and situational, so you should take care to
make sure the team has alignment.
A good way to learn from others
Sometimes you don’t understand the purpose of a commmit. This can be a chance to ask questions and
make code review a learning opportunity. Or not.