Debugging as a Method: Reproduce, Isolate, Fix
Working from a fault to its cause by a repeatable route: reproduce it reliably, cut the program down until the fault is cornered, then change one thing and check. Guessing edits is the habit this replaces.
What a learner can do afterwards
- Turn a vague fault report into a repeatable set of steps that shows it every time
- Narrow a bug down by halving the suspect region rather than reading the whole file
- State a hypothesis about the cause, then design the one check that would refute it
1 · Read
You start every fix with a reproduction: steps that show the fault every single time. You rerun the program the same way, then shrink to the smallest input that still triggers it. A tiny failing case beats a hundred guesses because you can rerun it after each change.
You isolate by halving the suspect region: switch off half the code and see if the fault stays. You can also rewrite the suspect block as plain steps and trace it by hand with the failing input. When your hand trace and the machine disagree, you have found the exact line where your model breaks.
You then state a hypothesis: a claim about the cause plus the one check that would prove it wrong. You change one thing, rerun the reproduction, and compare. Keeping notes on each try builds your personal bug catalogue, and old faults start looking familiar.
You only edit once the fault is cornered to one line, and you verify by rerunning the reproduction. Guessing edits without reproducing leaves you unable to tell whether any change fixed anything.
Reproduce every time, halve to one line, change one thing and rerun.
2 · Watch
Take it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.