Why do we review code? Here are some of the reasons:
- To find bugs and fix problems in code before it’s deployed.
- To get and give feedback on the system architecture.
- To mentor and train developers.
- To be aware of how some part of the system works.
Clearly a big part of code review is giving feedback on code. This often includes pointing out mistakes and areas of improvement. From experience I know that receiving this kind of feedback sometimes hurts. It can hurt even when given by a person with the best intentions.
It’s easy to end up defending yourself to avoid feeling hurt. However, if you refuse to admit your mistakes, you won’t learn anything. This is why there must exist a certain level of trust between the person giving the feedback and the person receiving it. The person receiving the feedback must feel safe to admit their mistakes.
This is especially important when your team includes juniors, who tend to feel more insecure about their skills. Then again, if the senior people in your team do not feel safe to admit mistakes, you’re in for some serious trouble, since their mistakes are likely to have the biggest impact.
See also my commandments for code review.