Collaborate, Evolve, and Learn to Enjoy the Process
The more communication and constructive criticism that happen in a code review, the better. You will be a better developer for it. Your colleague will become more adept at giving feedback and reading code.
In the end, you, your reviewer, and the product will benefit.
You should not be resistant to feedback on your code. This is a process that has been proven to catch bugs, produce higher-quality code, and increase the programming skill of everyone involved.
Don’t believe me?
I’m willing to bet that there has been at least one time in your history as a developer where you learned something on a CR.
Maybe your colleague left a comment and enlightened you on the use of a new function that reduced a massive 12-line block to just four.
Maybe something different happened and a senior engineer told you to expand that clever little one-liner you wrote into multiple lines for better readability.
You’re bound to learn something when getting feedback on your code — especially if you are passing your review to a more senior, experienced person.
If you’re still skeptical, check out this fantastic piece by Atlassian (the creators of Jira) on Why Code Reviews Matter.
Here are some of the benefits for everyone and everything involved in the code review process.
What benefits do you receive?
- You get a deep, targeted analysis of your design choices by someone familiar with the codebase.
- You get direct feedback on your syntax decisions.
- You get advice on code efficiency with potential ways of improving it.
- You get (at the very least) a basic analysis of code security.
- In some cases, your working relationship will improve between you and your reviewer. You might even make a friend!
- Peace of mind knowing that you had at least a second set of eyes on your work before it hits production.
What benefits does your reviewer receive?
- Your reviewer gets better at reading and understanding code.
- Your reviewer learns more about other development styles.
- Your reviewer learns more about the codebase.
- Your reviewer has the opportunity to collaboratively improve new or existing code.
- Your reviewer gains more ownership and responsibility for the codebase.
What benefits does the product receive?
- Your product receives more gatekeepers to potential bugs.
- Your product receives well-thought-out code with optimized efficiency.
- Your product receives (in most cases) more secure code.
- Your product receives code that is easier to maintain.
- Your product receives more overall ownership and visibility for different parts of the codebase.
These lists are not exhaustive. It’s unlikely you’ll see all of these benefits in every single CR. You will see some in each CR, and over time, you will begin to notice you’ve experienced almost all of them.
Also, don’t limit your code reviews to only one person. Don’t always ask the same person either. If you need a second opinion or a different part of your code requires a different engineer, then place that person on the review.
A Guideline to Live (Code) By
This leads me to an incredibly important guideline: Always place the person who is closest to the code on the review.
What does this mean?
If you are editing a section of code that some other engineer wrote, it is a good idea to put that engineer on the code review. If that person isn’t available, you move on to the next closest person — another person who touched the file or a different part of the function.
Go straight to the source (pun intended). Have a subject matter expert review the change.
Don’t place a random engineer or your best friend on the code review because it’s convenient. This might be faster, but it’s a terrible idea.
If you ask someone who is far removed from the code, they may not even understand it. They may not even be proficient in the language it is written in. This leads to a problem that may not seem like a problem: They’ll approve it. This is not what you want when you ask for a code review. You’re asking the wrong people just because you know they’ll give you a rushed, surface-level review and approve it quickly. This defeats the entire purpose of the review.
The Right Feeling
Placing the right people on the CR kicks off an intense but rewarding feedback loop process. The code enters the loop, it gets reviewed, you make changes, and repeat.
Sometimes, this feels brutal. It feels like it will never end. You just want to ship this damn feature. Keep going. Stay in the loop as long as it takes.
It should feel like this. You’re not a programming god. Your code is not perfect from inception. Stay in the feedback loop and you will end up with a much more polished, efficient, and secure piece of work.
Thank you for reading!