One-sentence summary
Debugging is the patient work of finding where a program or robot goes wrong and then fixing only that one step.
Why does it matter?
Everyone who writes code makes mistakes. When something did not work on my first try, I used to feel surprised. Then I realised the real skill is not writing without mistakes; it is being able to find them. If a robot turns the wrong way or a loop draws too few sides, we can treat it as a puzzle instead of a failure.
Learning to debug makes you independent as a programmer. When you get stuck, instead of saying “it does not work, I deleted it,” you can say “it stops here, let me try this.” This lesson shows a systematic way to do exactly that.
Short definition: Debugging is the process of finding and correcting a mistake in an algorithm or program.
A systematic debugging method
Making random changes usually makes the problem bigger. Following the order below is much safer.
- Write the expected result. What should the program do, exactly? Say it in one sentence first.
- Observe. What did the program actually do? Look carefully at the screen, the robot, or the error message.
- Shrink. Break the program into small parts. Think about one section, not all of it at once.
- Test one at a time. Run each step separately and check its output.
- Find the first difference. Mark the first point where the real result splits from what you expected.
- Change only that step. Make a single change, then try again. If it works, great; if not, undo it and try something else.
The heart of this method is simple: change only one thing at a time. That way you truly learn what worked.
Example: A loop that draws a triangle instead of a square
We want a character to draw a square, but a triangle appears on the screen.
Expected: A four-sided square
Observation: Three sides are drawn, then it stops
Shrink: Look only at the repeat section
First difference: The repeat count is written as 3
Fix: Change the repeat count to 4
The first difference appears on the “repeat count” line. So there is no need to delete all the code; we fix only that single line.
Example: A wrong threshold value
A robot should stop when it is closer than 10 cm to an obstacle. But the robot never stops until it bumps into it.
Expected: Stop if distance is less than 10 cm
Observation: The robot never stops
Shrink: Is the sensor reading correct? Yes, it reads 8 cm
First difference: The condition says "> 10" but should be "< 10"
Fix: Correct the comparison
Here the sensor works and the motor works. The only problem is the direction of the comparison. You find it by checking each part separately.
Types of mistakes
Mistakes do not all look the same. Knowing three main types makes it easier to know where to look.
Syntax error
Code that breaks a writing rule, such as forgetting a symbol or leaving a bracket open. The computer usually tells you and gives an error message. In Python, forgetting a colon is this kind of mistake.
Logic error
The code runs and gives no error message, but produces the wrong result. The loop that draws a triangle instead of a square is an example. These are the sneakiest, because the computer does not say “something is wrong here”; you have to notice the result yourself.
Runtime error
The program starts, runs for a while, then stops at some point. For example, trying to divide a number by zero or open a file that does not exist. The code is written correctly, but it meets an unexpected situation while running.
| Type | When you notice it | Example |
|---|---|---|
| Syntax | Before the program starts | Unclosed bracket |
| Logic | When the result is wrong | Square loop drawing a triangle |
| Runtime | It stops while running | Dividing by zero |
Where do robot problems come from?
In robots, a problem does not always come from the code. Checking four main sources in order is a good habit.
- Code: The logic or a threshold value may be wrong.
- Connection: A wire may be loose or plugged into the wrong pin.
- Power: The batteries may be flat or the voltage too low. If a motor turns weakly, look here first.
- Mechanical: A wheel may be stuck, a screw loose, or a part caught on something.
Once I searched a robot for hours thinking “the code is broken,” only to find a loose wire. That taught me to check the simplest, most physical things first.
Pseudocode: Test the robot step by step
Start
Write the expected behaviour in one sentence
Read the sensor alone and show its value
If the sensor value does not make sense
check the connection and the power
Run the motor alone for a short time
If the motor does not turn as expected
check the power and the mechanical parts
Leave the code logic for last and test it step by step
End
Python: Making a simple logic error visible
To see what happens in a loop that draws a square, we can use print at each step. This is one of the easiest ways to observe.
side_count = 3 # Bug: should be 4 for a square
for step in range(side_count):
print("Drawing side:", step + 1)
# move forward and turn 90 degrees
print("Total sides:", side_count)
When we see the output say “Total sides: 3,” we spot the first difference right away. Changing side_count to 4 fixes it.
Mini practice
The pseudocode below has a logic error. A character is supposed to draw a pentagon (5 sides).
Start
Repeat 6 times
move forward 1 step
turn right 72 degrees
End
Task:
- Write the expected result in one sentence.
- What shape does this code draw on the screen? (Hint: 360 ÷ 72 = ?)
- Show which line the first difference is on.
- Fix it by changing only that single line.
Explain your answer to an adult or a friend: “The expected result was this, the observation was this, the first difference is here, and my fix is this.”
Common mistakes
Deleting everything
When something fails, it is tempting to delete all the code and start over. But then you never learn what the mistake was, and you will make it again. Find the mistake first.
Making too many changes at once
If you change three things and run it again, you will not know which one worked when it fixes. Change only one thing each time.
Not reading the error message
The computer’s error message is not a punishment; it is a clue. It usually tells you which line and what kind of problem there is. Looking for a fix without reading it is like asking for directions without opening the map.
Safety note
When checking robotics parts (wires, batteries, motors), turn off the power first. Do not try to fix a loose wire or a stuck wheel while the power is on; your finger could be caught by the motor, or a short circuit could happen. Do all checks with batteries, motors, and wires together with an adult.
Lesson summary
- Debugging is finding a mistake and fixing only the relevant step, not deleting everything.
- Systematic method: write the expected result, observe, shrink, test one at a time, find the first difference, change only that step.
- There are three types of mistakes: syntax, logic, and runtime.
- Robot problems can come from code, connection, power, or mechanics; check the simplest, most physical one first.
- Change only one thing at a time and always read error messages.
Check questions
- What is debugging? Define it in one sentence.
- Write the six steps of the systematic method in order.
- A loop that draws a triangle instead of a square has which type of mistake: syntax, logic, or runtime?
- If a robot’s motor turns weakly, which two sources would you check first?
- Why is “making too many changes at once” a bad habit?
Answers
- It is the process of finding and correcting a mistake in an algorithm or program.
- Write the expected result → observe → shrink → test one at a time → find the first difference → change only that step.
- A logic error. The code runs and gives no error message, but it produces the wrong shape.
- Power (batteries/voltage) and mechanics (a stuck part); checking the connection is also a good idea.
- Because when it works, you cannot tell which change fixed it, so you have not really solved the problem.
Source and verification note
For “Debugging”, verification focuses on whether the relationship between A systematic debugging method and Example: A wrong threshold value remains consistent across examples. The algorithms in this lesson are checked by tracing sample inputs by hand and comparing them with expected outputs. Pseudocode is used to make the reasoning sequence visible without tying it to one programming language.
Next lesson
Comparing More Than One Solution: We will learn to compare different algorithms that solve the same problem by speed, number of steps, and clarity.