Here are some concrete examples of how far apart a symptom and its cause can be:

Why step 1 matters. A bug you cannot reproduce consistently is a bug you cannot trust that you have fixed. Before doing anything else, find a specific input — a particular value, a particular sequence of actions — that causes the bug every single time. Write it down. Use it as your test case throughout the debugging session. If your fix makes the bug disappear with one input but the bug was never reliably caused by that input in the first place, you do not know whether you fixed anything.

Why step 3 matters. Once a fix is in place, test it with the input that originally caused the bug. Then test it with other inputs — including edge cases and inputs you did not try before. A fix that works for one test case but breaks another is not a fix; it is a trade. Sometimes fixes also introduce regressions — new bugs in parts of the program that previously worked. Running a few basic checks after any fix catches regressions before they compound.

Here is the strategy applied to a concrete example. The program below is supposed to read a list of scores, double any score below 50, then print the adjusted list. The final output is wrong but you do not know where the problem starts.

scores = [80, 45, 90, 30, 70, 20, 65]

# ---- STEP 1: filter ----
passing = []
for s in scores:
    if s >= 40:
        passing.append(s)

# ---- STEP 2: double low scores ----
adjusted = []
for s in passing:
    if s < 50:
        adjusted.append(s * 2)
    else:
        adjusted.append(s)

# ---- STEP 3: sort ----
adjusted.sort()

print(adjusted)

The output is wrong. You do not know whether the problem is in the filter, the doubling, or the sort. Apply split-half:

Check 1 — midpoint, after the filter:

print("After filter:", passing)

Output: After filter: [80, 45, 90, 70, 65]. The score 30 is gone (correctly filtered), but 20 is also gone. It should not be — the filter should only remove scores below 40, and 20 is below 40 so it is correctly removed. Actually: 20 is below 40, so removing it is correct. 30 is below 40, so removing it is also correct. The filter looks right. The bug is in the second half — either the doubling or the sort.

Check 2 — midpoint of remaining half, after the doubling:

print("After doubling:", adjusted)

Output: After doubling: [90, 90, 80, 70, 65]. The score 45 should have been doubled to 90 — and there are two 90s. But the original list also had 90 in it. Wait: 45 doubled is 90, and the existing 90 is also in the list. Both correctly appear. But — the condition is s < 50 and 45 is below 50, so 45 is doubled to 90. That is correct. But 45 itself has disappeared from adjusted and been replaced by 90. That is also correct — that is what doubling means. The doubling looks right.

Actually looking more carefully: the expected output given the corrected logic would be [65, 70, 80, 90, 90]. But the output was different. Let us re-examine: adjusted before sorting shows [90, 90, 80, 70, 65] — that is five items. After adjusted.sort() that becomes [65, 70, 80, 90, 90]. If this is wrong, the error must be in what the programmer intended — perhaps they wanted to keep 45 as-is and add the doubled value as a bonus, not replace it. The bug is a logic error in the specification of Step 2, not a Python error.

Split-half located the problem in Step 2 in two checks, without reading all the code in detail.

Here is an example of isolation. A student has a 60-line program that calculates student grades and generates a report. The report totals are wrong. Instead of debugging the entire program, they isolate the calculation:

# Full program (60 lines) - too much to reason about at once

# Isolated version (12 lines) - just the calculation
scores = [85, 90, 78]
weights = [0.3, 0.4, 0.3]

total = 0
for i in range(len(scores)):
    total = total + scores[i] * weights[i]

print("Weighted total:", total)
print("Expected:", 85*0.3 + 90*0.4 + 78*0.3)

Running this small version with known inputs makes the calculation visible in isolation. Either the output matches the expected value — in which case the bug is elsewhere in the 60-line program — or it does not, in which case the bug is in this calculation and can now be diagnosed with only 12 lines to read.

Isolation also has a secondary benefit: it forces you to think clearly about what the code is supposed to do. Writing the expected value explicitly — 85*0.3 + 90*0.4 + 78*0.3 — makes it possible to compare intended behaviour with actual behaviour directly.

