Bugs are normal
Every programmer, including very experienced ones, writes code that does not work the first time. A bug is simply a difference between what you meant the program to do and what it actually does. Debugging is the process of finding that difference and removing it.
Beginners often read a bug as a sign that they are bad at coding. A more useful view is that bugs are information. The computer is doing exactly what the instructions say, and your job is to find which instruction does not match your intention. That shift, from “I failed” to “something here is a clue”, is most of what people mean by a debugging mindset.
The same approach works outside programming: a spreadsheet total that looks wrong, a recipe that turns out badly, a device that will not connect. The steps below apply to all of them.
Step 1: Reproduce the problem
You cannot fix what you cannot see. Reproducing means finding a reliable way to make the problem happen again.
Write down:
- what you did, in order
- what you expected to happen
- what actually happened, including the exact text of any error message
Exact wording matters. “It crashed” tells you little. An error message that names a line number and a type of problem often points straight to the area you should inspect.
If the problem only happens sometimes, note what differs when it does. Different input, a different order of actions or leftover data from an earlier run are common causes.
Step 2: Read the error message
Beginners often skip straight past error messages because they look like noise. They are usually the most useful clue available. Most messages tell you three things: what kind of problem occurred, where in the code, and sometimes what value was involved.
Read from the bottom of a Python error upward; the last line usually names the type of error and the lines above show where it happened. You do not need to understand every word. Pick out the line number and the name of the problem, and go look there. Be aware that the real cause is sometimes slightly earlier than the line reported.
Step 3: Isolate the cause
Isolating means shrinking the search area until the faulty piece is small enough to see. Useful techniques include:
- Divide and conquer. If a program has ten steps, check the state halfway. If the data is already wrong at step five, the bug is in steps one to five. If it is still right, look at six to ten. Repeat.
- Print what you have. Temporarily show the value of a variable at key points. Seeing the real value often beats guessing.
- Simplify the input. Try the smallest possible example that still fails.
- Comment out parts. Disable sections until the problem disappears, then restore them one by one.
Here is a tiny Python example. The goal is to compute the average of three numbers:
a = 4
b = 6
c = 8
average = a + b + c / 3
print(average)The program prints a number a little above 12 (about 12.67), but the average of 4, 6 and 8 is 6. Reproduce it: the same wrong result appears every time. Isolate it: print each piece. The value of c / 3 is about 2.67, and adding that to 4 and 6 gives about 12.67. That reveals the cause: division is applied before addition, so only c is divided by 3.
The fix is parentheses so the sum is calculated first:
average = (a + b + c) / 3Now 18 / 3 gives 6.0, which matches the expected answer. The cause was the order of operations, a rule from basic arithmetic that programming languages follow too.
Step 4: Form a guess and test one change
Once you suspect a cause, state it as a guess: “I think the division happens before the addition.” Then make one change and run the code again. Changing several things at once is a common trap, because if the problem disappears you do not know which change fixed it, and if it gets worse you do not know which caused that.
This is the same logic as a controlled experiment: vary one thing, keep everything else the same, and observe.
Step 5: Confirm the fix and look for relatives
After a fix, run the original failing case and a few others, including awkward ones such as zero, an empty list or a very large number. A fix that works for one input can break another.
Then ask whether the same mistake could appear elsewhere. If you misunderstood a rule once, you may have used it wrongly in other places.
Habits that help
- Take breaks. Staring at the same lines for an hour rarely helps. Stepping away often brings a fresh idea.
- Explain it aloud. Describing the code line by line to a friend, or even to an object on your desk, often exposes the faulty assumption. Programmers sometimes call this rubber duck debugging.
- Question your assumptions. “This part is definitely fine” is the most common last thing checked and first thing wrong.
- Save working versions. If you can return to the last version that worked, you can compare the two and find what changed. Version control is built for exactly this.
- Search with the exact error text. Chances are others have met it. Treat what you find as ideas to test rather than answers to paste in blindly, and be careful about running unfamiliar code.
When you are stuck
Being stuck is normal. Write a clear description of the problem: what you expected, what happened, what you tried. Often writing it exposes the answer, and if not, it is exactly what you need to ask someone else for help.