Debugging is a method, not a talent

You already read an error message in the last unit. That was one skill. This is the other one, and it is the difference between an hour and a week.

Most people, when something breaks, start changing things. They try one idea, then another, then a third, and if it starts working they do not know which change fixed it — which means they cannot fix it again. That is not debugging. That is shuffling.

You are not hunting a bug

You are hunting the first place where reality stopped matching what you believed.

Every program you write is a stack of beliefs. "The file loaded." "The number is a number." "The response has a close field." When something breaks, one of those beliefs is false, and everything after it is nonsense. Your job is not to spot the mistake by staring. It is to find the earliest false belief and check it.

The method

1. Make it happen on demand. A failure you cannot reproduce is one you cannot fix, because you will never know whether it is gone. Write down the exact steps. If it only happens sometimes, note what is different when it does.

2. Read the whole error, bottom line first. Errors are printed with the deepest call at the top and the most useful line usually near the bottom — the file and line number of your own code. Skip the parts inside libraries you did not write. Read the last line, then the last line that names a file you recognise.

3. Say out loud what you believe. "At this point, rows is an array of five objects." Full sentence, specific.

4. Check that belief. Print it. console.log("rows:", rows) on the line before the one that fails. Not a guess — a look.

5. Change exactly one thing.

Printing is not cheating

Beginners hesitate to add console.log as though it were an admission of failure. Professionals do it constantly. It is a window into a running program, and a running program is otherwise completely opaque.

Print the thing, not a message about the thing:

console.log("about to parse");        // tells you almost nothing
console.log("body:", body);           // tells you what actually arrived

Label your prints with the variable name. Three unlabelled numbers in a terminal are worse than none.

"It worked yesterday" is evidence

If it worked before and does not now, something changed, and the list of things that changed is short. Your code (check git diff and git log). Your data. Something outside — a service that is down, a key that expired, a network you are not on.

That is why the last unit had you commit. git diff answers "what did I change?" in one command, and that question is the fastest route to most failures you will hit this year.

The trap

The trap is the fix that works for a reason you never found out. You changed three things, it works, you move on. Two days later it breaks again and you have no idea why, because you never knew why it worked.

If a change fixes it, undo the change and confirm it breaks again. That takes ten seconds and turns a coincidence into knowledge.

Try it now

Take the program you wrote in unit 2 and break it on purpose: misspell a variable name somewhere in the middle. Run it. Read the error and find the line number before looking at your code. Then fix it. Do it again with a different kind of break — return a number where a string is expected — and notice that the second failure does not announce itself nearly as loudly.