Ask HN: How do you do code reviews without getting silly over little things?

Do you work at my company? :)<p>I don&#x27;t know how to solve it, but it&#x27;s insane. Especially for teams with high churning (typical in Silicon Valley where everybody constantly leaves for better opportunities), the code review culture changes from month to month depending on who&#x27;s the latest &quot;super picky specialist&quot; on the team, with terrible dips in productivity.<p>The managers are not too involved with the code review process themselves and they pat themselves in the back just for seeing &quot;very active and healthy code reviews&quot;, as measured in terms of review comments.<p>The problem is that code that 100% functionally works, with proper tests and good readability, gets blocked for weeks by __completely__ unproductive people who don&#x27;t do anything other than driving a personal agenda of demanding abstract levels of refactorings. Everyone in software should have learned at this point that your fancy abstractions don&#x27;t provide any benefit, since they won&#x27;t solve your future problems anyway. Just make sure you refactor where you would otherwise be facing physical duplication of code&#x2F;logic, and you&#x27;ll be 100% good.<p>I&#x27;ve been victim of this myself lately: I&#x27;m known for writing code that is as simple as it can be, while maintaining functionality, scalability and correct handling of corner cases: I don&#x27;t do abstract interfaces for the sake of it, I couldn&#x27;t care less about factories, ...<p>Sadly, it&#x27;s forcing me to likely look for opportunities out of my current company.

Nitpicky code standards should be the realm of automated sniffers and fixers.<p>Besides that there is no magic wand here. You have to do the work to create a good culture of code reviews in your team. This is not science, this is your engineering lead promoting good review practices and cracking down on harmful ones.

My experience with code reviews is that they always became adversarial. I tried to implement code reviews in my group many times and it didn&#x27;t provide a lot of value.<p>We finally did it by using GitLab and requiring that every merge request to master must be reviewed by two team members. This provided code review on every piece of code instead of only on select pieces. GitLab allows us to enforce it easily, but the process can be done anywhere.<p>The nit-picky code reviewer gets overwhelmed defending his point of view and starts being a little more selective. The lazy programmer gets overwhelmed with constant changes and actually starts paying more attention. Somewhere along the way it has actually balanced out.<p>Discussions have allowed us to identify poor practices, new techniques, and implement some standards.

Great question and thank you for making the rest of us think about it because it can become unnecessary or burdensome when used inappropriately.<p>I personally eschew the trivial or otherwise stupid company standards in favor of more language&#x2F;community set standards (think PEP8). When I do criticize I will lead more with “what was your reasoning behind &lt;this block of code&gt;” because you get a more honest response and sometimes you’ll get the author to admit to “oh I was just being lazy there” or “do you have a better way of writing that”. Code reviews are a necessary evil but how you approach them can change the outcome.

&gt; I&#x27;ve literally seen companies consider any change made in a code review to be a bug fixed so you get folks who pride themselves on flagging things in code review even though there is zero, and often negative, substance to the flag.<p>Do you not push back when this happens? You should be allowed to ignore some review comments. I think marking comments with priorities help (e.g. must fix vs could fix). When the reviewer knows you&#x27;ll be reviewing their work as well this can help stop them being unfair.