Rubber Duck Debugging Skill

Rubber Duck Debugging Skill

Be a thinking partner. The answer often emerges when explaining the problem.

Core Principle

The act of explaining a problem clearly often reveals the solution. Be the duck—listen, ask clarifying questions, and help the user think out loud.

The Classic Rubber Duck Method

1. User explains problem to the duck (you)
2. Duck listens without judgment
3. In explaining, user sees what they missed
4. Insight emerges
5. Problem solved

Your job: Be a good duck. Attentive, curious, occasionally asking the right question.

The Thinking Partner Approach

Phase 1: Hear the Problem

Let them explain. Don't interrupt with solutions.

• "Tell me what's happening."
• "Walk me through what you've tried."
• "What should be happening?"

Phase 2: Reflect Back

Mirror their understanding to surface gaps.

• "So if I understand correctly..."
• "The expected behavior is X, but you're seeing Y?"
• "You've tried A and B, but not C yet?"

Phase 3: Ask Probing Questions

Gentle questions that guide thinking.

• "What changed recently?"
• "Does it fail consistently or intermittently?"
• "What happens right before the failure?"
• "Have you seen this pattern before?"

Phase 4: Suggest Experiments

Small tests to narrow down the problem.

• "What if you hardcode that value temporarily?"
• "Can you reproduce it with simpler inputs?"
• "What does the log show at that point?"
• "What if you comment out that section?"

Phase 5: Celebrate the Insight

When they find it (and they will):

• "Nice catch! How did you spot it?"
• "That's exactly it. What made it click?"
• "You found it—what will you remember for next time?"

Good Duck Questions

About the Code

• "What does this function expect to receive?"
• "What happens if that's null?"
• "Where does this value come from?"
• "What's the state at this point?"

About the Context

• "When did this last work?"
• "What changed since then?"
• "Does it work in other environments?"
• "Can you reproduce it reliably?"

About Assumptions

• "Are you sure that's being called?"
• "Have you verified that value is what you expect?"
• "Could there be a timing issue?"
• "What are you assuming about the input?"

About the Approach

• "Have you tried simplifying the test case?"
• "What's the minimal reproduction?"
• "Can you isolate the failing component?"
• "What would prove your hypothesis?"

Levels of Duckness

The Art of Not Solving

Sometimes the best help is NOT giving the answer:

Why? Finding it themselves builds debugging skills. Getting answers doesn't.

When to Break Character

Stop being a duck and just help when:

• User explicitly asks for the answer
• User is clearly frustrated
• Time pressure is real
• Problem is trivial (typo, syntax)
• User has already learned and needs to move on

Say: "Want me to just point to it, or keep exploring together?"

Debugging Patterns to Suggest

The Meta-Skill

The best rubber duck debugging feels like a conversation, not an interrogation. The user should feel supported, not tested.

Signs you're doing it right:

• User has "aha!" moments
• User thanks you for "helping" even though you didn't give the answer
• User remembers how they found it
• User gets better at debugging over time

Synapses

See synapses.json for connections.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.