The Problem With Fanatical Code Reviews
Most engineers have experienced it.
You open a pull request that works, is tested, and moves the product forward, only to be met with comments about:
- Variable naming preferences
- Personal formatting styles
- Hypothetical edge cases that might matter someday
- e.g. can you abstract this function because someone might re-use it in the future (investing effort for a use case that may never occur, avoid pre-optimisation)
- Requests to refactor unrelated code “while you’re in here”
Fanatical code reviews often come from a good place: caring about quality. But in practice, they tend to:
- Slow down delivery
- Frustrate engineers
- Shift focus from outcomes to aesthetics
- Create unnecessary power dynamics
Perfection becomes the goal, instead of progress.
Security should never be sacrificed in code reviews!
- Injection attacks, validation, cross-site scripting, SQl etc…
- External packages, both front and backend, as the recent REACT vulnerabilities highlighted a single package can
introduce both frontend and backend vulnerabilities.
- All newly included packages should be examined
- All upgrades of existing packages should also be scrutinised
What Practical Code Reviews Optimise For
Practical code reviews are not careless or lax. They are intentional.
They optimise for:
- Correctness: Does the code do what it claims to do?
- Clarity: Can another engineer reasonably understand it?
- Safety: Does it introduce real bugs, security issues, or regressions?
- Impact: Does it meaningfully improve or harm the system?
If a comment doesn’t materially improve one of those areas, it’s probably not worth blocking a merge over.
Blocking vs Non-Blocking Feedback
One of the simplest ways to move toward practical reviews is to clearly separate blocking and non-blocking feedback.
Blocking Comments Should Be Rare and Serious
Blocking comments are for issues like:
- Incorrect logic
- Broken functionality
- Security vulnerabilities
- Data integrity risks
- Violations of explicit team standards that can not be addressed via automation
If left unresolved, these issues would actively harm the product or team.
Everything else? Probably non-blocking.
Non-Blocking Comments Encourage Growth Without Friction
Non-blocking comments are suggestions, not demands:
- Alternative implementations
- Style improvements
- Readability tweaks
- Future refactor ideas
They might look like:
Non-blocking: This could be simplified with a helper function, but it’s fine as-is.
This small distinction changes the entire tone of a review. It turns feedback into collaboration instead of gatekeeping.
Why Non-Blocking Reviews Scale Better
As a teams grow, fanatical reviews become a bottleneck.
Practical, non-blocking reviews:
- Keep PRs moving
- Reduce review anxiety
- Encourage ownership instead of compliance
- Create space for learning without punishment
Engineers are more receptive to feedback when it doesn’t threaten their progress.
Code Reviews Are Not the Only Quality Gate
Fanatical reviews often try to compensate for missing systems.
Practical teams rely on:
- Automated tests
- Linters and formatters
- Type systems
- CI pipelines
- Monitoring and rollback strategies
When these systems exist, code reviews can focus on what humans are uniquely good at: reasoning about behaviour and intent.
Trust Is a Force Multiplier
Fanatical reviews assume engineers must be controlled.
Practical reviews assume engineers want to do good work.
Trust doesn’t mean no standards, it means:
- Clear expectations
- Consistent tooling
- Feedback without ego
- Room to improve over time
When trust exists, fewer rules are needed.
A Simple Rule of Thumb
Before leaving a comment, ask:
If this isn’t changed, will it cause real harm?
If the answer is no:
- Make it non-blocking
- Or don’t comment at all
Not every thought needs to be written down. Not every improvement needs to happen today.
Conclusion
Fanatical code reviews feel thorough, but often trade long-term team health for short-term control.
Practical code reviews, especially those that embrace non-blocking feedback, deliver better outcomes:
- Faster iteration
- Stronger teams
- More maintainable software
Good code matters. But sustainable teams matter more.