Let’s face it: reviewing Pull Requests is the broccoli of development. You know it’s good for you, but it’s not always fun — unless you know how to spice it up and do it right.
If you’ve ever dropped a passive-aggressive comment or gotten a soul-crushing “This doesn’t scale” on your PR, this article is for you.
Being a good PR reviewer isn’t just about catching bugs. It’s about collaboration, clarity, empathy, and sometimes — yes — talking to your AI buddy, GitHub Copilot. Let’s dive into what makes a great reviewer and how not to be that person in code reviews.
✅ Best Practices for Being a Kickass Reviewer
🍞 Start with a Compliment Sandwich
Don’t go in guns blazing. Start by acknowledging what’s good.
“Nice use of useCallback here—makes the component super snappy!"
"But hey, this map inside the render could be memoized."
People aren’t merge bots — they’re humans who just spent hours staring into the abyss of nested ternaries.
🎬 Read the PR Description Like It’s the Plot Summary of a Nolan Movie
Before diving into code:
- What’s the goal?
- What problem is being solved?
- Are there screenshots, test plans, or linked issues?
If the PR has no description, request it politely:
“Hey! Could you add a quick summary of the changes here? Helps reviewers stay on the same page. 🙌”
🏷️ Label Your Comments Like a Pro
Not all comments carry the same weight. Help your teammate prioritize by labeling your feedback clearly. It saves confusion, reduces guesswork, and makes your review feel thoughtful instead of chaotic.
Use labels like:
- Nit — Minor things like formatting, naming, or micro-optimizations. Non-blocking.
- Suggestion — Optional improvements that could enhance readability, performance, or structure.
- Blocker — Something that must be fixed before merging (e.g., bugs, regressions, broken logic).
- Question — Points that need more clarity or discussion before moving forward.
This lets the PR author know what to fix now, what to consider later, and what just sparked a curious thought. Plus, it shows you’ve taken the time to organize your feedback — not just dumped it.
🕵️ Ask, Don’t Tell (Unless It’s a Security Risk)
Bad:
“Change this, it’s wrong.”
Better:
“Would it make sense to use a useMemo here instead? Might avoid re-renders.”
You’re not a code cop. You’re a curious teammate.
🔪 Don’t Nitpick to Death
Nobody wants 15 comments like:
- “Missing comma.”
- “Extra line break.”
- “Variable could be shorter.”
- “Missing new empty at EOF”
That’s what linters and Prettier are for. If it’s not breaking anything, breathe. You can always open a PR to address linters and Prettier changes.
🤖 Use Copilot to Review? Oh Yes, You Can.
Copilot isn’t just for generating code — it can help review too:
- Select a function and ask Copilot:
“What’s this doing?”
- Ask for alternatives:
“Can this loop be optimized?”
Copilot won’t replace you, but it’s like having an over-caffeinated junior dev whispering tips.
❌ Reviewer Red Flags (Aka Don’t Be That Dev)
Drive-by LGTM 🚀
Two minutes on a 500-line PR? Nah. That’s not trust. That’s neglect.Tone-Deaf Comments
“This is a terrible implementation.”
Try:
“This approach might introduce issues — what about using X instead?”
PR as a Battleground
If you strongly disagree, talk it out in a call. Text lacks tone. Even “?” can sound passive-aggressive.Holding It Hostage
Don’t vanish for days. If you can’t review, say so. Blocking someone’s merge with ghost energy = developer sin.
🙌 The Gentle Ask: Requesting Changes Without Crushing Souls
Instead of:
“Fix this.”
Try:
“This could be a bit cleaner — what do you think about extracting this into a utility?”
Instead of:
“Tests are missing.”
Say:
“Could you add a test for the loading state? Would help catch regressions later.”
You’re not just a reviewer. You’re a mentor, a peer, a collaborator.
✅ Approve with Comments & Close the Loop
Approve… and Suggest
You don’t have to block a PR just to leave a suggestion. Approving with comments is a baller move — it says:
“You’re good to go, but here’s a thought you might want to consider later.”
It builds trust, avoids unnecessary cycles, and keeps the team moving.
Say Thanks After Revisions
When someone makes updates based on your feedback, don’t just vanish into the merge button. A simple:
“Thanks for the update!”
“Appreciate the quick fix 🙏”
…goes a long way. It closes the loop and makes people feel seen, not just managed.
💎 Bonus Tips to Level Up Your Review Game
- Use GitHub’s “Suggested Changes” feature
- Emojis are cool — just not a zoo 🐒
🚀 Final Thoughts
A good reviewer is less about being right and more about being kind, constructive, and consistent. Good PR reviews build trust, prevent bugs, and make everyone better.
So next time, think less “gatekeeper” but more “collaborator.”
The best code isn’t just clean — it’s reviewed with care.
If you enjoyed this, give it a reaction. Got review horror stories or tips? Drop’em below — I’m all ears (and eyes).