Most engineers have been there. You open a pull request and brace yourself. Three days pass. The branch drifts. When comments finally arrive, they’re nitpicky and cold, or a blunt “this seems off” with no other context.
On the other side, you’ve been tagged on a PR you don’t have full context for and you’re not sure how deep to go. You’re worried that leaving too many comments will make you look difficult, or that leaving too few will mean something slips through.
Neither of these feels like collaboration. And yet that’s exactly what code review is for: not approval, but shared ownership of what gets shipped.
The real point of the pull request
A pull request is an invitation for a fresh set of eyes to check on the health of the codebase. The engineer who wrote the code has been living inside it for days. The reality is that a second person can take a step back and provide a more objective perspective.
This means every comment has a valid place, from the humble nit to the bold “did you consider this approach?” A big architectural question might feel presumptuous coming from a junior engineer, but the newest person on the team sometimes sees the simplest solution precisely because they don’t have the context to overcomplicate it.
The goal is good code, and everything else is in service of that.
The ground rules
Good review culture doesn’t happen by accident. It needs a few agreements that everyone on the team holds to. Here are some that I think are effective:
Give your reviewers context. Write a quick summary for your pull request that describes your chosen approach and a good place to start the review to build understanding.
Move quickly. A pull request that sits open is a liability: merge conflicts accumulate, and the author’s context fades. If you submitted the PR, address comments promptly. If you were tagged as a reviewer, get to it and stay on top of any threads you open.
Remember that there’s a human on the other end of every comment thread. You want them to understand your point of view. Explain it in a way that the developer can act on.
Leave ego at the door. There’s no need to take it personally when your code gets picked apart. The review is about the code, not the person who wrote it.
Don’t resolve someone else’s comment. The commenter needs to confirm their concern was actually addressed, and taking that away from them short-circuits the whole point of the exchange.
Everyone runs through the acceptance criteria. The code author and reviewer are both responsible for confirming that the work actually does what it was supposed to do. If the criteria aren’t met, that’s the most important thing to flag, and it’s everyone’s job to catch it.
What to actually look for
Beyond the acceptance criteria, a good reviewer is looking for things the author is often too close to see. New warnings that crept in. Missing unit tests for new code paths. Files that got included accidentally. Logic that works for the happy path but breaks at the boundaries.
None of these are gotchas. They’re the kind of thing that happens to every engineer when they’ve been heads-down on a problem. Catching them in review is exactly why this is a critical part of the SDLC.
What it looks like when it’s working
When review culture is healthy, the PR comments don’t feel like an attack. They feel like a conversation. Junior engineers push back on senior ones and get taken seriously. Senior engineers leave explanations alongside their suggestions rather than just marking things wrong. Threads close quickly because everyone is paying attention. The codebase gets a little better with every merge.
More than that, the team gets better. Engineers learn from each other’s comments. Patterns propagate. Standards rise without anyone having to mandate them. The review becomes one of the primary ways the team teaches itself.
It all starts with remembering what a pull request is actually for.
Dowell Dev 