When does an opinion become a nitpick?

Posted on: 11 September 2026

I was subtly linked to this blog post on Nitpicking in Code Reviews by a colleague recently. Which was all the confirmation I needed that I can be a little OCD sometimes when it comes to code reviews.

This post highlights some excellent points, reinforced by incorporating the changes as a team and it working wonders for them. TLDR: Stop nitpicking in code reviews. It’s at best noise, and at worst, misdirectional and harmful to developers’ patience and self-esteem.

So what is nitpicking in code reviews? As Dan, the author of the blog post, points out. Nitpicking “isn’t about code that is wrong but suboptimal.”

My initial reaction to this blog post was disagreement. I believe code quality is defined by doing lots of little things right. Over time, this results in a quality codebase. But perfection is never the goal, and the pursuit of it can become toxic to workplace culture. Whilst doing small things right is important to the long term health and cleanliness of a codebase, it’s not the primary objective of code review.

Code review should find issues in code. Logic that is wrong. Missing test coverage. Things that will age badly under scale and/or extension of the code over time. Nitpicking does not find these problems.

I realised I have the tendency to nitpick. If I read code that I might’ve written slightly differently, I feel an urge to point this out. “Nits” rarely highlight code that’s wrong, instead it’s simply not optimal in the eye of the beholder.

Developers are human

One of the points Dan highlights so well in the post is the notion that developers are in fact not cold, hard, logical machines, but “humans with unavoidable feelings and emotions”.

What was I really doing when I was thoroughly nitpicking code? The main effect wasn’t improving the codebase; it was making people upset with their code and angry with me.

We can all stand to be more empathetic to our colleagues. If you’re having a bad day and open up a PR you’ve shared to discover 10 nitpicking comments, but nothing actually wrong with the code, it grinds you down. I can attest to this personally; both sides of the coin.

So how do we take care of the “nits” ourselves?

Nits can encompass many things, but by-and-large, it’s not following the code conventions of a project. How do we best fix this? On a sliding scale of caring (most to least):

1. Incorporate checks into your IDE linter and/or Git pre-commit hook. This all but guarantees convention-violating code does not make it in front of other team members to critique.
2. Add a linting check in your CI pipeline. This is what we use at Arena, and I like this for the consistency it brings. No extra integration required locally for developers, and everyone gets reviewed the same by the linting bot. We use Codacy, which offers suggestions of how to fix convention-violations, which is helpful, but can be noisy in the code review.
3. You don’t. How much do they really matter? If this option is chosen, it needs to be made clear in code review that convention-correcting comments are not welcome. This puts the onus on the author of the change to ensure conventions are upheld (or not).

Dan’s suggestion is to automate what you’d otherwise nitpick, and I think this is the best solution. He concludes:

Ultimately, our codebase has not suffered due to a lack of nitpicking. If anything, it is better than before because we, as a team, work together better and focus on the important parts of code design in our reviews.

My conclusion: sometimes you come off as a jerk, even if you don’t mean to. When reviewing code, search for real problems and let go of the rest.