5 Things I Dislike the Most About Code Reviews

Opinionated comments, double standards, and more

Photo by Andre Hunter on Unsplash.

Firstly, I want to clarify the title. I don’t hate code reviews when they’re done correctly. In fact, I love reviewing code and being reviewed. With a supportive environment and consistent standards, code review can be a pleasant learning experience for both author and reviewer. Proper code review reduces bugs and maintains code base quality.

But in reality, it is often a stressful exercise. Toxic comments from a reviewer can cause constant arguments. In some cases, it causes a breakdown in team communication. Those are the times when I (and many developers I know) hate code reviews.

Here are a few things that I dislike the most about code review.

1. Opinionated Comment From the “I Am Always Right” Reviewer

In my past working experience, many teams have at least one senior developer with excessive ego and/or arrogance. This person can easily pollute the team environment with toxicity via code review.

An arrogant reviewer will try to prove they are better than others via code review. These reviewers tend to keep adding opinionated comments without justification or explanation. Many times, those issues fall into the category of personal preference.

I’ve seen code reviewers addicted to naming conventions or pedantic with over-engineering. They force the other developers to change their code according to the reviewer’s personal preference, even when the code meets the team’s coding standard.

Due to the perceived authority of the reviewer and time pressure to pass the PR, the other developer often gives in and makes the change. It’s a waste of time and effort and will make the other developer feel demotivated. Often, the unnecessary last-minute change due to the review will cause new bugs.

According to GitLab’s best practices:

“Accept that many programming decisions are opinions. Discuss tradeoffs, which you prefer, and reach a resolution quickly.”