The way I see code reviews, is that they are a great cover for learning, mentoring _and_ finding interesting quality issues in your code. If our main goal as leaders is to grow our teams, then code reviews are a great way to grow team members, by helping them gain many skills: how to mentor others, how to communicate better, Not being shy about asking questions, stopping hoarding knowledge and much more.
You should leave a code review either feeling like you've learned something new, or that you've shared something new, or that you've caught something stupid, or too smart, and you're more proud of the codebase.
To achieve all these great benefits there are some important points you can't neglect:
- To increase learning on many levels from each other, code reviews are always between at least two people (sometimes a third person can join in to learn how to review), sitting side by side. Not in different work stations, not in different offices and not in different buildings. Those learnings can be as simple as "how did you do that with the keyboard?" to "why would you even do that?" to "I didn't even imagine that's something you could do"
- To increase code quality and remove the chance of forgetting to implement them, code review comments are taken care of either _during_ or right after the code review has ended
- To increase focus and energy, code reviews should be short. 30 min. is almost too long. 5-15 min. is good. To do that you'll need to make sure that code reviews cover smaller parts of the codebase. One way to achieve that is by reviewing on every check-in, so that the batches to review are smaller.
- To increase overall team proficiency and share knowledge, code reviews are done by all members of the team to all other members. At least, that's the long term goal (within 2 months it's possible to achieve for a team of 10).
If you want to get started with code reviews, and read how I'd recommend teaching everyone to review each other's code, I expand on those things here.
What about all those code review tools out there? I don't use them and never have. If you use them, you're missing out on the most important part of code reviews, the interaction with other people to learn and teach something. Remove that interaction, and you're left with a dead, boring feeling of having to look through someone else's list of boring things they think you got wrong. Who has time for that?