Mastering Code Reviews | Article 1: Stop Being a “Human Linter”

If you are a Senior or Staff engineer and you’re still leaving comments like “you forgot a space here” or “use camelCase for this variable,” you are wasting everyone’s time—especially your own.

Seriously. Stop doing it.

I spent years being the “Code Police.” I thought I was keeping the standards high. In reality, I was just a bottleneck. I’d spend an hour hunting for typos and misplaced braces, and by the time I got to the actual logic—the thread-safety issues or the dangerous database transactions—my brain was too fried to catch them.

If a computer can find a mistake, a human should never talk about it in a review.

Why This Rule Exists (The Part Most People Miss)

Every code review spends from a fixed attention budget.

When senior engineers burn that budget on formatting, naming, and trivial style issues, they are actively trading away their ability to catch high-impact failures—race conditions, unsafe state, partial writes, security holes.

Style problems are cheap to detect and cheap to fix.
Production failures are neither.

That’s the real reason this rule exists.
Not politeness. Not kindness. Risk management.

Your time is too expensive for typos

As a seasoned guy, you aren’t paid to find semicolons; you’re paid to make sure the system doesn’t crash. If you’re still acting like a compiler, you’re failing at your job.

Before you even open a Pull Request (PR), your build pipeline should have already handled the “boring” stuff:

• Checkstyle / PMD: To handle the braces, spaces, and naming.
• SpotBugs / SonarQube: To catch the obvious “rookie” mistakes like null pointer risks or ignored return values.
• Modernizer: To stop people from using old-school Java 8 patterns when you’re on a modern version of the JVM.

If the build passes, the formatting is “good enough.” Close your mouth and move on to the logic.

The Rule: Fix the system, not the person

We all have those moments where we see a variable name that’s just slightly off. You want to comment. Don’t.

Instead of leaving a comment on the PR, do one of two things:

1. Ignore it. If it doesn’t break the app and it isn’t confusing, let it go. Merging the feature is more important than your personal preference.
2. Update the Config. If it really bothers you, update the team’s Checkstyle or Sonarrules. Let the machine fail the build next time.

Why this makes you a better leader

When you stop nitpicking, your relationship with the team changes:

• The “Boy Cried Wolf” Effect: If you leave 50 comments on every PR, people start ignoring you. If you only leave three comments, and they are all about a race condition or a memory leak, the team will actually listen because they know it’s serious.
• Velocity: You’ll find that you can clear your review queue in 15 minutes instead of 2 hours.

The Bottom Line

Your job is to protect the system, not the style guide. Reclaim your brain power for the hard engineering problems.

In the next article, I’ll show you my personal ritual for starting a review: Why I check the Jira ticket and the pom.xml before I ever look at a single line of Java code.