Here is a process for checking assumptions systematically. Before looking at the code, write down your assumptions about the state of the program at the moment of the bug:

1. What type is each variable involved? (Integer? String? List? None?)
2. What value does each variable contain? (The exact value — not "a number around 10" but the specific number.)
3. Has the function I am calling been tested on its own? Does it actually work?
4. Is the condition in the if statement what I think it is? Have I evaluated it manually?
5. Have I confirmed the data coming in — from user input, from a list, from a function call — is what I expect?

Then check each assumption using a print statement, the debugger, or a trace. Any assumption you cannot confirm from evidence is a potential location for the bug.

This principle extends to testing functions: before combining multiple functions into a larger program, verify that each function works correctly on its own with simple, known inputs. If you cannot test a function independently, write a short test at the bottom of your file:

def celsius_to_fahrenheit(c):
    return (c * 9/5) + 32

# Quick test — remove before submission
print(celsius_to_fahrenheit(0))    # Expected: 32.0
print(celsius_to_fahrenheit(100))  # Expected: 212.0
print(celsius_to_fahrenheit(-40))  # Expected: -40.0

If each function works in isolation, and the program still produces wrong output when they are combined, the bug is in how the functions interact — how values are passed between them, or how their results are combined. This is a much smaller space to search than the entire program.

Testing edge cases is particularly important. An edge case is an input at the boundary of what the function is designed to handle: zero, an empty list, the minimum or maximum valid value, a string with spaces, a negative number. Many bugs only appear at the edges, and many programmers only test with comfortable middle-of-the-range values.

The rubber duck technique is most effective when you follow a structure:

1. Describe the intended behaviour. "This function is supposed to take a list of numbers and return the average."
2. Describe the actual behaviour. "Instead, it is returning zero every time."
3. Walk through the code line by line. "Line 1 initialises total to zero. Line 2 starts a loop over the list. Line 3 adds each item to total..." At the point where you say something and realise it is not what you intended, stop. That is the bug.

In a course context, this is exactly the skill tested in oral desk checks and project defenses. The ability to explain your code line by line — and notice when your explanation does not match the code — is the same skill as rubber duck debugging. Practicing it while debugging trains the same muscle that oral explanations require.

If the checklist does not help, step away. This is not avoidance — it is a deliberate technique. Extended focus on a problem creates tunnel vision: you start to see what you expect rather than what is there, and your mental model becomes increasingly resistant to revision. A five-minute break, followed by reading the code from the top as if for the first time, frequently surfaces bugs that twenty minutes of intense focus missed.

When asking a teacher or classmate for help, do not say "my code is broken." Explain: the input that causes the bug, the expected output, the actual output, the section of code you believe is responsible, what you have already tried, and what you currently think the cause might be. This preparation forces you to organise your thinking — and often surfaces the answer before you finish explaining.

Here is the same session written out as a process:

Step 1 — Reproduce reliably. The output looks correct for the given input. Add a student with a score of exactly 60 to confirm the bug: ("Frank", 60). Expected: Frank appears in the output. Actual: Frank does not appear. Bug confirmed and reproducible.

Step 2 — Locate the cause. The program is short enough that split-half and isolation point immediately to the filter loop. Check the assumption: does the condition score > 60 include 60? Evaluate manually: 60 > 60 is False. So 60 is excluded. The cause is confirmed: the condition uses strict greater-than when it should use greater-than-or-equal.

Step 3 — Fix and verify. Change score > 60 to score >= 60. Run with Frank: he now appears in the output. Run with the original data: output unchanged (no original student had exactly 60). Run with Bob (45): still excluded. Run with a score of 59: excluded. Run with a score of 61: included. The fix is correct and has not broken anything.

The whole session took three steps and required checking one assumption. Without the test case of exactly 60, the bug would never have surfaced with the original data — which is precisely why testing edge cases and boundary values matters.