Debugging

Learn to compare expected and actual results and fix mistakes systematically.

LESSON COMPASS

What will you use this page for?

Core idea

Debugging is the patient work of finding where a program or robot goes wrong and then fixing only that one step.

Evidence to produce

Complete the page task with your own input, test conditions and reasoning.

Control trap

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.…

Next connection

Comparing More Than One Solution: We will learn to compare different algorithms that solve the same problem by speed, number of steps, and clarity.

Module sources: Python Tutorial · Arduino Learn

LevelBeginner
Age10–16
Duration30–45 min
PrerequisiteFlowcharts
ContentStandard lesson · 1,513 words
Last updated

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.

  1. Write the expected result. What should the program do, exactly? Say it in one sentence first.
  2. Observe. What did the program actually do? Look carefully at the screen, the robot, or the error message.
  3. Shrink. Break the program into small parts. Think about one section, not all of it at once.
  4. Test one at a time. Run each step separately and check its output.
  5. Find the first difference. Mark the first point where the real result splits from what you expected.
  6. 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.

Runtime error table
TypeWhen you notice itExample
SyntaxBefore the program startsUnclosed bracket
LogicWhen the result is wrongSquare loop drawing a triangle
RuntimeIt stops while runningDividing 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.

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:

  1. Write the expected result in one sentence.
  2. What shape does this code draw on the screen? (Hint: 360 ÷ 72 = ?)
  3. Show which line the first difference is on.
  4. 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

Check questions

  1. What is debugging? Define it in one sentence.
  2. Write the six steps of the systematic method in order.
  3. A loop that draws a triangle instead of a square has which type of mistake: syntax, logic, or runtime?
  4. If a robot’s motor turns weakly, which two sources would you check first?
  5. Why is “making too many changes at once” a bad habit?

Answers

  1. It is the process of finding and correcting a mistake in an algorithm or program.
  2. Write the expected result → observe → shrink → test one at a time → find the first difference → change only that step.
  3. A logic error. The code runs and gives no error message, but it produces the wrong shape.
  4. Power (batteries/voltage) and mechanics (a stuck part); checking the connection is also a good idea.
  5. 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.

Start QuizBack to Algorithms
QUESTION POOL

Reinforce this lesson with 10 questions

This lesson has a pool of 20 questions. Each attempt selects 10 and reshuffles the choices.