Phase 5: Debugging Methodology · ~35 minutes · Python · debugging methodology

Systematic (Scientific) Debugging

A real comparative study measured it directly: novice programmers given systematic debugging instruction went from 60% to 80% correctness, and their median time dropped from 28.7 to 10.7 minutes. This isn't a soft skill — it's a measured one.

Hiring signal: Changes exactly one thing at a time when debugging, and can always say what specific hypothesis a change was testing

What you will learn

Apply hypothesize -> predict -> test -> observe as an explicit discipline, not just faster guessing
Explain why changing multiple things at once destroys the ability to know what actually mattered
Debug a genuinely non-obvious, intermittent-seeming bug systematically
Explain why a debugging log with two simultaneous changes is inconclusive

Introduction

Type: Learn Languages: Python Prerequisites: Lesson 02 (Reading a Stack Trace) Time: ~35 minutes

Objective

Learning objectives

Apply hypothesize → predict → test → observe as an explicit discipline, not just faster guessing
Explain why changing multiple things at once destroys the ability to know what actually mattered
Debug a genuinely non-obvious, intermittent-seeming bug systematically
Explain why a debugging log with two simultaneous changes is inconclusive

What you're building

A genuinely non-obvious, intermittent-seeming bug (this lesson's mutable-default-argument example, or one of similar subtlety of your own construction):

Write out an initial hypothesis about the cause — specific and falsifiable, not vague
State a concrete prediction that would confirm or rule it out
Run exactly one test targeting that prediction, changing nothing else
Record the actual observation, and whether it confirmed or ruled out the hypothesis
Repeat this cycle (new hypothesis if the first was wrong, or a fix-verification cycle if it was right) until the bug is genuinely understood and fixed
Submit the complete log as debug_log.txt, following this lesson's format exactly — every cycle must show one specific change and one specific observation

A debugging log reads: "Hypothesis: the off-by-one is in the loop bound. Test: changed range(n) to range(n+1) AND also added a print statement AND reordered two unrelated lines. Observe: bug is gone." What's the accurate assessment of this log?

This is exactly this lesson's central trap. Even though the bug did go away, three simultaneous changes make the result genuinely uninterpretable: the range(n+1) fix might be entirely correct and sufficient on its own, or the line reordering might have coincidentally also mattered, or the 'fix' might not even be the range change at all. There is no way to know from this log which change was load-bearing — a real, working outcome, paired with zero actual understanding of why, which is a fundamentally weaker result than a single-change cycle would have produced, even if it took one extra test to get there.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.