Everyone talks about how important the code review process is for quality. But few people go deep into what really matters — how to give great feedback in a pull request. And more than that: how to receive that feedback without freezing, taking it personally, or turning every PR into an endless debate.
If you deal with code reviews day to day, this post is for you.
We’re not here to stay on the surface. No “be empathetic” or “don’t be aggressive” tips — you already know that. The goal is to show how a pull request can become a moment of real learning, where the team evolves together and delivery quality actually improves.
For reviewers: good feedback isn’t the smartest — it’s the most useful
The role of a reviewer isn’t to prove they know more. It’s to help the person who wrote the code think more clearly about what they’re delivering.
That changes everything. Instead of “this is wrong,” try asking “what was the reasoning behind this approach?” Rather than jumping straight to the issue, start with a genuine question. You might be missing context.
Great reviewers have one thing in common: they’re curious. They try to understand why the code was written a certain way before jumping in with a suggestion. They know feedback isn’t about showing off — it’s about helping build a better solution.
And yes, when you need to disagree, be direct — but explain why. “I think this regex might break in this edge case. Would you consider using a parsing function instead?” That sparks productive discussion, not friction.
Worth noting: a 2024 study analyzing over 8,000 PRs across 46 open source projects showed that suggestions for improvement were the most common type of feedback — even more than bug fixes or code style. And they also increased the chances of the PR getting approved, even if it took more time to address.
For authors: make life easier for whoever is reviewing
Some PRs arrive already asking to be rejected. Not because of the code, but because of the missing context.
Before opening a PR, ask yourself: does the reviewer have all the info that’s in my head? Usually, the answer is no.
A good PR description changes everything. Explain what was done, why it was done, and — if helpful — what alternatives were considered. If there’s a hidden business rule, mention it. If the diff is large because you renamed a bunch of files, say so.
Without context, reviewing becomes guesswork. And no one likes reviewing in the dark.
Another point: avoid shipping huge PRs. If you can break it down into smaller pieces, do it. It’s not just about easier reviews — it helps keep history clean, isolate the impact of each change, and make it easier to revert something if needed.
Feedback across levels: what changes from junior to senior
Not all feedback should be delivered the same way. The way you approach a junior dev’s PR is different from how you review a senior’s — and it’s not about hierarchy, it’s about context and career stage.
With more junior folks, the focus is on helping them develop critical thinking. Take time to explain standards, suggest alternatives with examples, and reinforce good practices. Don’t just correct everything. Ask first. Give them room to think.
With mid-level devs, you’ll want to balance guidance with autonomy. It’s fair to expect more context behind their decisions and encourage better documentation of choices.
With senior folks, feedback is often more technical and straight to the point. But that doesn’t mean skipping the conversation. Challenge decisions, offer alternatives, align on patterns. The goal is to keep things consistent and foster peer-to-peer exchange.
In short: adjust the tone, not the care.
On that note, a recent study showed that PRs submitted by first-time contributors tend to get fewer reactions and comments — which directly impacts learning and engagement, especially early in someone’s career.
How to build a healthy pull request culture in your team
A pull request shouldn’t be a source of anxiety. When done well, it becomes a space for learning and technical alignment.
To make that happen, a few things help a lot:
- Set clear expectations around what should or shouldn’t be in a PR
- Create a simple review checklist the whole team can use
- Use “suggestion” instead of “required changes” when it’s not critical
- Celebrate good solutions, not just point out issues
- Make room in retros to talk about the review process itself
One study on bot usage in PRs found that while they increased merge speed, they also reduced developer-to-developer communication — which can hurt knowledge sharing across the team.
Bottom line: speed matters, but not at the cost of collaboration. Feedback culture needs intentional care.
Good feedback speeds things up. Bad feedback slows everything down.
At the end of the day, the goal of a PR is to help the team deliver better — with more quality and less rework. Solid feedback (both giving and receiving) accelerates that cycle.
There’s no magic here. Just care, clarity, and good intent. And when that becomes part of the culture, the way a team collaborates and grows changes for real.
If you want to build a team that learns together, how you handle pull requests says a lot about where you’re headed.
⭐ You might also like:
Best practices for pull requests
Pull request metrics for engineering managers
