When It's Wrong

Every program you write will, at some point, do the wrong thing. Every one.

The difference between someone who programs and someone who gets stuck is not that the first makes no mistakes. It is that they know how to find them.

A bug you can see

Here is a program meant to double a number:

ASK "A number? " INTO n
SHOW "Double it: ", n + 2

Type 5. Double five is ten, so you expect 10:

A number? 5
Double it: 7

7, not 10. The computer did nothing wrong. It did exactly what the second line says. The bug is that the second line does not say what you meant.

So: you look at what it did (7, and you wanted 10). You narrow down to the line that works the number out. You read that line: n + 2. For 5, that gives 7. You wrote add two where you meant times two.

ASK "A number? " INTO n
SHOW "Double it: ", n * 2

A number? 5
Double it: 10

One character. The fix was a keystroke; the skill was finding which keystroke.

That is the whole method, and it never changes. Look at what the program did. Compare it with what you wanted. Narrow down to the line responsible. Read that line for the gap between what you wrote and what you meant.

When you cannot see it

Sometimes the wrong answer does not tell you enough. Then you make the program show you more of its working:

LET total = 0
FOR EACH price IN prices
  SHOW "adding ", price, " to ", total
  LET total = total + price
END
SHOW "Total: ", total

That extra SHOW is not part of the program you want. It is there to let you watch the values change, and you take it out afterwards. Doing it on paper works too:

Read what the machine tells you

When a program does not just misbehave but stops, whatever you ran it with will tell you something. It usually names a problem and a place.

That is a gift. It points straight at where to look. The people who stay stuck are the ones who see a message and freeze, as though it were a telling-off. The ones who get unstuck read it: what does it say, and which line does it name? Half of debugging is reading the message the machine already wrote for you.

Suspect your own code first

The moment something goes wrong, look at what you wrote. Not because machines and tools are flawless, but because your own slips are far more common than their faults, and far easier to find.

If you truly think the fault is not yours, earn it. Cut the program down to the smallest piece that still goes wrong. Check that it goes wrong every time. Try the same thing somewhere else and see whether it agrees. Doing that usually finds your bug, which is exactly why it is the habit that gets you unstuck fastest.

What you’ve learnt

• Every program misbehaves. Finding out why is the skill that separates getting it done from getting stuck.
• The method never changes: look, narrow down, read.
• When you cannot see it, make the program show its working, or trace it on paper.
• A message is information, not an insult. It names a problem and a place.
• Suspect your own code first, and earn the right to blame anything else.

Where to go from here

That is the course. You hold every idea that goes into a program: instructions and order, output and memory, input, arithmetic, decisions, loops, lists, named jobs, and how to find your way when one goes wrong.

None of it was about a language. You saw each idea in plain words so that you would know it again wherever you meet it.

So that is what comes next: pick a language to say these ideas in properly, on a machine you like the look of. Meet BASIC teaches the Spectrum’s own, and builds real games with it. The same ideas wear the Commodore 64’s BASIC, the Amiga’s AMOS, and others besides. Or head for the metal, down through the number systems a machine counts in and on into assembly.

Whichever you pick, you are not starting from nothing. You already have the ideas, and every language is a way of writing them down.