When It Breaks (And It Will)

Every tool breaks at some point. Every script has a day where it refuses to run. This is not a sign that you have failed, or that building is not for you. It is just part of the process — and once you know what to do when it happens, it stops being frightening.

This lesson is about that: what to do when the red text appears.

The Red Text Is Not an Emergency

When a script crashes, Python prints what is called a traceback — a detailed message explaining exactly what went wrong and where. At first glance, it looks overwhelming. Several lines of unfamiliar text, a reference to line numbers you have to go find, and an error name you have never heard of.

But here is the thing: that message was written for you. It is telling you, as specifically as it can, what the problem is.

The only skill you need to add is knowing which part of the message to read first.

Read the Last Line First

Python tracebacks print in chronological order — starting from the outermost function call and working inward toward the crash. That means the most important information is at the bottom.

Before anything else, look at the last line of the error. It will look something like this:

KeyError: 'status'

or

FileNotFoundError: [Errno 2] No such file or directory: 'data.csv'

or

TypeError: can only concatenate str (not "int") to str

That last line names the error type and the specific problem. It is the answer to "what went wrong." Once you know that, paste the whole block to Claude and let it explain what to do next.

The Three Zones of Every Error

The diagram above shows what every Python error has in common. You do not need to memorize the technical terms. You just need to know the reading order:

Zone C (the last line): what went wrong — the error type and the specific problem. Read this first, every time.

Zone B (the middle): the call stack — the chain of File "...", line N entries that led to the crash. This is where the file names and line numbers live. Read it from the bottom up: the bottom-most entry is the one closest to the actual bug. Jump here second to know where to look.

Zone A (the first line): the Traceback (most recent call last): header — Python announcing that a crash report follows. Context only; you can skim past it.

The Debug Loop

Once you know the reading order, debugging follows a simple cycle.

The loop is:

1. It breaks. Red text appears. You copy it all.
2. Paste to Claude. Share the full error message. Add context if it helps: "this is a script that reads a CSV and counts rows by status."
3. Try the fix. Make the change Claude suggests — usually one or two lines. Run the script again.
4. If it breaks again, start over at step 1. The new error is a new set of instructions.

Most fixes take one to three rounds. Occasionally more. That is normal for every developer, everywhere.

What Makes a Good Debug Paste

When you paste an error to Claude, include:

• The full traceback — all of it, from "Traceback" to the last line
• A one-sentence description of what the script is supposed to do
• If you recently changed something, mention it: "I just added a new column to the CSV"

You do not need to explain every line of your code. Claude can ask if it needs more.

Common Errors You Will See (and What They Mean)

KeyError — you tried to look up a key in a dictionary or a CSV row that does not exist. Usually a typo or a case mismatch (Status vs status).

FileNotFoundError — the script is looking for a file that is not there, or the path is wrong.

ModuleNotFoundError — the script imports a library that is not installed on your machine (for example, ModuleNotFoundError: No module named 'requests'). The fix is usually one command: pip install requests (or pip3 install requests on Mac/Linux). When Claude writes a script that needs a library beyond Python's built-ins, it will normally tell you what to install — but if it forgets, this error is how you find out.

TypeError — you tried to use a value in a way that does not match its type (mixing a number and text, for example).

SyntaxError — the code itself has a formatting mistake — a missing colon, an unclosed bracket, a stray character. Claude can spot these instantly.

None of these are emergencies. All of them are fixable. The information you need to fix them is already in the error message.

You Are Already Doing This

The debug loop is not special knowledge reserved for professional developers. It is what every developer does every day. The difference is that experienced developers are not surprised when errors appear. They expect them, read them, and move on.

Now you can too.