Code Review Series: Thank your reviewer

What?

First, let me clarify what I mean here. I don't mean you need to get up and walk over to your reviewer and say "Thanks for the review" (but you certainly could, I don't see any harm in that).

What I mean is, be receptive to your reviewer's feedback. Be open to their suggestions. Be appreciative. Approach the review in a positive manner - with appreciation - not resentment. Be grateful for code review.

How?

First of all, you need to remember (or realize) that code review is not an attack on your intelligence.

You also need to understand that code review is not a productivity killer. While you may feel like it is a time-suck in the present, it actually saves lots of time in the long run.

Code review is an acknowledgement that we are all just human. It is the action that corresponds to the idea that “2 heads are better than 1”.

Also - remember that code review is a learning opportunity.

If being receptive to feedback does not come naturally to you, one way to "fake it until you make it" is to start all of your responses to code review feedback with the phrase "Thank you". This will help you to set the tone of your response. Start with "Thank you for the question" or "Thanks for the suggestion" or "Thanks for catching this!" and then jump into your response.

Try to develop an attitude of welcoming code review. Of wanting all of your mistakes to be found. Do your absolute best writing the code, and then pivot to "now please help me find everything wrong with it!" or if that is too negative for you, you can go with "now please help me find everything that can be improved!"

If someone approves your code without any comments, that is not a time to celebrate, that is a time to be disappointed or suspicious. (Of course, sometimes the code change is so minor or boilerplate that it doesn't warrant any feedback - but I assume you have enough perception to know that's not what I'm talking about in these blogposts.) In this scenario, the reviewer has shortchanged you - not done you a favor (as they might mistakenly think).

The Don'ts of Receiving a Code Review (basically: Be a good sport)

• Don’t insert a tone into someone’s review feedback. Assume the best possible intentions, assume all questions are genuine, assume all suggestions were made without any hostility or arrogance or superiority. Don't interpret anything as accusatory or belittling.

• Don’t take any of the feedback personally. The feedback is about the code. Not you.

• Don’t be defensive. If you find yourself rejecting every suggestion the reviewer has given, this is a big, red, flashing, neon sign telling you that you are probably being defensive. Reconsider opening your mind a bit. Maybe walk away and come back with a fresh attitude.

• Don’t be a poor sport about several iterations of review (expect it).

• When your reviewer points out something wrong - fix it EVERYWHERE in your PR, not just in the one place they pointed it out.

Why?

Your reviewer is intended to be a representation of "someone who didn't write this code". Meaning that, if they don't understand the code, there is a good chance that the other devs on your team won't understand it either (potentially including your future self!). Unclear code slows down everything - and it's not very fun to deal with.

Your reviewer also has a fresh set of eyes. They are going to see things you don't.

Rather than being annoyed by code review or looking at it as a nuisance, take advantage of it. It will help you to have higher quality output. And it's also full of learning opportunities.

What if my reviewer actually is a huge jerk?

I think this topic probably warrants its own dedicated blogpost. So I'll try and address this in the next one.