Code reviews to become a better developer
In my experience, participating in a code review is the most effective way to level up as a developer. If you’re the creator of the reviewed changes, you can get direct feedback from your colleagues. And if you’re one of the reviewers, you can learn different approaches you might not have thought of on how to solve implementations.
But correctly giving and also understanding a code review is a skill that has to be learned. In this article, I’ll simply list some aspects I consider when giving and receiving code reviews. From my point of view, they’ve proven to be the right choice for a collaborative and welcoming development environment.
What I define as good code
Remember that there’s nothing more permanent than a temporary workaround.
The following key metrics are guiding me when writing and reviewing code.
- the code is maintainable, e.g. no hacks or workarounds however well documented
- the code is easily readable, thus reasoning about it is much easier
- the code is testable, thus further improving the previous two points
How to give a code review
Be humble
Being wrong isn’t a problem. Insisting that you’re right even though you’re objectively not is a problem. Always keep in mind that you might miss something or simply misunderstood the code. Be open for pushback and be humble for the chance to learn something new.
Code reviews are not personal
Remember: the code comes first. You might review someone’s code in a tense situation where both of you are not in the mood to talk to each other, or are generally in a disagreement about the current way things work.
Code reviews are not the place to let off some steam or to pay back frustrations. The sole purpose of reviews is to objectively improve the code quality. The code you review and that will be merged is the next legacy code, therefore it’s important to leave personal things aside and provide an objective review, no matter who’s the reviewee.
Opinions are not reviews
A key difference between a good review and just a comment is that reviews leave out opinions. For example, it doesn't matter how the code style looks, as long as it’s maintainable, easily readable and testable. If you’re not sure if your review would be opinionated, simply add a remark so that you can discuss the point with your colleague.
Good reviews lead to good discussions
Challenging a review can lead to great knowledge transfers between developers. A given review shouldn’t be treated as a final comment but rather as a starting point for discussions to get the whole picture. Both of you might miss something and discussing the criticism can only improve your insights.
Deadlines don’t matter
Not always easy to enforce, but skipping code reviews can potentially create a large technical debt no one will be willing to clean up. It is important to maintain the necessary discipline to give thorough code reviews even if you hear the clock ticking. You might be the next developer to work on this mess!
Use links for references
Comparing the reviewed code to existing one happens quite often. It’s therefore important to correctly include references via links. Only mentioning the approximate place where the referenced code is located doesn’t cut it.
Use your source control’s feature to highlight code on an existing branch and use the created URLs in your review for reference. The same applies to external documentation, for example on MDN.
How to read a code review
All of the above
Reading code reviews of your code makes you a better developer when you follow all the aforementioned points. Be humble, don’t take criticism personally and strive to understand what a review points out to better understand the big picture.
A personal opinion of how to be objective
This article reflects my personal approach on code reviews. The outlined points are just a culmination of my experience as a developer in teams large and small, both locally as well as international. They’ve proven to work, leading to better code and giving me the opportunity to directly learn from others.
