Most code reviews are a waste of everyone’s time.
I know that sounds harsh. But I’ve watched it happen over and over at the fintech startup and at every team I’ve worked with before. Someone opens a PR, someone else clicks approve within three minutes, and we all pretend the process worked. It didn’t. Nobody read anything. The review was theater.
The problem isn’t that teams skip reviews. Almost nobody skips them anymore. The problem is that teams confuse doing reviews with doing them well. You can have a 100% review rate and still ship garbage if nobody’s actually thinking about the code they’re approving.
Actually read the damn code
This shouldn’t need saying, but here we are. Before you leave a single comment on a PR, you need to understand what the change does and why it exists. If the PR description doesn’t explain that, send it back. Don’t guess. Don’t fill in the blanks yourself and hope you got it right.
At the fintech startup we made it a rule: if you can’t explain the change to someone else in plain language, you haven’t reviewed it. Simple as that. I’ve rejected “LGTM” approvals that came in ninety seconds after a PR was opened. There’s no way you read 400 lines of code in ninety seconds. You just didn’t.
Follow the data through the code. Step through the logic path. Check what happens when things go wrong, not just when they go right. That’s the work.
Stop obsessing over style
I see this constantly. A reviewer leaves fifteen comments about bracket placement and variable naming while completely missing a SQL injection vulnerability three lines down. Priorities, people.
Correctness. Security. Error handling. Edge cases. Maintainability. That’s what humans should focus on. Everything else should be automated. We set up linters and formatters specifically so we could stop arguing about tabs versus spaces and start catching actual bugs.
If your review comments are mostly about style, you’re not reviewing. You’re copyediting.
Say something useful
“This is confusing” isn’t feedback. It’s a feeling. Tell the author what is confusing and why. Better yet, suggest a fix.
If a function called processUserData is doing both validation and transformation, don’t just say “this does too much.” Say “split this into validateUserData and transformUserData so we can test them independently and the control flow is obvious.” That’s something someone can act on in five minutes instead of spending twenty minutes guessing what you meant.
Also, label your comments. At the fintech startup we started prefixing with blocker:, suggestion:, or question:. It sounds bureaucratic, but it completely changed the dynamic. Authors stopped treating every comment as a demand and reviewers stopped softening real concerns to avoid conflict. Blockers block the merge. Suggestions are optional. Questions are just questions.
Make reviews possible in the first place
Giant PRs get bad reviews. Always. Nobody can hold 2000 lines of diff in their head and reason about correctness. The code might be fine. The reviewer will never know because they glazed over at line 300.
Keep PRs small. One concern per PR. Write a description that explains the problem, the approach, and how to test it. I’ve seen PRs at the fintech startup where the description was better than the code, and that’s not an insult. Good context makes review ten times faster and ten times more useful.
Automate everything that isn’t judgment
Formatting, linting, type checking, test gates, dependency scanning. All of it should run before a human ever looks at the PR. Every minute a reviewer spends on something a machine could catch is a minute wasted.
Your reviewers’ attention is finite and expensive. Protect it.
The honest thing to do
If you don’t have time to review something properly, say so. “I can’t get to this until tomorrow” is infinitely more useful than a rubber-stamp approval today. A fake review is worse than no review because it gives false confidence. At least with no review, everyone knows the risk.
Code review works when people take it seriously. Not as a gate to check off, but as the last chance to catch something before it hits production. That’s the whole point. Everything else is just counting approvals.