7 tips to have your code better reviewed (recovered post)

Note: This post has been recovered from my archive after having been lost due to my brain injury. It was originally posted in my old development blog on September 25, 2017.

Code reviews take time. Of course. But they are helpful. Very helpful. They are a fantastic way to keep all the team on the same page and encourage everybody to do the right things and to do them correctly. Here you have some tips I’ve learn through the years to avoid my code reviews to become painful or useless:

1. Create reviews for all the code you push. No, seriously: do it. Some companies or teams have this process semi-automated or very established as part of its tech culture. If they don’t, ask your manager to do so. And if she responds that it’s a bad idea, run out of that company!! NOW!!.

   Remember: Most of the times optional code reviews means no code reviews.

2. Create your reviews early and often. Don’t wait to have a monster with a million of lines of code. Several small, specific changesets, are way easier to review than one big changeset with lots of changes. Also, your changes will more likely be accepted if you divide them into several smaller steps.

3. Review your own code before showing it to your teammates. Imagine you receive that code from another person to be reviewed for the first time. Be your best reviewer, be critical with your code. Take your time.

4. In order to avoid noise, use your IDE to identify possible bugs. Modern IDEs analyze your code in order to find possible warnings or bugs. If your IDE does not analyze it automatically, pass your code through a static code analyzer.

   If your team uses a code formatting standard, use an automatic formatting tool to format it. This will allow your teammates to concentrate on the really important things and avoid silly conversation threads about coding style.

5. Prepare your review. I mean, not only add the code or the changesets you want to review. Link the review to the corresponding ticket and/or explain the feature you’re trying to add, focusing on implementation details that maybe are not in the ticket, but are relevant. If there is some piece of code which is not obvious, you should explain why you did it that way and not differently.

6. Carefully select the people you want to review your code. If there is a policy for that, follow it. Most of the cases, however, not everybody in your team needs to review your code.

   People who probably needs to be included in your code review includes your manager, some people with experience in the related product domain, the original author of the piece of code you’re touching (or just someone who touched the code before) and anyone who is developing another related feature in parallel (ask for that if necessary).

7. Don’t take it personally. It’s your code what is being reviewed, not you. Long comment threads in a review doesn’t mean someone hates you or wants to annoy you. More probably, it will mean she disagrees with you in some specific technical thing. Be nice, assume the best intentions on the reviewer and answer all the comments pleasantly.

   Be ready to learn from others. Be grateful on the good suggestions and express your arguments clearly, but with politeness, if there’s something you honestly don’t agree with.