Writing Reviewable PRs
Keep PRs small: under 400 lines changed. Large PRs get rubber-stamped, not reviewed. Write a clear title: "Add user search with autocomplete" not "Feature updates." Include a description: what changed, why, how to test, and screenshots for UI changes. Link to the issue/ticket. Self-review before requesting: re-read your diff, catch obvious issues, remove debug code. A well-structured PR gets reviewed 3x faster than a dump of changes.
Giving Constructive Feedback
Start with what's good — acknowledge effort and good decisions. Ask questions instead of making demands: "What if we used a Map here instead?" vs "Use a Map." Distinguish between blocking issues and suggestions: prefix with "nit:", "suggestion:", or "blocking:". Explain the why: "This could cause N+1 queries because..." not just "Don't do this." Be specific — point to the exact line, provide an alternative. Review the code, not the person.
Receiving Feedback Gracefully
Don't take it personally — reviewers are improving the code, not attacking you. Respond to every comment, even if just acknowledging it. If you disagree, explain your reasoning calmly with technical arguments. Ask for clarification when feedback is unclear. Say "thank you" — genuine appreciation builds a positive review culture. Remember: the goal is better code, not being right. Sometimes the reviewer's suggestion is better; sometimes yours is. Discuss the tradeoffs.
Review Turnaround
Aim to review PRs within 4 hours during working hours. Blocked PRs block the entire team — prioritize reviews over new feature work. If a review will take more than 30 minutes, schedule it — don't let it sit. Use GitHub's "Request changes" vs "Approve" intentionally. Don't approve without actually reading the code. Set team expectations: "All PRs reviewed within one business day" is reasonable.
What to Automate
Don't waste human attention on things machines can check: formatting (Prettier), linting (ESLint), type checking (TypeScript), test coverage, dependency vulnerabilities, PR size warnings. Set up CI to run these on every PR. Humans should focus on: logic correctness, architecture, naming, edge cases, security, and performance. Automate the objective, review the subjective.
Handling Disagreements
Agree on coding standards upfront — document them in a style guide. For technical disagreements: (1) Both parties explain their reasoning in writing, (2) If still unresolved, bring in a third opinion, (3) Make a decision and move on — perfection isn't the goal. Don't block PRs over style preferences. Use "let's try your approach and revisit if it causes issues" when both options are valid. Prolonged PR debates hurt team velocity more than a suboptimal solution.
Building Review Culture
Lead by example — senior engineers should request reviews and accept feedback publicly. Celebrate good reviews in retros. Rotate reviewers — don't let the same person review everything. Pair junior and senior reviewers for knowledge transfer. Make reviewing a first-class activity — include it in sprint capacity, recognize it in performance reviews. A healthy review culture catches bugs, spreads knowledge, and builds team cohesion.