Let's talk about what's really happening in your code reviews.
You know that junior who just quit? The one who mentioned in their exit interview that your reviews made them feel like they'd never be good enough? Yeah, that happened on my team. And before you think "well, my juniors love my feedback," ask yourself: would they actually tell you if they didn't?
This isn't about pointing fingers. Well, you know what, actually - it is. Because too many senior developers have turned code review into a performance art, and it's time we called it out. I'm guilty of this too. But that doesn't mean we shouldn't shine a light on what's happening across the industry.
🎭 The Theater of "Best Practices"
Here's the pattern. A junior submits a PR that solves the problem elegantly. Tests pass. Logic is sound. Then you roll in with:
- "This variable should be
userDatanotuser" - "Can we make this more functional?"
- "I would've used a factory pattern here"
- "Hmm, interesting approach..." (Translation: "This is wrong but I want to sound thoughtful")
Meanwhile, the actual bug they missed? The edge case that'll crash production? You didn't catch it because you were too busy debating whether their function should be called processData or handleDataProcessing.
You're not reviewing their code. You're performing your expertise.
⚔️ The Nitpicking Power Trip
Let's be honest about what code review has become for many seniors: a weapon. Maybe not intentionally malicious, but the impact is the same.
The Perfectionist's Playground
Every PR becomes an opportunity to demonstrate how you would've done it better—not how to make their code better.
You sneak in obscure patterns you just learned. You reference architectural decisions from your previous company as if they were universal truths. You leave comments that are really just you thinking out loud, not actionable feedback.
The Moving Goalpost Game
- 🥇 Round 1: "Use more descriptive names"
- 🥈 Round 2: "Actually, these names are too verbose"
- 🥉 Round 3: "Can you just rewrite this whole function?"
- 💀 Round 4: They've given up and are updating their résumé
Sound familiar? If you're doing this, you're not "maintaining standards." You're hazing people.
The Silent Treatment
Three days. No comments. No approval. Just... silence.
You tell yourself you're "too busy" or "need to think about it more." But really? You're procrastinating on the hard work of giving good feedback. And that silence? It gives you power. It makes you the bottleneck. It makes people wait on you.
That's not leadership. That's gatekeeping.
🚨 The Real Problems You're Ignoring
While you're arguing about syntax sugar, here's what you're not asking:
- Does this actually solve the user's problem?
- Are we introducing technical debt?
- Is this even the right feature to build?
- Will this scale?
- Did anyone test beyond the happy path?
But sure, argue about whether this should be a class or a function. Because those debates make you feel smart. The hard questions? Those require actual thought.
🤷♂️ "But Code Quality!"
Yeah, everyone justifies it with "code quality."
But here's what you're actually creating:
- Junior devs who learn to write code that passes your review, not code that's good
- A team where real learning stops happening
- An environment where innovation dies under the weight of your preference-based nitpicking
You're not raising the bar. You're just moving it around to stay relevant.
🧪 The Ego Test
Your review culture is toxic when:
- You block PRs over style preferences that aren't in any style guide—they're just your preferences
- Your comments focus on how they did it, not whether it works
- You approve garbage from other seniors while eviscerating juniors for the same mistakes
- Discussion threads become longer than the diff itself—because you can't let go
- You find yourself thinking "if I don't find something wrong, people will question why they need me"
If you recognize yourself in any of these, congratulations: you're part of the problem.
✅ What Code Reviews Should Actually Be
Code reviews should:
- Catch bugs & security issues (you know, things that matter)
- Share WHY certain approaches are better, not just assert that they are
- Verify the solution fits the problem
- Ensure tests actually test what matters
- Be a dialogue, not a lecture
Notice what's missing?
Proving you're smarter than the author.
🌱 What a Good Review Actually Looks Like
What most seniors write:
"This won't scale. Rewrite using the repository pattern."
What mentorship looks like:
"Nice fix! One concern: this queries the database in a loop, which might be slow with lots of records. Could you batch it? Happy to pair on it if helpful—here's what worked for us before: [some link]. But if there's a reason for this approach I'm missing, let me know!"
The first is gatekeeping. The second is collaboration.
Which one are you doing?
🌑 The Uncomfortable Truth
Most review comments are performative.
They're cover-your-ass disguised as quality control. They're you protecting your position as the "senior" who knows better. They're you afraid that if you don't find something wrong, people will question why they need you.
And yes, I've been guilty of this too. But recognizing the problem doesn't absolve any of us from fixing it.
🤔 Questions to Ask Before You Hit "Submit"
Before you leave that next review comment, force yourself to answer:
- Am I reviewing to improve code, or to show off?
- Is this comment useful or just critical?
- Am I blocking over preferences or real issues?
- Would I accept this code if another senior wrote it?
- Will this comment help them grow, or just make them feel small?
If you're honest with yourself, you'll probably delete half your comments.
🧾 The Bottom Line
Good code review:
- catches bugs
- spreads knowledge
- improves systems
- builds confidence
Bad code review:
- hazes people
- slows teams
- protects egos
- drives talent away
Sometimes the best review you can give is:
"Looks good, shipping."
And when you do have feedback, lead with what's working before you mention what needs work. Ask questions instead of making pronouncements. Treat every PR author like the capable professional they are.
Here's the challenge: Go look at your last 10 code reviews. Really look at them. How many of your comments were about actual problems versus personal preferences? How many times did you ask questions versus make demands? How many PRs could have shipped a day earlier if you'd focused on what mattered?
The job of a senior developer/reviewer isn't to be gatekeepers. It's to open gates. It's to build people up, not tear them down. It's to use our experience to make the team better, not to prove we're the smartest person in the room.
The question is: are you doing that?
Or are you just running your own ego Olympics, and calling it code review?
Top comments (10)
If that is the review, that person should not be a senior of anything.
It doesn't matter if you are doing code reviews with whatever level of experience, the main goal is to have the right code.
Agreed. regardless of experience level, the goal of a review is to help the code (and the developer) get better, not throw patterns around without explanation. The best reviews are the ones that explain the why, not just the what.
Really enjoyed this take — especially the distinction between quality control and ego. One thing I’d add is that so many review conflicts happen simply because the context isn’t clear.
When reviewers don’t know the rationale behind a piece of code, the review becomes opinion vs. opinion. When they do know the rationale, it becomes collaboration.
Teams that bake context + lightweight documentation into their workflow avoid most of the ego friction altogether. The review becomes about improving the system, not defending the change.
Great piece! While reading it, I kept catching myself thinking: “come on, that’s an exaggeration - who even does that?!” - and then I realized I actually know at least a few people like that 😅 Plus, of course, zero room for discussion: “it has to be the way I say it, or the PR gets rejected.” 🙃
Well, as a mid-level developer myself, I used to leave quite a lot of comments because I thought that’s just how it’s supposed to be 😄 Fortunately, I’ve grown out of it.
haha I had the exact same reaction while writing it — “surely no one actually behaves like this”… and then remembered multiple real-life examples 😅
That “my way or the PR gets rejected” energy is exactly what turns reviews into mini dictatorships instead of collaboration.
…and btw, you calling yourself mid is the funniest thing I’ve heard all week 😭
😂 haha no no, I'm not THAT modest, I was mid a couple of years ago 😅
Not sure I agree with all of this - if we are talking about a junior developer and they've implemented something in a pattern that isn't right for the code base, or used variable naming that doesn't fit with our standards, then it is a learning moment for them and an important one. It might be that they hadn't fully grasped an architectural concept or hadn't met the underlying requirements of our solution - it works, it's reasonably elegant, but it isn't a fit, is something I want a code review to enforce.
I agree that style over content isn't right, of course, and I can imagine that some people will perform as you say, I've seen it often and been the recipient of it myself - I'm just saying don't throw the baby out with the bath water.
I believe that this works, 60% of my team have been, at some point, junior developers in my organisation. In the 3.5 years I've been in charge, we haven't lost any, and the progress and understanding of our architecture have been first-rate.
i think you missed the point of the post. Correcting someone in a code review is not the problem. It is doing it without explanation. It is possible a developer didn't understand the concept or the solution. But if it is something they haven't used/done before, I think it is more the fault of the senior/teamlead to pick up on it and make them understand before they started. They shouldn't have spend the time to create a solution that is wrong.
There’s a difference between reading something as information and reading it as confirmation.
For you, this article may have been cathartic—a confession and a call-out. For me, it’s simply accurate. A description of weather I’ve been standing in for a decade.
And it doesn’t stop at code reviews or even this industry. I see the same dynamic in healthcare, where supervisors “flex” their power by degrading rather than empowering. The impact is the same: people learn to survive the hazing, not to grow.
It’s demeaning to endure, and yet perversely instructive in the climb—because maybe that’s the point: we don’t want you climbing any higher.
Whether in tech or medicine, the pattern repeats. The real question is whether we’re willing to break it, or just keep calling it “quality control.”