I hear a lot of complaints about it.
It's harsh, it demotivates people, it slows down shipping. And in some cases, that's true.
When code reviews are used to gatekeep or show superiority rather than improve the work, they're genuinely harmful. That's not okay, and I'm not going to defend that.
But I think something gets lost in those complaints. Something worth examining.
The Woodworker's Table
Imagine you're a hobbyist woodworker. You've spent weeks building a table. In your mind, it's perfect. Exactly how you envisioned it. But before you let your family sit around it at dinner, you invite a professional woodworker to take a look. Someone with ten-plus years of experience creating tables. You ask for their honest opinion.
They walk around the table, run their hand across the surface, and check the joints. Then they give you their feedback.
The leg structure isn't positioned to distribute weight evenly. The wood hasn't been treated properly, so the color will fade within a year. The technique works for a shelf but not for something that needs to bear this kind of load.
Your first reaction? Frustration. Maybe even anger.
This is my first table. I'm not a professional. Why are they being so harsh?
Then you take a breath. You realize you asked for their honest feedback. And you know that if you use the table as is, it might collapse one evening with your kids sitting around it.
The story is fictional, but I think it maps pretty well to what happens in a code review (give or take). Someone with more context (not always more experience, but more context about that specific area) looks at your work and tells you what they see. Not to be cruel. Only to protect the thing you're building from the things you couldn't see yet.
The code review protects us from ourselves.
The code review is there to catch what we miss when we're too close to the problem. Our excitement about a clever solution. Our limited knowledge of a system we've only touched for a few days. Our frustration with a task that's taken longer than expected is pushing us to just get it over with.
I've been on both sides of this. I've submitted code I knew wasn't ready because I was tired of looking at it. And I've reviewed code where the problems were obvious to me because I'd made the exact same mistakes six months earlier.
That's the thing people forget. The reviewer isn't judging you from some position of superiority. They've been where you are. Most of the feedback they give comes from their own past mistakes and experience.
Taking it Personally
The first challenge I've noticed is that engineers take review feedback personally.
This is a completely natural response, especially when you're not used to receiving direct feedback on your work. But it limits your thinking. When you're focused on defending what you wrote, you stop being able to see what you could improve.
I remember at least a dozen reviews early in my career where senior engineers left a comment saying my approach was "unnecessarily complex" or way too brittle. At first, I'd try to often prove them wrong. But after a while, I realized I was compensating for my ego instead of trying to create the best solution for the problem.
This type of compensating often costs me hours, hours that I could've put towards other work. Nowadays, a code review for me is a learning opportunity, where I want people to find the things I missed, so that we as a team can deliver the highest possible quality.
Respecting the Reviewer's Time
The second challenge is one that doesn't get talked about enough: respecting the reviewer's time.
This is partially driven by delivery pressure. There's always a deadline, always a stakeholder asking when it'll be done. But that pressure doesn't change the reality that someone is about to spend their time reading your code, understanding your decisions, and giving you thoughtful feedback. That's a gift, not an obligation. And it comes with a cost.
I've seen too many pull requests where the author clearly didn't review their own code before requesting a review. Leftover debug statements. Commented-out blocks. TODO comments that should have been addressed. An entirely broken CI. Things you'd catch in thirty seconds if you just read through it one more time.
My approach is simple. Once I think I'm done, I step away. I go get a coffee or work on something else for a bit. Then I come back and review my own pull request as if someone else wrote it. I leave comments explaining trade-offs I made. I catch the obvious stuff before anyone else has to.
This does two things. It shows the reviewer that I value their time as much as my own. And it often catches problems I would have been embarrassed to have someone else find.
A Learning Opportunity, Not a Chore
The third challenge is maybe the most important one: code reviews have become a chore instead of a learning opportunity.
A review comment you don't understand isn't an interruption. It's the start of a conversation. An approach you've never seen before isn't confusing; it's a chance to learn something new or understand something better.
I've learned more from asking "Why did you suggest this?" in a code review than from most technical articles I've read. Those conversations, where someone walks you through their reasoning, where you push back, and they explain further, where you both arrive at something better than either of you started with. That's where real growth happens.
And it goes both ways. Some of the best technical discussions I've ever had started with a junior engineer asking me "why?" on a review comment I left. Forcing me to articulate my reasoning made me realize that sometimes I didn't have a good reason. I was just pattern-matching against habits I'd never questioned. I also might not have explained it properly, because if I make a comment, it should be obvious to the reader what that comment means. Otherwise, it's just noise.
Shipping Still Matters
I want to be clear about something. I understand that shipping matters. Deadlines are real. Business pressure is real. I'm not arguing that every pull request needs a three-day philosophical discussion.
But catching issues early in the process is significantly less painful than a 2 AM incident with four people on a call trying to figure out what went wrong. The code review is one of the cheapest places to find problems. Cheaper than staging. Cheaper than production. Infinitely cheaper than a postmortem.
The thirty minutes a reviewer spends on your pull request might save your team ten hours later. That's not slowing down. That's investing.
I've been doing code reviews for years now, on both sides of the table. I still learn something most of the time. Not always something technical. Sometimes, it's about communication, about how to give feedback that helps instead of hurts, about how to receive feedback without letting my ego get in the way.
The code review isn't perfect. But when it's done with mutual respect, genuine curiosity, and a shared goal of making the work better, it's one of the most valuable things we do as engineers.