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.)
Great topic to highlight. I completely agree, this happens far more often than we like to admit.
I’d add the "ego Olympics" don’t exist only in PRs, maybe that’s where they’re most visible. Sadly, they show up in every corner of our industry (and I’ll limit my take to our industry this time). Ego appears in attitudes like "never use this language/framework" or "this is now a bad practice." When an industry is driven by show off, "performance" reviews, and "impact" metrics, it’s hard to expect people not to fall into these behaviors, often without even realizing it.
Again, this is a very good topic, and I think it can be extrapolated to many other aspects of our work. At the end of the day, we work as a team, and empathy is one of the most important, and most lacking, soft skills.
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.
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.
Good code reviews are a systems problem, not a personality one.
When a team lacks explicit standards and architectural intent, reviews collapse into preference debates by default. At that point, people aren’t evaluating code — they’re negotiating taste and hierarchy.
Strong teams externalize intent early: conventions, constraints, and “what actually blocks a merge.” Then reviews shift from judgment to signal detection. Less ego, more throughput, better learning.
Most review toxicity isn’t malice. It’s missing structure.
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 😅
This is a great topic. When done right, code reviews are about improving quality and sharing knowledge, not showing superiority. A respectful review culture helps teams grow and makes the codebase stronger for everyone.
Amen!
Interesting to read
The main point for me in here.
I am a gate keeper - that's a (imho: bad) company design here, but anyhow I need all my devs to stay focused and motivated to make things work out in the end.
For me that means that I show myself vulnerable and challengable - so we can talk about things.
So tell my why you did that in your way and we are going to have a discussion. Perhaps it's me who is wrong and your approach is the better one in this case - otherwise I need to convince you or the entire team at all.
Sure, it is hard after decades programming "in your personal way" and being promoted because of that to lead teams and people, but you still need to adopt new ideas and ways.
Anyhow - isn't it another anti-pattern to talk to your people not until the code review? Do they fear to ask you in beforehand?
This is exactly it. Sharing the why, staying open to being challenged, and talking before the review changes it from gatekeeping into collaboration. Reviews shouldn’t be the first time people feel safe to disagree.
Type of stuff everybody thoughts but nobody talks about!
Somebody had to put it into words!
Wrote a post about how to make code review process efficient dev.to/nicolasbonnici/how-to-code-...
This article is spot on! Much development teams suffer a lot from code flavor disagreements.
Also at the moment what does code syntax even mean if AI can read mostly everybody its code syntax.
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.
Pointing out mistakes is another thing that should also be done without the ego tone.
But what I'm saying here is that some mistakes, when pointed is not really about mistakes but rather about the reviewer's own style preference and it's even bigger problem when they decided to make so much big of deal that the PR had to be blocked from being merged.