Mastering Code Reviews | Article 7: Debug the Code, Not the Person

After a decade of leading Java teams, I’ve learned that the moment a code review feels like an “attack,” the engineering process has already failed.

As a seasoned guy, I approach every Pull Request with one mindset: We are all on the same side against the bug. I am not “reviewing” a human being; I am debugging a system alongside a colleague. When you stop blaming people and start debugging logic, the whole culture of the team shifts from “fear” to “problem-solving.”

1. The “Us vs. The Bug” Mentality

If I see a dangerous race condition in a Spring service, I don’t say “You forgot to synchronize this.” That makes the developer the problem.

The Senior Move: I say, “I think we have a race condition here if two threads hit this singleton at once. How can we make this thread-safe?”
The Result: It shifts the focus to the technical puzzle. We are now two engineers working together to protect the JVM.

2. “Why” is a Question, Not an Accusation

When you see a weird architectural choice, don’t assume the developer was “lazy” or “didn’t know better.”

The Senior Move: Ask for the context. “I noticed we are calling the repository directly here instead of the service. Was there a specific blocker that made us do this?”
The Result: You might find out there’s a legitimate technical reason (like a circular dependency) that you didn’t see. You are debugging the architecture, not the person.

3. Use the “Machine” as the Bad Guy

If you have to enforce a standard (like naming conventions), don’t make it a personal argument or a matter of “your opinion.”

The Senior Move: Refer to the System Standard. Instead of “I don’t like this name,”say “The team’s Checkstyle config expects camelCase here. Let’s update it to match so the build passes.”
The Result: It removes the ego. It’s just another “failed test” that needs to be fixed.

4. Stop the “Nitpick” Wars

If you are arguing about where a brace goes, you aren’t debugging; you’re bickering.

The Senior Move: If the logic is sound and the data flow is safe, but the code is just “ugly”—let it go.
The Result: You save your energy for the battles that actually matter (like security and performance).

Why this matters

When you focus on debugging the code instead of blaming the person, you change the “Bus Factor” of your team.

Trust: People stop hiding their mistakes. They’ll come to you earlier because they know you’ll help them solve the problem, not judge them for it.
Velocity: Less friction means faster merges. You stop wasting time on 20-comment threads about “preferences” and spend more time shipping.
Retention: Engineers stay at companies where the culture is collaborative. Blame-heavy environments drive away the best talent.

The Bottom Line

At the end of the day, we are all just trying to ship stable Java apps and get some sleep. The code will eventually be deleted, but the engineering culture you build by being a “collaborative debugger” is what actually scales a company.

Don’t review to be right; review to get it right.