Debugging Collaboration Language | Pair Programming Exercises

1 / 5

You're debugging a production issue in a pairing session and want to share your hypothesis.

Which phrasing is most useful?

Hypothesis-driven debugging requires stating your theory, the evidence that would confirm it, and your next step:

Component	Example	Purpose
Hypothesis	"session timeout is being calculated incorrectly"	Gives the pair a specific theory to test
Predicted evidence	"we should see mismatches in the timestamps"	Makes the hypothesis testable and falsifiable
Next action	"let me check the logs to confirm or rule this out"	Drives the session forward with a clear step

Key vocabulary: "my hypothesis is", "if I'm right, we should see", "confirm or rule this out".

2 / 5

"We can rule out the network layer — all requests are reaching the server."

What does "rule out" mean in debugging collaboration?

Systematic debugging has a precise vocabulary for narrowing down the hypothesis space:

Term	Meaning	Example use
Rule out	Eliminate — not the cause	"We can rule out the cache — it's disabled in staging"
Narrow down	Reduce the suspect list	"This narrows it down to the payment or tax service"
Confirm	Evidence matches hypothesis	"The null pointer confirms our hypothesis"
Reproduce	Create a reliable test case	"Can we reproduce this with a minimal test?"

Key vocabulary: "rule out", "narrow down the suspects", "isolate the variable", "root cause vs. symptom".

3 / 5

Your pair says "let me add a breakpoint here."

Which collaborative debugging action is the most useful follow-up from the navigator?

The navigator's value during debugging is maintaining the hypothesis and predicting results — not waiting passively:

Navigator action	Why it matters
Predict expected values at the breakpoint	Enables instant interpretation of the result — "yes that confirms it" or "no, it's something else"
Connect breakpoint to current hypothesis	Keeps the session hypothesis-driven rather than exploratory
Prepare the next step in advance	Reduces dead time after the breakpoint is hit

Key vocabulary: "expected vs. actual value", "hypothesis-driven inspection", "navigator predictive role", "breakpoint interpretation".

4 / 5

"We've been on this for 45 minutes — should we try rubber duck debugging?"

What is rubber duck debugging and how does verbalising the problem help?

Rubber duck debugging works because articulating a problem forces logical structure that silent thinking can bypass:

Why verbalising works	What it surfaces
Forces you to state assumptions explicitly	Hidden assumption errors ("wait, I assumed X but that's not guaranteed")
Requires the full logical chain to be spoken	Missing steps and logical gaps in the reasoning
Slows down rapid mental pattern matching	Bugs hidden by familiarity with the code

In pairing: "let me just walk you through what I think is happening" = rubber duck with a real listener who can ask questions. Key vocabulary: "rubber duck debugging", "verbalising the problem", "articulate assumptions".

5 / 5

After resolving the bug, you want to make sure your pair understands the root cause.

Which phrase best initiates a root cause explanation?

A good root cause explanation in pairing combines explanation, demonstration, and generalisation:

Component	Example from option B
State the root cause	"currency conversion applied before the tax calculation"
Explain why it matters	"the order matters here"
Show in the code	"let me show you where in the code it happens"
Generalise the lesson	"so you can spot this class of bug in future"

Key vocabulary: "root cause", "class of bug", "teaching moment in pairing", "knowledge transfer during debugging".