Receiving Feedback

Receiving Feedback

Core Mindset

"Verify before implementing. Ask before assuming. Technical correctness over social comfort."

Code review feedback is a technical discussion, not a social one. Focus on the code, not on feelings.

The Six-Step Process

Step 1: Read Completely

Without reacting. Read the entire comment before forming any response.

❌ BAD: Read first sentence → start typing defense
✅ GOOD: Read entire comment → understand full context → then respond

Step 2: Restate Requirements

Rephrase the reviewer's feedback in your own words to confirm understanding.

Reviewer: "This function is doing too much. It handles validation,
transformation, and persistence all in one place."

Your restatement: "You're suggesting I split this into three separate
functions: validate(), transform(), and persist()?"

Step 3: Check Against Codebase

Verify the feedback against actual code conditions before responding.

// Reviewer says: "This will throw if user is null"

// Check the code:
function getUsername(user: User): string {
  return user.name;  // No null check - reviewer is correct
}

// Or discover context:
function getUsername(user: User): string {
  return user.name;  // TypeScript enforces User, null not possible
}

Step 4: Evaluate Technical Soundness

Consider whether the feedback applies to your specific stack and context.

Reviewer: "You should use useMemo here for performance"

Evaluate:
- Is this component re-rendering frequently? → Check React DevTools
- Is the computation expensive? → Profile it
- Does React 19's compiler auto-optimize this? → Check version

Step 5: Respond with Substance

Provide technical acknowledgment or reasoned objection.

✅ GOOD: "Fixed. Split into validate(), transform(), persist()
         at lines 24, 45, 67."

✅ GOOD: "Respectfully disagree. This list has max 5 items
         (see schema.ts:12), so filter performance is O(5)."

❌ BAD: "You're absolutely right! Great catch!"
❌ BAD: "I don't think that's necessary."

Step 6: Implement One at a Time

Address each piece of feedback individually with verification.

Feedback item 1: Add null check
→ Implement → Test → Commit → Verify → Move to next

Feedback item 2: Extract helper function
→ Implement → Test → Commit → Verify → Move to next

NOT: Try to address all feedback in one massive commit

Avoiding Agreement Theater

The Problem

Performative agreement wastes time and provides no information. When you write "Great point!" you're adding noise, not signal.

Forbidden Phrases

Actions Demonstrate Understanding

❌ "You're absolutely right! Great catch on that null check!
    Thanks so much for pointing this out!"

✅ "Fixed. Added null check at line 42."

The code change shows you understood. Words are redundant.

When Acknowledgment IS Appropriate

Brief, technical acknowledgment when learning something new:

✅ "I wasn't aware of that edge case. Added handling at line 42."
✅ "Good point about thread safety. Added mutex at line 67."

When to Push Back

Valid Reasons to Disagree

Push back with technical reasoning when feedback:

Good Pushback Format

## Template
This conflicts with [X]. [Evidence]. Was that the intent, or should we [alternative]?

## Example
This conflicts with our JWT authentication architecture (see auth/token.js:45).
Switching to sessions would require restructuring the API middleware.
Was that the intent, or should we keep JWT?

Bad Pushback

❌ "I don't think that's right."
❌ "That won't work."
❌ "We've always done it this way."
❌ "That's too much work."

Verification Before Claiming Fixed

The Checklist

Before writing "Fixed" or "Done":

• Change is implemented
• Tests pass (full suite, not just changed files)
• Specific behavior mentioned in feedback is verified
• Edge cases are tested
• No unintended side effects introduced

Acceptable Responses

✅ "Fixed. Added null check. Tests pass."
✅ "Fixed at line 42. Verified with test case X."
✅ "Implemented. All 47 tests pass."

Unacceptable Responses

❌ "I think this addresses your concern."
❌ "Should be fixed now."
❌ "Done, I believe."
❌ "Fixed (probably)."

When You Can't Verify

If you cannot verify a fix:

✅ "Implemented the change, but I'm unable to verify because
    [specific reason]. Can you confirm on your end?"

Quick Reference

Anti-Patterns

Content adapted from obra/superpowers by Jesse Vincent (@obra), MIT License.