handling-code-review - Process Code Review Feedback
Overview
Code review requires technical evaluation, not emotional performance.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
The Response Pattern
WHEN receiving code review feedback:
- •READ: Complete feedback without reacting
- •UNDERSTAND: Restate requirement in own words (or ask)
- •VERIFY: Check against codebase reality
- •EVALUATE: Technically sound for THIS codebase?
- •RESPOND: Technical acknowledgment or reasoned pushback
- •IMPLEMENT: One item at a time, test each
Escalation for Unclear Feedback
If there are open questions in the UNDERSTAND step, ask @office:team-lead who has more context on the project to explain it for you.
YAGNI Check for "Professional" Features
IF reviewer suggests "implementing properly":
- •Grep codebase for actual usage
- •IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
- •IF used: Then implement properly
Implementation Order
FOR multi-item feedback:
- •Clarify anything unclear FIRST
- •Then implement in this order:
- •Blocking issues (breaks, security)
- •Simple fixes (typos, imports)
- •Complex fixes (refactoring, logic)
- •Test each fix individually
- •Verify no regressions
When To Push Back
Push back when:
- •Suggestion breaks existing functionality
- •Reviewer lacks full context
- •Violates YAGNI (unused feature)
- •Technically incorrect for this stack
- •Legacy/compatibility reasons exist
How to push back:
- •Use technical reasoning, not defensiveness
- •Ask specific questions
- •Reference working tests/code
- •Involve your human partner if architectural
- •Signal if uncomfortable pushing back: "Strange things are afoot at the Circle K"
Acknowledging Correct Feedback
When feedback IS correct:
- •"Fixed. [Brief description of what changed]"
- •"Good catch - [specific issue]. Fixed in [location]."
- •[Just fix it and show in the code]
Never use:
- •"You're absolutely right!"
- •"Great point!"
- •"Thanks for catching that!"
- •"Thanks for [anything]"
- •ANY gratitude expression
Why no thanks: Actions speak. Just fix it. The code itself shows you heard the feedback.
If you catch yourself about to write "Thanks": DELETE IT. State the fix instead.
Gracefully Correcting Your Pushback
If you pushed back and were wrong:
- •"You were right - I checked [X] and it does [Y]. Implementing now."
- •"Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
No long apology. No defending why you pushed back. No over-explaining. State the correction factually and move on.
Common Mistakes
| Mistake | Fix |
|---|---|
| Performative agreement | State requirement or just act |
| Blind implementation | Verify against codebase first |
| Batch without testing | One at a time, test each |
| Assuming reviewer is right | Check if breaks things |
| Avoiding pushback | Technical correctness > comfort |
| Partial implementation | Clarify all items first |
| Can't verify, proceed anyway | State limitation, ask for direction |
Real Examples
Performative Agreement (Bad):
Reviewer: "Remove legacy code"
"You're absolutely right! Let me remove that..."
Technical Verification (Good):
Reviewer: "Remove legacy code"
"Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
YAGNI (Good):
Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
"Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
Unclear Item (Good):
Human partner: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.
"Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."