Hack University - 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 rather than 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, meaning 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. That narrowing is the whole value, and it is why the instinct to skim past the red text and re-read the whole file is the wrong one.

Fixing an unterminated string

The broken version opens a string and never closes it.

print("Coding is fun!)

The corrected version closes the quote before the parenthesis.

print("Coding is fun!")

Output

Coding is fun!

Reading the fix

The error names the problem directly: an unterminated string literal. Reading it before reading the code points you at the quote rather than at the parenthesis.
A string must end with a closing quote before the parenthesis closes, so the order is quote, then parenthesis.
The broken line is a good illustration of why Python stops. Without the closing quote, everything after it, including the ), is just characters inside an unfinished string, so Python reaches the end of the file still waiting for the string to end.

Notes to humans: comments

Code is read by people far more often than it is written, whether that reader is future you, a teammate, or a reviewer, 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, and the second puts a short note after real code. Neither affects what runs.

Good comments explain why, as in "3 because the fair committee set the price", rather than what, since the code already says what. A comment reading "multiply price by 4" next to price * 4 adds nothing and still has to be maintained.

You have been seeing comments since lesson 1-2, since every starter line beginning with # was one.

Comments changing nothing

The two comments are invisible to the interpreter.

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

Output

Python skips everything from # to the end of the line, so only price = 3 and the print actually run. The output is the same as it would be with both notes deleted.

Removing the # from the first line would produce an error, because "Ticket math for the school fair" is not valid Python. That is worth trying deliberately once, since it makes the point that the # is doing real work: it is the only thing separating a helpful note from a syntax error.

What the interpreter does with a comment

Given a line reading # double the score, the interpreter ignores the whole line.

Everything after # is a comment for humans. The interpreter skips it entirely, so nothing is doubled and no score changes.

If you want the score doubled, you have to write real code such as score = score * 2 on an uncommented line.

This is a genuinely common source of confusion, and usually in the reverse direction. Commenting out a line is how programmers temporarily disable code, so a # in front of a working line silently stops it from running, and a puzzling "my change did nothing" is often exactly this.