I once spent an entire afternoon arguing with a junior dev about whether to use a ternary operator or an if-else block, feeling incredibly superior while the actual logic error that was about to tank our payment gateway sat untouched three lines below. We weren’t actually reviewing code; we were just performing an expensive, ego-driven ritual. Most “best practice” guides on how to review someone else code kindly tell you to use more emojis or “soften” your language with “maybe” and “perhaps,” as if being polite is the same thing as being helpful. That’s not kindness; that’s just polite inefficiency, and it’s how we miss the bugs that end up waking us all up at 2 AM.
I’m not here to give you a list of magic phrases to make your comments sound less aggressive. Instead, I want to talk about shifting the focus from “what you did wrong” to “how we make this system more resilient.” I’ll share what I’ve learned from fifteen years of seeing good intentions turn into production incidents, focusing on how to provide technical clarity without the ego. My goal is to help you write reviews that actually improve the codebase rather than just testing how much friction your teammates can tolerate.
Table of Contents
Reducing Ego in Code Reviews to Save the System
The problem with most code reviews isn’t the technical logic; it’s the subtle, unintentional hierarchy we build with our comments. I’ve seen it happen a dozen times: a senior dev leaves a comment that sounds less like a technical inquiry and more like a reprimand. When you frame a suggestion as “You should have done X,” you aren’t just correcting code; you’re attacking the person behind the keyboard. This is where we fail at improving developer psychological safety. If a junior engineer feels like they’re being judged rather than mentored, they’ll stop taking risks, they’ll stop asking questions, and eventually, they’ll stop growing.
To fix this, we need to treat the code as a separate entity from the author. I’ve found that shifting the focus from the person to the system is the most effective way to handle this. Instead of saying “Your loop is inefficient,” try “This loop might cause a bottleneck if the input size scales unexpectedly.” It’s a small distinction, but it changes the entire dynamic. We aren’t here to win an argument about who is smarter; we are here to ensure the service stays up. Reducing ego in code reviews isn’t about being “nice” for the sake of politeness—it’s about maintaining a clear, objective channel for information so we can catch errors before they become incidents.
Effective Peer Review Communication When the Stakes Are High
When the system is actually down, or when we’re pushing a change to a legacy payment gateway that hasn’t been touched in three years, the tone of a PR comment changes everything. In high-stakes moments, it is tempting to lean into “command and control” language—telling people what they must do. But that usually backfires. Instead of focusing on the fix, the author starts defending their competence. I’ve learned that effective peer review communication isn’t about being polite for the sake of politeness; it’s about keeping the focus on the code so we can resolve the incident without a side quest into someone’s feelings.
If you see a critical flaw during a hotfix, don’t use passive-aggressive phrasing like “it might be better if…” which just obscures the urgency. Be direct, but keep the target on the logic, not the person. Use asynchronous communication best practices to your advantage by providing the “why” immediately: “This loop will cause a timeout if the payload exceeds 5MB; let’s add a limit here.” This approach is a core part of improving developer psychological safety. It turns the review from a trial into a collaborative debugging session, which is exactly what you need when the pressure is on and the logs are screaming.
Five ways to stop being a pedant and start being a teammate
- Ask questions instead of issuing commands. “Change this to a map” sounds like a directive from a superior; “Would a map make this lookup faster here?” invites a technical discussion. I’ve found that when I frame things as inquiries, I often realize I was actually the one who misunderstood the context.
- Separate the logic from the linting. If you’re spending your mental energy pointing out missing semicolons or trailing whitespace, you’re missing the race condition hiding in the loop. Use an automated formatter for the trivial stuff so your comments can actually focus on whether the code is going to crash the payment gateway.
- Use “we” to share the burden of the codebase. Instead of saying “You didn’t handle the null case,” try “How do we want to handle the null case here?” It shifts the perspective from a personal failure to a shared engineering challenge. We’re all trying to keep the system upright.
- Acknowledge the good parts. If a solution is clever or particularly readable, say so. I’ve had many days where a single “this is a really clean implementation” in a PR comment made a stressful week feel significantly more manageable. It’s not about empty praise; it’s about marking what we should replicate.
- Contextualize your “why.” Never just say “this is bad.” If you see a pattern that looks like it will cause a memory leak under load, explain that specific risk. A critique without a reason is just an opinion, and opinions are what turn code reviews into ego battles.
The post-mortem mindset for reviews
Treat every comment as a way to harden the system, not as a way to correct a person; if you can’t frame your feedback around preventing a future incident, you’re probably just arguing about style.
Replace “You should do X” with “I’ve seen X cause a race condition in production before, what do you think about this approach instead?” to move the focus from their mistake to the shared technical risk.
If a discussion is going in circles for more than three comments, stop typing and get on a call or walk over to their desk; some things are too expensive to solve through a screen.
The Long View
At the end of the day, code reviews aren’t about winning an argument or proving you’re the smartest person in the room. They are about the mechanical reality of keeping the system running. We’ve talked about stripping the ego out of the process, focusing on logic rather than syntax nitpicks, and communicating with a level of clarity that prevents misunderstandings when things go sideways. If you can shift your focus from “what is wrong with this person’s code” to “how do we make this specific implementation more resilient,” you’ve already won half the battle. It turns a potentially adversarial interaction into a shared engineering task.
I’ve spent enough years in the trenches to know that the codebase will eventually outlive all of us, and the culture we build during these reviews is what actually determines how much sleep we get. Be the person who leaves a comment that helps a teammate understand a trade-off, rather than the one who just points out a mistake. We are all just trying to build something that doesn’t break at three in the morning. If we treat each other with a bit of professional grace, we spend less time fixing broken egos and more time fixing the actual problems.
Frequently Asked Questions
How do I push back on a design choice I disagree with without making it a personal attack on the author's competence?
Shift the focus from “you” to “the system.” Instead of saying “your approach is inefficient,” try “I’m worried this pattern might cause a bottleneck when our throughput doubles next quarter.”
At what point does "being kind" cross the line into letting technical debt slide just to avoid an uncomfortable conversation?
Kindness isn’t about being nice; it’s about being clear. If you see a shortcut that’s going to bite us in six months, staying silent to avoid an awkward chat isn’t being “kind”—it’s being complicit. That’s how we end up with a legacy mess that nobody wants to touch. Frame the critique around the system, not the person. “This works now, but it’ll break our scaling later” is a technical observation, not a personal attack.
How should I handle a situation where a senior engineer's code is actually the thing that's going to break the system?
Stick to the data, not the hierarchy. If a senior’s PR looks like a landmine, don’t make it a battle of wills; make it a discussion about the failure mode. Instead of saying “this is wrong,” try “I’m worried this specific edge case will cause a deadlock under high load.” Frame it as a shared technical risk. If they push back, ask for the mitigation plan. If the system breaks, the seniority won’t matter.
How do we keep the review process from becoming a bottleneck that slows down the entire sprint?
The biggest mistake is treating a PR like a formal thesis defense. If you wait until a feature is “perfect” to ask for eyes, you’ve already lost the sprint. I’ve learned to push small, incremental changes rather than 2,000-line monoliths that require a PhD to approve. Also, establish a “triage” rule: if a comment isn’t about a potential production failure or a fundamental logic flaw, it’s a suggestion, not a blocker. Move on.
