Let me start with this – I’m not a huge fan of code reviews as a tool to “check someone’s work”. It’s pretty condescending to walk in at the last minute to offer criticisms. If someone needs help working through a problem, then paired programming is a much better option. With that said – pairing isn’t always possible so there are cases where it needs to be done. There are also times when a developer wants a second (or third) pair of eyes. In order to make the time spent beneficial to both codebase and participants, it’s important to focus on the following outcomes.
The author walks away feeling confident that the code fulfills expectations (possibly with some improvements).
If you are a reviewer you need to put yourself into the mindset that you are there to provide value to the author. Your job is to help the author identify risks and pitfalls in the implementation. This includes bugs, smells, and confusing logic.
However, when it comes to offering opinions or solutions – it’s not as straight forward. Based on the nature of your relationship with the author it may or may not be advisable to share these opinions. Sometimes it’s most helpful to simply bring to light areas that can use improvement and allow the developer to determine how it should be solved. In other cases the developer may wish to have some assistance – it’s up to you to make that determination.
In the end it’s your responsibility as a reviewer to support the authors efforts. This means you need to empathize. Your goal should be to help the author move forward and “have her/his back”. They should walk away with with a clear sense of what the problems that need to be solved are.
The reviewers understand the intent and thought process behind the code.
You may ask, why is it important that I understand what the author was thinking when this code was written? The answer is: this is an amazing opportunity to grow as a leader on two fronts:
First it will help you build relationships – which is very important if you wish to be an effective leader. Taking the time to understand how someone approaches a problem is a good investment and they will appreciate it. It will build trust (as long as you don’t critique how they think..)
Second it will open your mind to other ways of thinking. You may not realize that the author was considering something you had not. While we may be able to improve our skills on our own we can’t expand “how”” we think about things without outside perspective. I can think of no better time to do so when reviewing work someone else has poured time and energy into.
The end result should exceed the status quo.
A code review should produce suggestions for improving code. It should result in better code.
An exceptional code review will produce new perspective and trust. It should result in stronger bonds among teammates.
Comments by mark