Code Reviews: Making Your Team Better Instead of Worse

Code reviews used to be my favorite thing to avoid.

I'd submit pull requests and want them merged ASAP. I'd review others' code and either rubber-stamp them or be weirdly aggressive about pointing out every tiny thing.

I was doing it all wrong.

Then I started working with someone who did code reviews differently. They weren't about finding bugs. They were about making us better developers.

Everything changed.

Code Reviews Aren't Actually About Finding Bugs

Well, they are. But that's the side effect, not the point.

Tests find bugs. Linters find style issues. Code reviews find something deeper: they make you think about your code differently.

When someone questions why you solved something a certain way, you start questioning it too.

That's growth.

The Vibe Matters More Than You Think

I've seen code reviews that were demoralizing. Comments like "this is wrong" or "why did you write it this way?" made people feel stupid.

Then I've seen code reviews that were encouraging. Same feedback, completely different vibe: "Great approach here. Did you consider this edge case?"

The difference: Experienced reviewers explain the why. They're teaching, not judging.

Code review comments should sound like:

• "I'm not familiar with this pattern. Help me understand it."
• "I like how you handled this. Here's another approach that might be simpler."
• "This could be a performance issue because..."
• "Could we abstract this further?"

Not:

• "Wrong way"
• "Bad code"
• "Why would you write it like this?"

Understand Intent First, Implementation Second

Before I dig into details, I understand: what is this code trying to do?

Then I check: does it do that? Is it the best way?

I've seen people reject perfectly good code because they would have written it differently. That's not the job of a code review.

What Actually Matters to Review

Correctness:

• Does it do what it's supposed to?
• Are there edge cases?
• Error handling?

Performance:

• Will this scale?
• Obvious inefficiencies?
• Database query issue?

Security:

• Input validation?
• Auth/authz?
• Exposed secrets?

Maintainability:

• Clear what this does?
• Would another developer understand it?
• Overcomplicated?

Tests:

• Actually testing the code?
• Edge cases covered?

What NOT to Review

• Formatting - use a linter, not humans
• Style preferences - 1 space vs 2 spaces
• Naming of private functions - minor details
• Personal preferences - "I would have written it differently"

Let tools enforce style. Save human review for things tools can't check.

Review Your Own Code First

Before asking someone to review, review it yourself with fresh eyes.

Usually I find:

• Something I missed
• A simpler way to write it
• A comment that needs clarifying

This saves everyone time. Your code is better before it even gets reviewed.

Responding to Feedback Matters

When someone suggests a different approach, it's not an attack on your skills.

Engage with it:

• "That's interesting, here's why I chose this approach"
• "I didn't think of that, let me try it"
• "I see your point, but I think this is simpler"

The best teams argue respectfully about code. Both defending your choices and being open to feedback are healthy.

When to Approve

I approve when:

1. The code does what it's supposed to do
2. No obvious bugs
3. Not worse than existing code
4. I'd feel okay deploying this to production

Sometimes that's 95% ideal. That's okay. Perfect code is expensive. Good code shipped beats perfect code that never ships.

When to Block

I block when:

1. It will definitely cause production issues
2. Obvious security problems
3. Clear codebase pattern being ignored
4. Tests don't match code changes

Everything else is negotiable.

Getting Better at Code Reviews

• Review every line - even if it looks fine
• Ask questions - "what does this do?" clarifies intent
• Suggest, don't demand - "what if..." instead of "you must..."
• Be quick - slow reviews are demoralizing
• Learn from disagreements - someone codes differently? You might learn something
• Compliment good code - people need to know what they did well
• Remember the person - there's a human on the other end

The Best Code Reviews I've Done

I remember one where someone suggested a refactor. We discussed. They showed me three approaches. We tried one. It was genuinely better.

We both learned something. The code got better. The relationship got stronger.

That's the goal.

---

Your code reviews reflect your team culture.

Make them kind, thorough, and focused on growth.

Your code will be better. Your team will be better. People will actually want to work with you.

That's worth more than catching every bug.