A Code Review Is Not a Test You Set

I remember sitting in a dimly lit office in 2008, staring at a pull request that felt less like a technical critique and more like a personal indictment. The comments weren’t about logic or edge cases; they were a series of sharp, condescending “nits” that made me want to close my laptop and never look at a compiler again. Most management training tells you that being “kind” means being soft or avoiding conflict, but they completely miss the point of how to review code kindly and usefully. In reality, true kindness in engineering isn’t about sugarcoating a mistake; it’s about having the technical precision to point out a flaw without making the person behind the keyboard feel subhuman.

I’m not here to give you a list of polite emojis to sprinkle on your comments. I’ve spent twenty years untangling legacy payment systems and fixing the messes left behind by “brilliant” developers who couldn’t communicate, so I know exactly where the friction lies. I’m going to show you how to strip away the ego and focus on the actual breakage. We’re going to talk about how to provide feedback that actually improves the system, rather than just making the author feel defensive.

Reducing Ego in Technical Discussions Before It Starts

The problem usually starts before a single line of code is even written. I’ve spent two decades watching “architectural debates” devolve into ego battles, often because we treat our code as an extension of our identity. When you view a pull request as a personal critique rather than a technical audit, you’ve already lost. Reducing ego in technical discussions isn’t about being “nice”; it’s about decoupling your self-worth from your variable names. If you can’t separate “I wrote this mistake” from “I am a bad engineer,” you’re going to make the review process toxic for everyone involved.

One way I handle this is by shifting the focus from the person to the system. Instead of saying “You didn’t handle this edge case,” I try to frame it as, “The system might fail here if the database connection drops.” This subtle shift is a core component of improving developer experience through code reviews. It moves the conversation from a trial of character to a shared problem-solving exercise. We aren’t here to police each other’s intelligence; we’re here to make sure the payment gateway doesn’t crash at 3:00 AM.

When Soft Skills for Software Engineers Save the Sprint

I’ve spent enough time in legacy payment systems to know that a sprint doesn’t usually die because of a logic error or a race condition. It dies because of friction. You can have the most brilliant architectural fix in the world, but if you deliver it with a tone that makes your teammate feel defensive, that fix is going to sit in a PR loop for three days. When we talk about soft skills for software engineers, we aren’t talking about being “nice” for the sake of it; we are talking about maintaining the velocity of the team.

A single poorly phrased comment can derail a developer’s focus for the entire afternoon. If a junior engineer feels attacked, they stop taking risks, and suddenly your codebase becomes a graveyard of “safe,” mediocre code. This is where psychological safety in engineering teams becomes a tangible technical asset. When people feel safe enough to admit they don’t understand a specific implementation, we catch bugs before they hit production. It turns a potential week-long debugging nightmare into a five-minute conversation.

The Reviewer’s Survival Kit: Five Ways to Not Be the Problem

• Stop using “You” as the subject of your critiques. “You didn’t handle the null case here” feels like a finger pointed at a chest; “The null case isn’t handled here” focuses on the logic. It’s a small linguistic shift, but it keeps the conversation on the code rather than the person’s competence.
• Distinguish between a “Must Fix” and a “Should Consider.” If I see a way to refactor a function that isn’t strictly necessary for the ticket’s requirements, I label it as a suggestion. Don’t block a PR because of a stylistic preference that isn’t codified in our linter.
• Always explain the “Why” behind the “What.” Telling a junior dev to “Use a Map here instead of a nested loop” is a command. Telling them “Using a Map here reduces the complexity from O(n²) to O(n), which matters as this table grows” is a lesson. If you don’t explain the consequence, you’re just being pedantic.
• Look for the “Good” too. If someone implemented a particularly elegant way to handle a race condition in our payment gateway, say so. If you only comment when things are broken, your presence in the PR queue becomes a source of dread rather than a quality gate.
• Check your own assumptions before hitting ‘Comment.’ I’ve spent many hours debugging legacy code only to realize I didn’t understand the original context. Before you call a pattern “bad,” ask yourself if there is a hidden constraint—like a weird database quirk or a legacy edge case—that makes that “bad” pattern necessary.

The Post-Mortem of a Bad Review

Review the logic, not the person; if your comment starts with “You should have,” you’ve already lost the technical argument to your own ego.

Prioritize “why” over “what”; pointing out a bug is a service, but explaining the edge case it creates is where the actual engineering happens.

Distinguish between a preference and a defect; if it’s just a different way of writing a loop that doesn’t break the system, mark it as a ‘nit’ or leave it alone.

## The Difference Between a Bug and a Person

“A pull request isn’t a deposition of your intelligence; it’s just a map of where the logic hits a wall. If your comment focuses on the broken edge case rather than the developer’s competence, you’re actually helping them build something that won’t crash at 3:00 AM.”

Pernille Askeland

The Long Game of Code Reviews

At the end of the day, a code review isn’t just a gatekeeping exercise or a way to prove you know more about the legacy database than the person who wrote the PR. It is about moving the needle forward without leaving a trail of resentment behind you. We’ve covered how to strip the ego out of the discussion before the first comment is even typed, and how prioritizing human connection can actually keep a sprint from collapsing under the weight of technical debt and bruised feelings. If you focus on the code rather than the person, and if you approach every “nitpick” with the intent to teach rather than to correct, you stop being a bottleneck and start being a force multiplier for your team.

I’ve spent two decades looking at code that was written in a rush, under pressure, or by someone who was just trying to survive their first month on the job. I’ve seen how a single, condescending comment can make a talented engineer shut down for weeks. We aren’t just shipping features; we are building a culture that survives the inevitable outages and the inevitable bugs. Treat your colleagues with the same precision and care you give to your most critical production systems. Because in the long run, the quality of your software will always be a reflection of the quality of your team.

Frequently Asked Questions

How do I maintain this kind of empathy when I’m staring at a critical bug in a legacy system that’s currently costing the company money?

You don’t. Not in the heat of the moment. When the production logs are hemorrhaging and the CFO is breathing down your neck, empathy is a luxury you can’t afford—until the fire is out. My rule is to separate the code from the person. I treat the bug like a faulty binding in a book: it’s a structural failure to be corrected, not a moral failing of the person who glued it together.

Is there a way to push back on bad architectural decisions without sounding like I'm just being "difficult" or "nitpicky"?

Shift the focus from “I don’t like this” to “How does this scale?” When I see a design that’s going to cause a production outage at 3 AM, I don’t make it about my preference. I frame it through the lens of maintenance and risk. I ask about edge cases, latency, or the cost of future refactoring. If you tie your pushback to the long-term stability of the system, it’s not being difficult—it’s being responsible.

How do you handle a reviewer who uses "kindness" as a mask for being vague, leaving you with comments like "maybe rethink this" but no actual technical direction?

I’ve seen this before. It’s “polite” obstructionism. When someone says “maybe rethink this” without a technical reason, they aren’t being kind; they’re being unhelpful. I handle it by forcing the abstraction back into the concrete. I’ll reply: “I want to make sure I address your concern correctly. Are you worried about the time complexity here, or is there a specific edge case in the state machine I’ve missed?” Don’t guess. Make them define the failure.