Code Review as Conversation, Not as Test

I have been in code reviews where the reviewer's goal was clearly to prove the code was wrong. Every comment was a gotcha. Every suggestion was phrased as "this is obviously the right way." The author spent the whole review defending their work instead of thinking about it.

I have also been in code reviews where the reviewer was genuinely curious about the approach. "I see you went with X instead of Y, what made you pick that?" That opens a conversation instead of starting a trial. Usually the author had good reasons. Sometimes they realized mid-explanation that their reasons were not good. Both outcomes are useful. Neither of them happen if the review is adversarial.

The code review is not a test of the code. It is a conversation about the code. The goal is not to find flaws. The goal is to surface thinking.

What a Conversation Looks Like

When you see an approach that seems suboptimal, the instinct is to correct it. The better move is to ask about it.

Instead of: "This should be async, not sync. Blocking the event loop defeats the purpose of Node."

Try: "I'm wondering about the sync approach here. Are you worried about race conditions from concurrent access? I ask because [specific context about the codebase]."

The first version makes you sound like you know it is wrong. The second version invites the author to explain their thinking. Maybe they have a reason you did not think of. Maybe they did not think of it either and your question surfaces it. Either way, it is a conversation instead of a correction.

The author learns by explaining. You learn by listening. You both end up thinking about the code more carefully than either of you would have alone.

What This Requires

You have to be genuinely open to being wrong. If you write comments like you are always right, people stop engaging. They stop explaining their thinking because they know you are not listening for understanding. You are listening for the moment when you can point out you were correct.

You have to take time. A real conversation is slower than a pass/fail judgment. If you are trying to review five PRs in an hour, you cannot have conversations. You can only have judgments. That is a constraint worth surfacing to the team. If the team is moving too fast for meaningful code review, that is the problem worth solving.

You also have to ask about things you do not fully understand instead of pretending you do. Saying "I'm not sure I follow this section, can you walk me through it?" is uncomfortable. It is also the fastest way to actually understand the code.

What Actually Happens

When the review is a conversation, the code usually gets better. Not because you found more flaws, but because both people thought about it more carefully. The author is defending not their identity but their reasoning. If the reasoning was half-baked, you both know it now and it is easier to change because it is not about the author being wrong, it is about both of you learning something.

The author's next PR will be better because they are thinking about how to explain their approach to you. That is a way more powerful incentive than "I don't want the reviewer to find a flaw."

Your next review will be better because you had a conversation with someone and you learned how they think. You understand their constraints and their priorities. You are not just judging their code, you are building a shared understanding of how to build.

The Tradeoff

Conversation is slower than judgment. A code review that is pure judgment can be done in 10 minutes. A code review that is a conversation might take 30 minutes. That is a real cost.

The payoff is that after a few rounds of conversation, people start thinking about code the same way. The reviews get faster because there is shared understanding. The code quality goes up because people are thinking more carefully. The team is better at explaining itself and learning.

The cost is the upfront time. Most teams optimize for the speed of the review instead of the quality of the thinking. The result is that code review becomes a box to check instead of a place where people learn.

I have been both. The judgment approach was faster. The conversation approach made the team better. The team that did conversation had lower bug rates, faster onboarding of new people, and less frustration about code quality. The speed cost was worth it.

It is a choice about what you are optimizing for. If you are optimizing for review speed, conversation is a waste. If you are optimizing for team learning and code quality, it is the whole point.