The Code Review That Changed How I Lead

Early in my career as a technical lead, I conducted a code review that I'm still not proud of. The code was messy. The engineer was junior. And my review was thorough, technically correct, and completely destructive.

I left twenty-something comments. Most of them were some variation of "this is wrong" without explaining why or suggesting an alternative. The engineer was demoralized. Their next few PRs were timid and over-engineered — they were so afraid of criticism that they paralyzed themselves.

That experience changed how I think about code reviews, mentoring, and leadership.

Code Reviews Are Conversations, Not Audits

The fundamental mistake I made was treating the code review as a quality gate instead of a teaching opportunity. Yes, the code needed to improve. But the goal of a code review isn't just better code — it's a better engineer.

Now, my approach to reviews follows a few principles:

Ask questions instead of making statements. "Why did you choose this approach?" is more productive than "This is the wrong approach." Sometimes the engineer has a good reason you didn't consider. And even when they don't, the question helps them think through the decision themselves.

One lesson per review. If I see ten things I'd do differently, I pick the one or two that matter most and focus there. Overwhelming someone with feedback doesn't help them grow — it makes them defensive or defeated.

Praise what's good. I always find something positive to call out. Good variable naming, a clever test case, a thoughtful error handling pattern. People learn faster when they know what they're doing right, not just what they're doing wrong.

The Mentoring Multiplier

As I moved into architecture and leadership roles, I realized that the highest-leverage thing I could do wasn't writing better code myself — it was helping others write better code.

One hour of thoughtful mentoring with a junior engineer produces years of improved output. The design patterns you teach them, the debugging strategies you share, the architectural thinking you model — all of it compounds across every line of code they write for the rest of their career.

What I Teach

When I mentor engineers, I focus on principles rather than technologies:

Think about the reader. Code is written once and read many times. Every naming choice, every abstraction, every comment should optimize for the person who reads this code six months from now — who might be you.

Understand the failure modes. Before you write the happy path, sketch out what happens when things go wrong. What if the database is down? What if the input is malformed? What if this function is called with null?

Test the behavior, not the implementation. Tests that assert on internal implementation details break every time you refactor. Tests that assert on behavior survive and provide real safety nets.

Learn the domain. The difference between a junior engineer and a senior one isn't just technical skill — it's domain understanding. Invest in learning the business context of what you're building.

The Ripple Effect

That junior engineer I demoralized with my early code review? They eventually became a strong mid-level engineer — no thanks to that review, and largely thanks to a more patient mentor who picked up where I failed.

But the experience gave me something valuable: empathy for the vulnerability of putting your code out for review. Every PR is someone showing their work and asking, "is this good enough?" How you respond to that question shapes their confidence, their growth, and their relationship with the craft.

Lead the review you'd want to receive.