6 exercises — articulate a problem clearly enough to find the bug yourself, using goal/expected/actual framing and line-by-line narration.
0 / 6 completed
1 / 6
You are about to explain a bug out loud to a colleague (or a rubber duck). Which opening correctly frames the problem before diving into details?
Rubber duck debugging works because articulating the goal, expected behaviour, and actual behaviour out loud forces you to slow down and notice gaps in your own reasoning — often before the listener says a word.
Formula: "Here's what I'm trying to do: [goal]. Here's what I expect: [expected]. Here's what's actually happening: [actual]."
This three-part frame is the verbal equivalent of a bug report's "expected vs. actual" structure, and it's the single most effective habit for self-resolving bugs before asking for help.
2 / 6
Midway through explaining your code line-by-line, you suddenly realise the bug yourself. What is the correct way to acknowledge this out loud?
The classic "rubber duck moment" — say what triggered the realisation ("saying that out loud"), and state your new hypothesis explicitly before verifying it. This keeps the explanation useful even if you're talking to a real colleague who was following along.
Formula: "Wait — actually, saying that out loud, I think I see it. Let me check: [hypothesis]."
Narrating the "aha" moment (rather than silently going quiet) is respectful to a human listener and reinforces the habit of externalising your reasoning, which is the whole point of the technique.
3 / 6
A junior engineer says "I tried explaining it to my rubber duck but I still don't see the bug." What is the best follow-up coaching advice?
The technique fails when the explanation stays too high-level ("this function processes the order"). Coaching should push toward literal, line-by-line narration of actual behaviour, not intended behaviour — the gap between "what I think it does" and "what it literally does" is where most bugs hide.
Useful phrase: "Walk through it line by line and say exactly what each line does, not what you intend it to do." This distinction — narrating actual vs. intended behaviour — is the core mechanic that makes rubber duck debugging effective.
4 / 6
You're rubber-ducking with an actual colleague (not a toy) and want to clarify your own understanding mid-explanation. Which phrase is most appropriate?
When rubber-ducking with a real person, periodically check your own understanding out loud rather than assuming it — this invites the listener to correct you if your mental model is wrong, which is often exactly where the bug lives.
Formula: "Let me make sure I'm explaining this right — [restated assumption], correct?"
This phrase does double duty: it's good rubber-ducking practice (surfacing assumptions) and good collaborative debugging (giving the listener an explicit point to interject).
5 / 6
After successfully rubber-ducking your way to a fix, how should you summarise the process to a teammate who asks "how did you find it?"
A good debugging summary explains the method (narrating line by line) and the specific finding (the off-by-one error), so the technique itself becomes a transferable lesson for the listener, not just an anecdote.
Formula: "I walked through it out loud step by step and realised [specific finding] — explaining it line by line surfaced [type of bug] I kept missing when reading silently."
Sharing not just the fix but the process reinforces good debugging habits across the team, and normalises rubber duck debugging as a legitimate first-line technique rather than something to be embarrassed about.
6 / 6
You want to use rubber duck debugging asynchronously, by writing (not speaking) an explanation in a scratch document before asking for help. Which framing is correct?
Written rubber-ducking ("the written duck") follows the same principle: state the goal, expected, actual, and what you've ruled out in writing before you ask anyone. Many people find the bug simply by forcing themselves to write a clear, complete explanation.
Formula: "Writing this out to think it through: I expect [X], I'm seeing [Y], I've already ruled out [Z]."
This habit produces a bonus benefit: if you don't solve it yourself, you now have a well-structured bug report ready to post, rather than a vague "it's broken" message.
What does the "Rubber Duck Debugging Language" exercise practise?
Practise articulating a problem clearly out loud or in writing: goal/expected/actual framing, self-explanation, and the written rubber-duck technique. 6 exercises.
How many questions are in this exercise?
This exercise has 6 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Beginner. If the vocabulary feels difficult, browse the Debugging Language category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Rubber Duck Debugging Language" part of a larger series?
Yes — it's one exercise in the Debugging Language category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Debugging Language category page for related exercises, or browse the main Exercises hub for other IT English topics.