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 t...
For further actions, you may consider blocking this person and/or reporting abuse
Yeah, this is spot on. Too many teams act like they’re doing quality checks, but really it’s just seniors showing off. Half the stuff people argue about in reviews doesn’t even matter in production. If we all just focused on real bugs, real risks, and actually helping each other get better, most PRs would move way faster and people wouldn’t dread reviews. It feels like a lot of this could be fixed if teams just agreed on what actually counts as a blocker instead of letting everyone’s personal taste run the show.
Exactly. Focusing on real blockers and collaboration over personal taste would save so much time and actually help people grow. Reviews should empower, not intimidate.
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.
I understand why you'd see my comments that way, but I still believe it's worth making those comments on this post, given the listed examples. I am in no way saying that this post is invalid, I'm just pointing out that it starts by talking about junior developers leaving and makes a number of comments that are about trusting professional developers - I'd hoped my comment made the differentiation between those two groups that I considered when I read it and made my response.
If a junior implemented a project completely wrongly, then yes, it would be the fault of their mentor or team lead. Still, juniors often just use a pattern that is less appropriate as a small part of their solution - some state management, some variable or function name that doesn't mean what it says - this is how we all get better, I think.
Sure there are some sections where the post could be more nuanced. I think the exaggeration is fitting within the narration voice of the post.
I think people can see that it is more a be cautious tale than a manual you need to follow.
Really appreciate the take and yeah I agree with a good chunk of it. When a junior is genuinely missing an architectural concept or writing something that doesn't fit the codebase, absolutely, that is a teaching moment. Patterns, conventions, consistency - all of that matters, and good reviewers should help guide them.
My issue isn’t with that kind of review.
It’s with the ones that claim to be about architecture, but are really just stylistic preferences in disguise. “Use this pattern because I like it,” vs “Here’s why this pattern matters in our system.” Those two feel very different in practice.
and your point about not throwing the baby out with the bathwater is fair. i mean code reviews done well do shape strong dev/engineers. and the fact that your team stay, grow and understand the architecture deeply after years under your leadership says alot.
This post was aimed at the opposite of the spectrum - teams where reviews stop being guidance and turn into gatekeeping. sounds like yours isnt one of them, and honestly that's super refreshing to hear!
Thanks for taking the time to respond. I liked the post (literally and physically) because I've seen a lot of poor code review behaviours, and I read it mostly thinking "yep." I commented just to point out that a few of the points we've now discussed can have a legitimate basis. I can imagine a disgruntled junior grumbling about a code review that they should actually care about, so I wanted to make that point.
Early on, you talk about "treating people as professionals" - I couldn't agree more, respect for people who aren't juniors is more about asking about why a pattern was chosen, not showing power through rejections and checklists. (Oh, God, checklists issued by holier-than-thou colleagues for no legitimate reason.)
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.
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.”
Beautifully put.
and yeah you're right, this dynamic shows up everywhere not just in tech. any environment where an authority is used to assert hierarchy instead of build capability ends up teaching people how to survive than how to grow beyond it.
What you said about hazing is important too. People internalize that behavior, then replicate it when they become seniors, leads, or supervisors. It becomes cultural muscle memory.
Thanks for sharing this, it adds a layer of humanity to the conversation that often gets lost in the technical framing.
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 😅
Interesting to read
Yes. Feel free to go. Company hire me to do that. If they can’t do that, I’ll help to point out the wrongdoings but don’t be to sensitive. Code smells are valid concerns. You can low your bar but never spread it as a standard. Maybe next time give a head up before you review, lol.
Fair point on code smells, but there’s a difference between pointing out problems and tearing people down. Reviews should build code and confidence, not just ego.
You must see it is their problem that they can’t do a quality pull request and being offended when someone points out their mistakes. I guess they will be less offended when an AI agent reviews their work instead since no human is involved. It’s a psychology thing.
Type of stuff everybody thoughts but nobody talks about!