The Uncomfortable Truth
Your Code Reviewer Is Right More Often Than You Think
You just got feedback on a PR and your chest tightens. Your heart rate kicks up a notch. The reviewer’s tone feels harsh, their suggestions seem to completely miss the point of what you were trying to accomplish, and there’s this part of you (maybe a big part) that wants to defend every single line you wrote. You want to type out a paragraph-long comment explaining why they’re wrong, why your approach is actually brilliant, and why they clearly don’t understand the problem you were solving.
Been there? Yeah, me too. More times than I’d like to admit.
The Real Source of the Pain
Here’s the thing the Stoics figured out a couple thousand years ago, and it still holds true when some senior dev is tearing apart your pull request: that discomfort you’re feeling right now? It’s not actually coming from the criticism itself. It’s coming from your judgment that you’ve been wronged. That your competence is being questioned. That this must mean something about your worth as a developer.
And that’s where we screw ourselves over.
Because the truth is, most code review feedback, even the harshly delivered stuff, contains something useful. But we can’t see it because we’re too busy nursing our wounded pride and mentally drafting our defensive response.
Mining for Gold in a Pile of Shit
What if you could extract every ounce of value from harsh feedback while discarding the emotional poison that comes with it? That’s the skill we need to develop.
First thing: you have to learn to separate the messenger from the message. A rude delivery, or even what you perceive as rude delivery, doesn’t automatically invalidate true insights. I’ve gotten feedback from people who had the communication skills of a brick, but their technical points were solid. Your job is mining for gold, not judging the miner’s manners.
Ask yourself this: is any part of this criticism true? Even 10% true? Because here’s the thing, even 10% accuracy in criticism is a gift. It’s information you didn’t have before. It’s a chance to improve your code before it hits production. Dismiss nothing until you’ve honestly examined it against reality.
I know how easy it is to get caught up in the emotions. To feel like your code’s being attacked. Like your self-worth is being questioned. I’ve been there, sitting at my desk, feeling that heat rise in my face, already mentally preparing my rebuttal. But that’s when you need to pause and ask: is there something here I can actually learn from? Is there a point buried in this feedback that, if I’m being honest with myself, is actually valid?
Maybe this person has a point. Maybe there is a better way to structure this. Maybe my first instinct wasn’t actually the best approach.
Your Critics Are Your Trainers
Here’s a reframe that’s helped me: view your critics as personal trainers for your code. They’re adding resistance that makes you stronger, even when it’s uncomfortable as hell. You don’t go to the gym expecting the trainer to tell you you’re perfect, you go expecting them to push you harder than you’d push yourself.
Same thing with code reviews.
I’ve learned to practice what I call “the grateful opposite.” Instead of getting defensive, I try to thank people for catching bugs, architectural flaws, or blind spots before they become production problems. Because at the end of the day, that’s what matters, producing the best quality code possible. It’s not about satisfying our own egos or proving we’re the smartest person in the room.
It’s very easy to get caught up in that. Trust me, I’ve dealt with ego battles over a long career. But over time you start to understand: I’m here to do a job. I’m here to do it well. My job is to produce the best quality product I can deliver, and if anyone can help me do that, even if they’re kind of an asshole about it, I’m going to take full advantage of that opportunity.
Not All Feedback Is Created Equal
Now, let’s be real for a second. You do need to distinguish between preference and principle. Some feedback is subjective style preferences; tabs versus spaces, this naming convention versus that one. And some reveals actual defects in your reasoning or approach.
I’ve had plenty of situations where feedback was just nitpicky bullshit. Someone commenting on variable naming when the real issue is whether the algorithm is efficient. In those cases, I don’t focus on it too much. But even in those nitpicky comments, I look for whether there’s something being pointed out that I could do a little better. Is there a better way to execute this, even if the specific suggestion isn’t quite right?
Epictetus said it best: if someone criticizes you unjustly, that’s their problem. But if it’s justified, thank them for the free education.
When We Get Too Close to Our Code
Here’s what happens to me all the damn time: I get blinded by my own work. You get into that tunnel vision of coding where you’re locked in, cranking out line after line, building this thing in your head. And then somebody comes along and points out that maybe you’re overthinking it. Maybe you’re writing too much code. Maybe there are things you could better reuse or ways to eliminate code versus actually creating more of it.
And they’re right. But it stings because you were so deep in your own solution that you couldn’t see the simpler path.
Use criticism as a mirror. When you have a defensive reaction, that reaction reveals where your ego is attached. That’s big data about yourself that’s worth examining. Anytime something triggers you, and I mean really triggers you, makes you want to write that defensive comment, you should evaluate why.
Is it really because this person has it out for you? Or is it because you’re too emotionally attached to the code you wrote?
Nine times out of ten, it’s the latter.
The “Try It First” Approach
Here’s something I’ve started doing that’s been genuinely helpful: implement the suggested approach first, even if you disagree with it. Just try it. Because sometimes your resistance isn’t actually technical judgment, it’s pride masquerading as technical judgment.
I’ve had situations recently where I look at a suggestion and think, “I don’t necessarily 100% agree with this approach.” But at the same time, it’s not really worth fighting over either. It’s very easy to get caught up in this subjective battle, this ego-driven mindset of “my way is the best way and this person doesn’t know anything because I’ve been doing this for 15 years and they’ve only been doing this for 3 years.”
Who the hell cares?
If their approach makes sense when you really think about it, when you set your ego aside and evaluate it objectively, just make the change. There’s no sense fighting that battle. There are so many things we should be focused on trying to be better at. There are some things you just need to learn to let go of.
The Culture That Feeds Our Defensiveness
Let’s zoom out for a second and talk about why this is so hard for us as developers. We’re operating in a culture that constantly reinforces ego-driven behavior.
Tech Twitter is full of hot takes about the “right” way to do things. There’s this mythology around “10x developers” who supposedly produce perfect code and never need feedback. We see conference talks from people making everything look effortless. GitHub stars and follower counts become weird proxies for technical competence.
All of this feeds into an environment where admitting you might be wrong, where accepting that your first approach wasn’t perfect, feels like weakness. Like you’re not one of the smart ones.
But that’s BS. The smartest developers I know are the ones who actively seek out criticism. Who treat every code review like an opportunity to level up. Who check their ego at the door because they understand that the goal is shipping great software, not proving they’re right.
What This Actually Looks Like in Practice
So what does this look like day-to-day? For me, it’s a constant practice. I still have that initial defensive reaction, I don’t think that ever fully goes away. But I’ve learned to recognize it and pause.
When I get feedback that makes my stomach clench, I take a breath. I read it again, this time looking specifically for what might be valid. I ask myself: “If my best friend gave me this exact same feedback over coffee, how would I receive it differently?”
Sometimes I’ll even sleep on it. Let the emotional reaction fade a bit before I respond. Because responding while you’re still in that defensive headspace? That’s how you write comments you’ll regret, or dig in on positions that aren’t actually defensible.
And when I do find myself getting into a back-and-forth debate in PR comments, I try to remember: this isn’t a courtroom. Nobody’s keeping score. The goal isn’t to win the argument; it’s to end up with better code than what I started with.
The Payoff
The more you practice receiving feedback without ego, the better feedback you get. People are more willing to give you honest, detailed reviews when they know you won’t get defensive. They’ll point out subtle issues they might have otherwise let slide because they didn’t want to deal with pushback.
And that makes you better. Faster. Your code improves more quickly because you’re not wasting energy on defending your choices. You’re using that energy to actually evaluate and implement better approaches.
Plus, and this is huge: it makes code review way less stressful. When you’re not treating every piece of feedback as an attack on your competence, when you’re genuinely curious about what you might learn, the whole process becomes less painful. Sometimes even enjoyable.
Your Turn
I want to hear from you because I know I’m not alone in struggling with this:
What’s your biggest challenge when receiving code review feedback? Is it certain types of criticism, or feedback from specific people, or just the general feeling of being judged?
Have you ever had feedback that initially pissed you off but later realized was actually spot-on? What made you come around?
What strategies have helped you separate your ego from your code? Any mental tricks or reframes that work for you?
Share your thoughts in the comments. Because honestly, we all need to get better at this. The developer who can receive feedback without getting defensive is going to grow faster, ship better code, and probably enjoy their job a hell of a lot more than the one constantly defending their territory.
At the end of the day, the person most likely to hold you back isn’t your code reviewer—it’s you.
Quote of the Day:
“If anyone can refute me—show me I’m making a mistake or looking at things from the wrong perspective—I’ll gladly change. It’s the truth I’m after, and the truth never harmed anyone.” - Marcus Aurelius
👉 If you enjoy reading this post, feel free to share it with friends!
Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏
You can find me on X and Instagram.
Also, I just launched a new YouTube channel - Code & Composure