What is debugging
By the time we reached inheritance, we'd built a fairly large program (Lesson 13). But any program you build goes wrong somewhere. One typo or one wrong assumption is enough. Going wrong isn't failure; it happens all the time, and calmly finding and fixing it is called debugging.
Where it stopped is the first clue
When a program goes wrong, it doesn't quietly die; it stops at one spot.
And it points to that spot: "here, this line."
That pointer is the most valuable first clue. An error tells you first where things stopped.
Press run and the steps light up one by one, then stop right at the spot where things went wrong.
You can see at a glance where it stopped.
Next, red text appears at that spot.
Many people panic when they see that text, but it's actually on our side.
Red text is a hint, not a scolding
The red text isn't telling you off.
It's a note saying what the computer couldn't understand.
It usually has two parts: the place (where) and the kind (what), like "this isn't a number" or "there's no such name."
Once you learn to read it calmly, you've solved half the problem.
Tap the pieces of the message and "where" and "what" light up separately.
Read the message split into "where" and "what," and the scary text suddenly looks friendly.
But the spot the message points to isn't always the real cause.
In a long program, how do you narrow down the cause quickly?
Cut the range in half
When you don't know where the bug is, don't read everything from the start; look at the middle.
Is everything fine up to here? Then the bug is in the second half; if not, it's in the first half. Then split again.
Cutting in half like this finds the culprit fast, even in a long list of lines.
Each press of "check middle" halves the range, depending on whether it's fine or broken.
After a few presses, the range narrowed to a single spot.
You pinpointed the culprit without looking at everything.
Now that you've found the cause it's time to fix it, but there's one trap that's easy to fall into.
Change one thing at a time, then check
Just because something looks like the cause doesn't mean you should change everything at once.
Change five places at the same time, and even if it gets fixed, you won't know which change did it.
If a new problem appears, you won't know what caused it either.
So change one thing, run it, and look.
Change just one candidate and press check, and the cause becomes clear. Change several and it's unclear which one fixed it.
Changing things one at a time made the real cause clear.
You know exactly what the culprit was, and you fixed it.
So is that the end? There's one step left, because "it seems fixed" and "it's fixed" are different.
After fixing, always run it again
Thinking you've fixed it isn't the end.
It's only done when you run it again and see with your own eyes that it passes all the way through.
As a bonus, check that nothing that used to work has broken.
This loop of "fix, then check again" is the line between guessing and truly fixing.
Press "run again" and the fixed program passes all the way through in green.
Now we know how to build things (Lessons 1–13) and how to find and fix them when they go wrong (Lesson 14).
But how do the words we write become something a machine actually runs?
In the next lesson, we'll follow the path from that text to the machine's work.