Debugging like a pro

The string of lights will not turn on, the wifi is acting up, your program produces nonsense. The first impulse is the same for everyone: poke around wildly and hope. Pros do something different. They close in on the bug systematically, like detectives ruling out suspects one by one. You are about to learn these methods, and they work on code just as well as on broken bikes.

Halving: closing in like binary search

Instead of checking every spot one by one, you split the problem into two halves and check which half contains the bug. Then you halve that half again, and so on. You already know this idea: it is exactly binary search! Count it through on a small example: 16, 8, 4, 2, 1. For 16 lines that is four halvings. With 1000 lines of code you reach the single faulty spot after at most 10 halvings, instead of going through up to 1000 lines one by one. For this to work you need two things: you must be able to split the problem into independent halves, and you need a repeatable test that tells you which half contains the bug. Then the trick works in many places: comment out half the function, or narrow down half of a recipe's ingredient list.

Form a hypothesis, test it deliberately

Good debuggers do not guess, they form hypotheses: I think the bug only happens with empty input. Then they build a test that checks exactly that hypothesis, changing only one thing at a time. If the hypothesis holds, you have cornered the bug. If it does not, you have still learned something and can cross one suspect off the list. It is important to jot down the result of every test, otherwise you end up checking the same thing twice.

Explain out loud and build checklists

A surprisingly powerful trick is the explain method: explain your program out loud, line by line, to another person or even to a rubber duck. As you say it, you often notice yourself where your explanation no longer matches what the code really does, and that is exactly where the thinking error sits. And once the bug is found, do not throw the insight away: write yourself a checklist of your most common mistakes, for example typos in names, swapped comparison signs, forgotten starting values. For the next bug you go through the list first, which often saves half the search.