Read the error, fix the bug

Errors are information, not failure

Professional engineers spend more of their time finding and fixing mistakes than typing new code, so reading error messages is a day-one job skill, not a sign you are bad at this. Without it, the first red message you meet becomes a wall; with it, the message usually tells you exactly where to look.

When the Python interpreter hits a line it cannot understand, it stops and prints an error message instead of guessing. That is deliberate: a guess that happened to be wrong would give you a wrong answer silently, which is far more dangerous than a loud stop. Here is a broken line and what Python says about it:

print("Hello!

    print("Hello!
          ^
SyntaxError: unterminated string literal (detected at line 1)

Read error messages from the bottom up:

• The last line names the kind of problem. SyntaxError you met in lesson 1-2: the text is not valid Python. "Unterminated string literal" means a string was opened with a quote but never closed.
• line 1 tells you where to look, and the ^ arrow points near the spot.

The message will not always describe the fix, but it almost always narrows the search to one line.

Notes to humans: comments

Code is read by people — future you, teammates, reviewers — far more often than it is written, and the code alone cannot say why a value was chosen. Python therefore gives you a way to write notes it will skip: a comment. Everything from a # symbol to the end of that line is ignored by the interpreter completely.

# Ticket math for the school fair
price = 3  # dollars per ticket
print(price * 4)

The first line is a whole-line comment, the second puts a short note after real code. Neither affects what runs.

Good comments explain why ("3 because the fair committee set the price"), not what (the code already says what). You have been seeing comments since lesson 1-2 — every starter line beginning with # was one.