Errors are friends, actually

The first time I saw a Python error, my stomach dropped. It was a wall of red text, several lines tall, with words like "Traceback" and "module" and a file path I didn't recognise. I assumed I'd broken something serious. I closed the laptop. I came back to it the next day.

I want to save you that day. Errors in Python are not punishment. They are the language trying — sometimes clumsily — to tell you what went wrong and where. Once you learn to read them, they go from terrifying to useful in about a week.

Read the last line first

Python errors are printed top to bottom, but the most useful piece of information is almost always at the bottom. The lines above it are the path the computer took to get there. The line at the bottom tells you what actually broke.

So when you see a red wall of text, don't read it like a book. Read it like this:

1. Look at the last line. That tells you what kind of error and what the problem is.
2. Look at the line just above the last line. That tells you which line of your code triggered it.
3. Only if you still don't get it, scroll up and read the rest.

That's the whole trick. It takes ten seconds and it works most of the time.

A real example: TypeError

Here's a piece of code a Week 1 student might write:

application_fee = input("Enter the application fee in USD: ")
transcript_fee = 30
total = application_fee + transcript_fee
print("Total:", total)

You run it, type 80, hit enter, and Python yells at you:

Traceback (most recent call last):
  File "fees.py", line 3, in <module>
    total = application_fee + transcript_fee
TypeError: can only concatenate str (not "int") to str

Read the last line first: TypeError: can only concatenate str (not "int") to str.

Translated to English: "You tried to add a string and an integer together. I don't know how to do that. Pick one."

Look one line up: it points to total = application_fee + transcript_fee. That's the line that broke.

Now you know exactly where and why. input() always gives you a string, even if the user typed digits. You need to convert it to a number first:

application_fee = int(input("Enter the application fee in USD: "))

That single error message taught you something real about how input() works. That's why I call errors friends — they correct you immediately, in private, with no judgement.

Another one: KeyError

Now suppose you're working with a dictionary about a scholarship:

scholarship = {
    "name": "Chevening",
    "country": "UK",
    "level": "Masters",
}
 
print(scholarship["deadline"])

Python responds:

Traceback (most recent call last):
  File "scholarship.py", line 7, in <module>
    print(scholarship["deadline"])
KeyError: 'deadline'

Last line: KeyError: 'deadline'.

Translated: "You asked me for the key deadline in this dictionary. There's no such key."

Look up at the next line — yes, line 7, the one with scholarship["deadline"]. That's where the issue lives. The fix is to either add a deadline key when you create the dictionary, or check whether the key exists before reading it:

if "deadline" in scholarship:
    print(scholarship["deadline"])
else:
    print("No deadline recorded.")

Notice what happened. The error didn't break your day. It told you precisely which key you assumed was there but wasn't.

Two habits that change everything

Habit one: copy and paste the last line. When you don't recognise an error — and you won't recognise most of them, at first — copy the last line and paste it into Google. Add the word "python" in front if you like. Stack Overflow, the Python docs, and increasingly an AI assistant will explain it. Every working programmer does this. Senior engineers do this. It's not cheating; it's the job.

Habit two: ask out loud. In the cohort channel, in office hours, with a classmate sitting next to you. Paste the error, paste the code, say what you were trying to do. Nine times out of ten the act of writing it down for someone else makes you spot the problem before they answer. The tenth time, someone answers and you both learn.

Getting stuck is not failure

Here's something I wish someone had told me when I started: being stuck is not evidence that you're bad at this. It's evidence that you're doing the actual work. Every programmer you admire has stared at an error message and felt dumb. Then they read the last line. Then they searched. Then they fixed it. Then they moved on.

The skill we're building in PySprout isn't "never see an error." It's "see an error, read it, and keep going." That skill, more than any specific bit of Python, is what makes a real programmer.

So next time the red text shows up, take a breath. Scroll to the last line. Smile a little. Your friend is trying to tell you something.