Practice rubber duck debugging and explanation vocabulary: step-by-step walkthroughs, finding bugs through explanation, revealing false assumptions, and talking through problems.
0 / 5 completed
1 / 5
A developer says 'I found the bug while explaining it to you.' Why does explaining code often reveal bugs?
Rubber duck debugging works because explanation forces explicit, linear articulation of logic. When you read code you wrote, your brain fills in gaps with assumptions. When you explain it step by step to someone (or a rubber duck), those assumptions must be stated — and false ones become obvious.
2 / 5
A colleague says 'Explain your code to me from the beginning.' What is the 'from the beginning' instruction trying to achieve?
'From the beginning' forces you to walk through setup, preconditions, and initial state — areas where bugs often hide but are skipped when you assume they work. Many bugs are found not in the complex logic but in the initial state or a condition set up earlier.
3 / 5
You say to a colleague 'Walk me through the logic step by step.' Why is the step-by-step constraint important?
Bugs often hide in transitions between steps — 'then it does X... and then Y happens.' The 'step by step' constraint forces you to specify every transition explicitly, exposing implicit assumptions about what happens between visible operations.
4 / 5
After explaining your code, you say 'The explanation revealed the false assumption.' What is a false assumption in this context?
False assumptions are beliefs about how the code behaves that are not true — 'this function always returns a positive number', 'this variable is always initialized before use', 'this API call always succeeds.' Rubber duck debugging surfaces these by forcing you to state assumptions explicitly.
5 / 5
A team retrospective recommends 'use talking through the problem as a first debugging step.' What is the benefit of this approach?
Talking through a problem as a first debugging step is cost-effective — it often resolves the issue without needing to involve anyone. When it does involve a colleague, it creates shared context efficiently. It also builds the habit of articulating technical problems clearly, a valuable engineering communication skill.