The Error Message Is the Job, Not the Failure

Ask a working developer what they did today and much of the honest answer is debugging: finding why code does what it does instead of what it should, and fixing it. Students often treat this backwards: writing code feels like the real work, and the red error feels like proof they are bad at it, so they avoid errors by copying finished code or starting over. Each escape skips the skill that matters most — the day you can debug is the day you can work on code you did not write.

The good news is that debugging is a routine, not a talent: a repeatable way of narrowing a problem until it is small enough to see. This article gives you that routine in five steps, one runnable bug to practise on, and a way to use AI and classmates without letting either do the learning for you.

The Routine: Read, Reproduce, Shrink, Fix, Prove

Step one is to read the error, and to read only what it actually says. Error messages look hostile because they are written for the machine, not for you, but they almost always say what went wrong, which line the program reached when it stopped, and sometimes which value was involved. Read the last line first, then look at that one line of code. Do not rewrite the file or change five things at once: if the bug disappears, you will not know which change fixed it, and it will return.

Step two is to reproduce the bug on purpose: run the code again and note the input, the output, and what you expected instead. “It does not work” is not a bug report; “with scores 85, 90 and 78 it prints 26.0 but should print about 84.3” is. Step three is to shrink: delete everything unrelated until the smallest version still shows the bug. Step four is to fix one thing only. Step five is to prove it: run the code again against the expected answer from step two. A fix you have not run is a guess.

Your First Bug: It Runs, and It Is Wrong

Here is the sneakiest kind of bug: a program that runs and answers wrong. Paste it into the browser editor in Python — one of the 34+ executable languages on CoderFile (120+ syntax-highlighted) — and run it before reading further. What should the average of 85, 90 and 78 be? What does the program actually print?

# grade_average.py — it runs with no error. So why is the answer wrong?
scores = [85, 90, 78] total = 0
for s in scores: total = s # <-- read this line very carefully
average = total / len(scores) print("Average:", average)
# Expected: about 84.3. Actual: 26.0. Your job: find why, before scrolling on.

The bug is one character of intent: total = s replaces the total with each score instead of adding to it, so after the loop total is just the last score, 78, and 78 divided by 3 is 26.0. The fix is total += s. Nothing crashed, and the only thing standing between you and a wrong answer was your own expectation: without deciding the answer should be about 84.3 first, you might have submitted 26.0 with confidence. Change the line, run it again, and watch the output become 84.333… — that moment is the whole routine in miniature.

Save both versions as snippets: the broken one labelled with what was wrong, the fixed one with what changed. That pair records a bug you can now recognise. When a future program gives a suspiciously small answer, your first thought will be “am I overwriting instead of accumulating?” — and the old snippet proves you have beaten this bug before.

Learning to Read the Errors That Do Crash

Crashes are kinder than wrong answers, because they announce themselves. A handful of messages cover most student crashes. A NameError means you used a name the program has never seen — usually a typo, or a variable used before creation. A TypeError means you combined things that do not combine, like a number and text. An IndexError means you asked a list for a position it does not have. A SyntaxError means malformed code, often a missing bracket or colon on the line above the one reported. Meet each one, translate it once in your own words, and save that translation with the snippet that caused it.

One habit makes all of these easier: shrink before you panic. Copy the suspicious part into a fresh tab and run it alone. If it still fails, the bug is in those few lines. If it works, add pieces back one at a time until it fails again — faster than staring at a full file hoping the bug will confess.

Use AI and Classmates Without Outsourcing the Learning

AI is genuinely useful for debugging, used the right way: paste the error and the lines around it, and ask what it means and where to look — not for a rewritten file. Then fix it yourself and run it. A fix you cannot explain is a debt: it will fail again in an interview or an exam, where the assistant is not beside you. After AI helps, cover the answer and explain the bug in one sentence in your own words. If you cannot, you have not finished debugging yet.

Classmates are the other underused debugging tool. Explaining a bug out loud often solves it halfway through, because saying what the code should do forces a comparison with what it actually does. Share the runnable snippet and let them run it, not just read it — a classmate with the same wrong answer confirms the bug is real, and one with a different answer has found a clue. The free plan allows up to 3 collaborators per snippet, exactly a small study group, and the built-in developer tools help too: format before sharing, and diff the broken version against the fixed one.

Why This Pays Off Beyond the Assignment

Debugging is also interview preparation in disguise. Interviewers rarely ask for perfect code on the first try; they watch what you do when the first try is wrong. Can you read the error, narrow the problem, test a hypothesis, and explain the fix? That is the routine above, performed out loud. Every bug you save as a before-and-after pair is rehearsal for that moment, and portfolio evidence too: a snippet describing what broke and what you changed says far more than a file that was never wrong. Practising in Lab lessons, where exercises are checked as you go, builds the same habit.

When Debugging Hits a Limit, That Is the Upgrade Moment

Stay on Free ($0: 20 executions a day, 10 AI requests a day, 10 saved snippets, 3 private snippets, 3 collaborators per snippet) while it fits. But a debugging afternoon is exactly when limits show up: repeated runs eat a day’s executions, and before-and-after pairs fill ten saved snippets fast. That is when Pro earns its $9/month or $69/year — unlimited saved snippets and executions, 100 AI requests a day, 10 collaborators per snippet, and unlimited private snippets — and Team ($19/user/month, or $15/user/month billed annually) covers a study group debugging together. See the pricing page for current terms, and upgrade for a limit you hit.

Your next step takes ten minutes. Open the editor, run the grade-average program above, and fix it yourself — no AI rewrite, no copied answer. Then break it again on purpose: change one more line, predict what will go wrong, and run it to check. Save both versions as snippets with a one-line note each about what changed. You will have practised the whole routine and started the bug collection that makes the next error familiar.