In 2019 I gave a talk about code reviews to the Chicago PHP group. At the time, a part of my job was to facilitate code reviews for my teams and teach good practices so folks receiving the code reviews felt like they were getting actionable feedback and not just opinion soup.

Code reviews are vitally important for many reasons, and for me one of the most underrated, or under utilized tools in an engineer’s toolbox. Reviews can catch bugs before they hit production, it can encourage better test coverage, and it can ensure the code is actually doing what is required for the feature.

Often reviews only focus on the naming and code style aspects. Which is great and a necessary component of a review, but this is also where people have the most opinions. Here I would recommend you and your team, or better yet, your organization adopt a code style that can eliminate some of the opinions and peacocking on naming and style.

For engineers reviewing code, there are several benefits to being thorough and detailed. You provide mentorship to more junior folks, or new engineers to the team. These people joining a new team may feel like they are behind and anxious that they are not providing code to the level perceived by the team. Especially if they get a review with the comment "This thing is broken". That's not very helpful.

It helps with learning. I cant tell you how often I was reviewing something and didn't understand the syntax used. After researching it, I found a new way to do the thing. I also subscribe to the learning method in the medical field: See one, Do one, Teach one. Where reviews are on the third pillar of that system.