I've seen a lot of pull requests reviewed in a lot of codebases, and I've noticed a pattern: most code reviews are too polite to be useful. Comments like 'maybe consider extracting this?' or 'not sure if this is intentional?' wrapped in enough qualifiers that the author can safely ignore them. The reviewer feels like they did their job. The code ships as-is. And six months later, everyone's debugging the thing nobody wanted to call out.
Politeness is not the same as respect
The instinct to soften feedback makes sense. You don't want to be that person. You're not their manager. Maybe they know something you don't. But here's the thing: the code is going into a shared codebase that you and everyone else on the team will have to live with. Vague, deferential feedback doesn't protect the author — it protects you from an awkward moment while they ship something that causes problems for everyone.
What good code review actually looks like
It's specific. Not 'this feels complex' but 'this function is doing three things, and I think it should be split here and here, because right now it's impossible to test the validation logic in isolation.' It's direct without being dismissive. It asks questions when it's genuinely unclear, not as a softening device. And it blocks when something would actually cause a problem — not just when it's stylistically different from what you would have written.
A review that doesn't block anything was either a great PR or a wasted review.
— Zaid Maraqa
The reviewer's job
Your job in a code review is not to validate the author's effort. It's to improve the code before it becomes everyone's problem. That means being honest about when something doesn't work, even if the author is senior, even if they're confident, even if it'll create friction. The friction of a blocked PR is nothing compared to the friction of a production incident at 2am.
On being reviewed
If you're on the other end, you have a role here too. Treat your PR as a proposal, not a declaration. When someone calls something out, resist the instinct to explain why you did it before you've considered whether they're right. The code isn't you. A critique of the implementation isn't a critique of your ability. The teams that review well aren't the ones where everyone agrees — they're the ones where disagreement is normal and everyone leaves the conversation feeling like the code is better.