I once wrote about how I've stopped nit-picking in code reviews, which improved the signal-to-noise ratio and helped everyone get along better.

I’m back with a third reason to ditch the practice: nit-picking wastes time.

By definition, nitpicks are about minor problems: poorly named variables, slightly confusing logic, bits of duplicated code, that sort of thing. (If the feedback was about major issues, they wouldn’t be nitpicks!) But I’ve come to realize that minor problems don’t really affect the overall health of your codebase:

  • Minor problems have a small blast radius. A problem localized to a single function, class, or module isn’t going to virally infect the codebase. Sure, it’s annoying to anyone working on that part of the code, but it won’t trigger a meltdown, or be the cause of a big refactor.
  • Minor problems might never cause any trouble. Maybe a function is written sub-optimally but no one ever modifies it again. It lives its life for a few years, only to be deleted in a feature rewrite, never causing anyone heartburn.
  • Minor problems can be easily fixed later. If it turns out you do need to fix it, you’re not gonna struggle. That poorly named variable is one refactor away from resolution. The function was confusing, but rewriting it doesn’t affect any other code. De-duplication is a rote activity.

Every nitpick takes time to write; then the author has to take time to respond or act to the feedback. If the value of the change is near zero, then the nitpick is wasting everyone’s time.

Yet, the notion of letting nitpicks slide is hard to swallow because you can prove that the code is suboptimal! Why wouldn’t you fix something that is wrong?!

If we all had unlimited time & energy: sure, fix it all! But I sure don’t have that, and neither does anyone else.

(As an aside: dreams of unlimited time & energy are why backlogs grow infinitely. People won’t archive tickets, even if no one will ever resolve them.)

Taking the time to go back and perfect your code means sacrificing what you could’ve been doing otherwise, like addressing major problems, fixing bugs, or writing features. As is always the case in software development (and life in general), prioritization is key - focusing on what matters and letting slide what doesn’t.