Pull requests are not a gatekeeping ritual. They are one of the few places a team still talks about tradeoffs in public. The quality of that conversation predicts the quality of the codebase six months later.
What I actually review for
- Intent: can I explain what changed and why without a meeting?
- Risk: auth, money, data loss, concurrency, silent failures.
- Operability: logs, metrics, migrations, rollback story.
- Kindness to the next reader: names, structure, tests that document behavior.
I try to separate preference from principle. Tabs and taste are cheap comments. “This will race under load” or “this leaks PII into logs” is why review exists. When I disagree on approach, I ask for the failure mode we are optimizing for, not who wins the argument.
Teaching without humiliating
The best reviews I have received assumed I was competent and still showed me a sharper path. The worst ones performed superiority. If your review style makes people hide work, you did not raise quality, you raised fear. Fear ships quietly broken things.
Key takeaways
What to remember
- Review risk and intent, not taste wars.
- Fearful reviews hide broken work.
- Teach without humiliation.
