And how to tell if yours isn’t working
If your team is doing code reviews but they feel painful, slow, or performative, this post is for you. Let’s walk through what a healthy process actually looks like.
What Code Review Is (And Isn’t)
Code review is the practice of having another developer look at your code before it gets merged into the main codebase. Someone writes code, opens a pull request (or merge request), and one or more teammates review it before it goes live.
What it’s for:
- Catching bugs and logic errors before they hit production
- Ensuring code meets the team’s standards and conventions
- Sharing knowledge across the team (so the bus factor isn’t 1)
- Getting a second perspective on architecture and approach
What it’s not for:
- Proving how smart you are
- Gatekeeping or power dynamics
- Catching every possible issue (that’s what tests are for)
- Rewriting someone else’s code in your preferred style
The goal is collaboration, not competition. If your reviews feel adversarial, something’s broken.
A Typical Healthy Flow
Here’s what a well-functioning code review process generally looks like:
1. Developer Opens a Pull Request
After finishing a feature or fix, the developer opens a PR with:
- A clear title describing what changed
- A description explaining why (not just what)
- Links to relevant tickets, designs, or context
- Any areas they’re uncertain about or want specific feedback on
Good PR descriptions save everyone time. “Fixed the thing” tells reviewers nothing. “Fixed race condition in payment processing that caused duplicate charges under high load” tells them exactly what to focus on.
2. Automated Checks Run
Before any human looks at the code, automated systems handle the boring stuff:
- Tests run (and pass)
- Linting checks code style
- Build verification confirms nothing’s broken
- Security scans flag obvious issues
This isn’t optional. If your team is manually checking for semicolons and indentation, you’re wasting human attention on robot work.
3. Reviewer(s) Assigned
Someone (or multiple someones) gets assigned to review. This might be:
- Automatic based on code ownership
- Requested by the author
- Assigned by a lead
- Picked up from a queue
The key is that someone is clearly responsible. “Anyone can review” often means no one does.
4. The Actual Review
The reviewer reads through the changes with a few questions in mind:
- Does this do what it’s supposed to do?
- Is there anything obviously wrong or risky?
- Will this be maintainable by someone else later?
- Does it follow our conventions?
- Are there edge cases that aren’t handled?
They leave comments: questions, suggestions, concerns. Good reviewers distinguish between blocking issues (“this will break in production”) and nitpicks (“I might name this variable differently”).
5. Author Responds
The author addresses comments: fixing issues, answering questions, or explaining why they made certain choices. Not every suggestion needs to be accepted. “I see your point, but I went this way because X” is a valid response.
6. Approval and Merge
Once the reviewer is satisfied, they approve. The code gets merged. Everyone moves on.
The whole cycle, for a reasonably-sized PR, should take hours or a day. Not a week. Not multiple rounds of extensive rewrites. If reviews are consistently taking forever, something’s wrong with the process (or the PRs are too big).
Signs Your Process Is Healthy
Reviews happen quickly. PRs don’t sit for days waiting for attention. There’s an understanding that blocking someone’s work has a cost.
Comments are constructive. Feedback focuses on the code, not the person. “This could be clearer if…” beats “Why would you do it this way?”
Knowledge gets shared. Junior developers learn from reviews. Senior developers learn too. Everyone gets better.
PRs are reasonably sized. Small, focused changes are easier to review well. If every PR is 2,000 lines, no one is actually reviewing anything.
People feel comfortable pushing back. Authors can disagree with suggestions. Reviewers can be wrong. Discussion is normal and healthy.
It’s not a performance. Reviews exist to improve code, not to demonstrate expertise or catch people making mistakes.
Signs Your Process Is Broken
PRs sit for days. Work piles up waiting for review. Developers context-switch to other things and forget what they were doing.
Reviews are nitpicky or hostile. Every PR becomes a battle. People dread opening them. Comments feel like attacks.
Only certain people can approve. One or two gatekeepers control all merges. They become bottlenecks, and everyone else feels like their opinion doesn’t matter.
Reviews are rubber stamps. Approvals come in seconds with no real feedback. The process exists on paper but not in practice.
PRs are enormous. Thousands of lines, multiple features, impossible to review meaningfully. Reviewers skim because actually reading it would take all day.
Everyone’s afraid to merge. The review process has become so heavy that people avoid it. Code gets developed in long-lived branches. Integration becomes painful.
Practical Tips for Better Reviews
As an author:
- Keep PRs small and focused (under 400 lines is a good target)
- Write a real description explaining context and intent
- Self-review before requesting others (you’ll catch obvious stuff)
- Point out areas where you want specific feedback
- Respond to comments promptly
As a reviewer:
- Review within a day (ideally within hours)
- Start with understanding, then evaluate
- Distinguish blockers from suggestions from nitpicks
- Ask questions instead of making demands
- Acknowledge what’s good, not just what needs work
As a team:
- Set expectations for response time
- Rotate reviewers so knowledge spreads
- Keep PR size reasonable (this is a team problem, not individual)
- Automate everything that can be automated
- Treat reviews as collaboration, not gatekeeping
The Culture Underneath
The mechanics of code review are simple. The hard part is culture.
In healthy teams, reviews are seen as help. Someone taking time to look at your code is doing you a favor. Feedback is a gift. The goal is shipping good software together.
In unhealthy teams, reviews are seen as judgment. Every comment feels like criticism. Every suggestion feels like an attack. The goal becomes getting through the process, not improving the code.
If your reviews feel like the second description, the fix isn’t a better process doc. It’s addressing the underlying team dynamics: trust, psychological safety, and how people treat each other.
The Bottom Line
Code review should make your team faster and your code better. If it’s not doing both, something needs to change.
The process itself isn’t complicated. The cultural piece is harder. But teams that get it right build better software and have developers who actually enjoy working together.
That’s worth getting right.
Wondering if your development processes are helping or hurting? We help teams audit their workflows and identify what’s working and what isn’t. Reach out if you’d like to talk.
