How to Debug Code: A Beginner's Guide to Fixing Errors

Every Error Is a Clue

New coders are often scared of errors. They see red text and think "I'm bad at this". But guess what?

Every error is a clue!

An error message is Python telling you exactly where it got stuck and why. It's not a punishment. It's help.

Everyone gets errors

Professional programmers see errors every single day. Big companies have whole teams that do nothing but find and fix bugs. The difference between a beginner and an expert is not that experts make fewer mistakes. It's that experts aren't afraid of them, and they know how to read them.

Errors make you better

Each error you fix teaches you something you won't forget. The first time you forget a bracket, it might take you five minutes to find. The tenth time, you'll spot it in two seconds. That's real learning, and it only comes from making mistakes.

Build confidence with small wins

• Solve one small problem a day. Small wins add up and build momentum.
• Clarity beats syntax. You don't need to memorise everything. Think clearly, and look up the code you need.
• Celebrate fixes. Every bug you squash is proof that you're getting better.

You already know how to read an error message from chapter 2: the line number, the kind of error, and the message. In this topic, you'll learn what to do after reading it.

An error isn't a failure. It's a clue that tells you where to look.

Debug Like a Detective

A detective doesn't guess who did it. They collect clues, test ideas and narrow it down. Debugging (finding and fixing bugs) works the same way.

The detective's method

1. Read the clue. Read the error message: its last line, and the line number.
2. Go to the scene. Look at that line, and the line just before it.
3. Make one change. Fix the one thing you think is wrong. Only one!
4. Test it. Run the code again.
5. Repeat. Still an error? Read the new message, which may be about a different line. Go back to step 1.

Why only one change at a time?

If you change five things at once and the code works, you don't know which change fixed it. And if it breaks in a new way, you don't know which change caused it. One change, one test: then you always know what happened.

When there's no error, but the output is wrong

Sometimes code runs without any error, but shows the wrong thing. Python is happy, but you're not! Then compare the output with what you expected, line by line, and find the first line that's different. The bug is in the code that made that line.

123print("Shopping list:")
print("milk", "eggs", sep="")
print("bread")

No error, but milkeggs should be milk, eggs. The first wrong line points at sep="". Fix it to sep=", " in the editor and run it again.

Read the clue, change one thing, test again.

Check Your Code with print()

Here's a trick every programmer uses, from beginners to experts: add extra print() lines to see what your code is doing.

Checkpoint prints

Put a print() between the steps of your code, like checkpoints in a race. When you run it, each checkpoint that shows up proves the code got that far:

12345print("checkpoint 1")
print("Welcome to the shop")
print("checkpoint 2")
prnt("Here is your receipt")
print("checkpoint 3")

Checkpoints 1 and 2 appeared, but 3 didn't. So the problem is somewhere between checkpoint 2 and checkpoint 3. In a long program, this narrows the search a lot.

Why this works so well

You can't see inside a running program. A checkpoint print is like a window into it. Later, when your programs store and change values, you'll use print() to look at those values too, and check that they are what you expect.

Clean up afterwards

Checkpoint prints are for you, not for the people who use your program. Once the bug is fixed, delete them. In the Comments chapter, you'll learn another way: switching a line off without deleting it.

Lost? Add a print() as a checkpoint, and see how far your code really gets.

What to Do When You're Stuck

Sometimes you read the error, check the line, try a fix, and you're still stuck. That happens to everyone. Here's what to do.

Explain it out loud

Programmers have a famous trick called rubber duck debugging. You explain your code, line by line, to a rubber duck (or a toy, a pet, or a patient friend). Very often, halfway through explaining, you hear yourself say something that doesn't make sense, and there's the bug!

It works because explaining forces you to slow down and look at what the code really says, not what you think it says.

Take a short break

Stuck for more than 15 minutes? Stand up, drink some water, walk around. Your brain keeps working in the background. Many bugs are found in the first minute after a break.

Search the error

Copy the last line of the error message, and search for it. Someone has almost always had the same problem, and the answer is often the first result.

Ask for help, the right way

When you ask a person for help, give them what they need:

• what you wanted to happen,
• what actually happened (copy the whole error message),
• the code, and what you already tried.

A clear question gets a fast answer. And often, just writing the question down helps you solve it yourself!

Stuck? Explain it, take a break, search the error, then ask with details.

Practice: Debugging

Solve these to lock in what you learned in this topic. Each one runs in your browser.

1. 32.Fix a Python Program With Steps in the Wrong OrderEasySolve