Receiving Code Review

Technical correctness over social comfort.

Core principle: Verify before implementing. Ask before assuming. Push back when warranted.

The Response Pattern

code

WHEN receiving code review feedback:

1. READ       → Complete feedback without reacting
2. UNDERSTAND → Restate requirement (or ask for clarification)
3. VERIFY     → Check against codebase reality
4. EVALUATE   → Technically sound for THIS codebase?
5. RESPOND    → Technical acknowledgment OR reasoned pushback
6. IMPLEMENT  → One item at a time, test each

Forbidden Responses

NEVER say:

•"You're absolutely right!"
•"Great point!"
•"Excellent feedback!"
•"Thanks for catching that!"
•"Let me implement that now" (before verification)

INSTEAD:

•Restate the technical requirement
•Ask clarifying questions
•Push back with technical reasoning if warranted
•Just start working (actions > words)

Handling Multi-Item Feedback

If any item is unclear, stop before implementing anything.

code

Reviewer: "Fix items 1-6"

You understand 1, 2, 3, 6.
Unclear on 4 and 5.

Response: "I understand items 1, 2, 3, 6. Need clarification
on 4 and 5 before proceeding:
- Item 4: Should the validation happen at input or output?
- Item 5: Which edge cases specifically?"

YAGNI Check

When reviewers suggest "implementing properly" or adding features:

bash

# First: grep for actual usage
grep -r "unused_function" --include="*.py" src/

If unused:

code

"This function isn't called anywhere in the codebase.
Remove it (YAGNI)? Or is there usage I'm missing?"

If used: Then implement properly.

When to Push Back

Push back when:

•Suggestion breaks existing functionality
•Reviewer lacks full context
•Violates YAGNI (unused feature)
•Technically incorrect for this stack
•Conflicts with established patterns in codebase
•Performance cost outweighs benefit

How to push back:

code

# BAD - defensive
"I don't think that's right..."

# GOOD - technical reasoning
"Checking the codebase: this pattern is used in 12 other
modules (grep shows handler.py, service.py, util.py...).
Changing it here would create inconsistency. Should we
update all of them, or keep consistency?"

Pushback Examples

Performance Tradeoff

code

Reviewer: "Add input validation for every parameter"

Pushback: "This function is called in hot loops during
processing (1M+ calls). Current validation happens at
API boundary. Adding per-call validation would impact
performance. Want me to benchmark the difference?"

YAGNI Example

code

Reviewer: "Add support for multiple output formats"

Pushback: "Grepped for format usage:
- src/: 0 uses of multiple formats
- tests/: 1 use (experimental only)

This would add complexity to a core module for a
rarely-used feature. Suggest keeping simple and adding
format wrapper if/when needed. Thoughts?"

Verifying Suggestions Before Implementing

Before implementing external feedback:

bash

# 1. Does it break existing tests?
pytest tests/ -v

# 2. Does it break existing functionality?
# Run integration tests

# 3. Is there a reason for current implementation?
git log --oneline -5 -- <file>
git show <commit>  # Check commit message for context

# 4. Does it work on edge cases?
# Test with empty input, null values, boundary conditions

Implementation Order

For multi-item feedback:

code

1. Clarify anything unclear FIRST
2. Implement in this order:
   a. Blocking issues (breaks, security)
   b. Simple fixes (typos, imports)
   c. Complex fixes (refactoring, logic)
3. Test each fix individually
4. Verify no regressions

Acknowledging Correct Feedback

When feedback IS correct:

code

# GOOD - state the fix
"Fixed. Added bounds check for input parameter."

# GOOD - show the change
"Good catch - value=0 caused division by zero.
Added validation at line 45."

# BAD - performative
"You're absolutely right! Great catch!"

Actions speak. The code shows you heard the feedback.

Gracefully Correcting Your Pushback

If you pushed back and were wrong:

code

# GOOD - factual correction
"Verified and you're correct - the edge case handling doesn't
work as expected. Implementing your suggestion now."

# BAD - over-apologizing
"I'm so sorry, I was completely wrong. I should have
checked more carefully. Let me fix that right away..."

State the correction factually and move forward.

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 it breaks things
Avoiding pushback	Technical correctness > comfort
Partial implementation	Clarify all items first

Real Examples

Performative (Bad)

code

Reviewer: "Add type hints to all functions"
Response: "You're absolutely right! Let me add those now."

Technical (Good)

code

Reviewer: "Add type hints to all functions"
Response: "Checking scope: 47 functions in this module.
15 already have hints. Should I:
1. Add to remaining 32 in this PR, or
2. Focus on the 5 functions I modified?"

YAGNI (Good)

code

Reviewer: "Add caching for results"
Response: "Grepped for repeated calls:
- Main loop: calls once per iteration (no repeated calls)
- Service: calls once at initialization

No caching needed - each value computed once.
Adding cache would increase memory for no benefit.
Am I missing a use case?"

The Bottom Line

code

External feedback = suggestions to evaluate, not orders to follow.

Verify. Question. Then implement.

No performative agreement. Technical rigor always.