5 Traits of a Bad Code Reviewer
Code review is a widespread practice for most current projects. In all teams that I have worked with, it was mandatory. But that does not mean that it was always good. Or even a bit helpful.
Why is that? Because of the developers’ attitude towards this process. In some cases, it was not only a waste of time, but it made things worse.
This article will look at some red flags that may indicate that a person is not doing that good job as a code reviewer.
Let’s roll!
1) Reviewing only from the technical side
Code review is not only about code quality. That’s an important part, and you should not neglect it. But code review is so much more than that. It’s about ensuring that the code you are checking will do its job. If you are reviewing a piece of new implementation, make sure you familiarize yourself with the business requirements of that feature and check if the written code matches those requirements.
That’s tedious — you may think. But no one said that code review is an easy process. It’s complex. And a responsibility.
The easiest way to check if a person correctly understood business requirements is to check unit tests. First of all, are they present? Do they include edge cases?
By looking at the unit tests, you can easily understand whether the developer has considered all the possible outcomes of their code.
2) Not taking responsibility
Code reviews are generally part of your job. And it’s your responsibility to do that job well, which means that superficially glancing over the code is not enough. Even since you press that ‘Approve’ button, you become as responsible for that code as the one who wrote it, and if any serious problem occurs — you will be equally to blame.
So you either invest enough time into this process or deny doing it altogether.
Don’t do a half-ass job.
3) Using “I don’t like this” as an argument
There are so many ways to do the same thing — indeed, more than one. And yes, it may so happen that another person prefers another method. There is no tragedy here. And no need to start a holy war over a pattern used, or even the lack of it. Is the code easy to understand? Does it meet requirements? Then everything is ok. Would you do it differently? That doesn’t matter.
4) Not taking time restrictions into account
We always want to make things better. But you have to think about the priorities. So when you are doing a code review, always consider the current situation on a project. If there is plenty of time, there is plenty of room for improvement. But if we are on a deadline, asking a colleague to re-implement a feature from scratch is just reckless.
5) Not being polite
Remember, you are checking someone’s days of work. Even if there are mistakes or the code is terrible, this is still your colleague. Always show some basic respect.
My rule of thumb is leaving comments in the form of a question.
“Maybe it’s better to do this in another way?” sounds much better than “Do this in another way!”.
After all, you want to maintain a good relationship with your team.
Briefly
When doing a code review, check both technical implementation and code’s compliance with requirements. Be attentive, as you are responsible for your review. Don’t waste time arguing about best practices — there are more opinions than one. Consider current project status and suggest massive changes only if there is time to make them. And of course, always be polite.
