Debugging

⏱ 8 min✏️ Quiz at the end

Every Programmer Makes Bugs

Here is a secret that beginners are rarely told: professional programmers spend much of their time fixing their own mistakes — and that is completely normal.

An error in an algorithm is called a bug, and hunting them down is called debugging. It is not a punishment for bad work; it is a skill, and one of the most valuable in computing.

Kinds of Bugs

BugWhat happensExample
Sequence errorSteps in the wrong orderbutter the toast before toasting it
Logic errorRuns fine, wrong thinking"add 2" where you meant "multiply by 2"
Condition errorThe test is wrong or flippedIF answer NOT = correct THEN "Correct!"
Loop errorRepeats wrongly — or forevera countdown whose counter goes up
Missing stepA needed action was never writtenforgetting "open the jar" entirely

The sneakiest are logic errors: nothing crashes, no warning appears — the algorithm cheerfully does exactly what you wrote, which is not what you meant.

The Debugging Method

Debugging is detective work, and detectives follow a method:

  1. Reproduce it — find an input that makes the failure happen every time
  2. Trace it — follow the algorithm by hand with that exact input
  3. Locate it — find the first step where what happens differs from what you expected
  4. Fix one thing — change only that step
  5. Re-test — the failing input should now work, and the old working inputs must still work

Rule 4 matters most. Change three things at once and you will not know which one fixed it — or which one quietly broke something else.

Tracing With a Trace Table

Tracing (also called a dry run) means pretending to be the computer: follow each step exactly, keeping a trace table of every variable's value.

Buggy countdown — should print 3, 2, 1 and stop:

SET count = 3
REPEAT UNTIL count = 0:
    OUTPUT count
    ADD 1 TO count      ← suspicious…
StepcountOutput
SET count = 33
output, add 143
output, add 154
output, add 165

The table makes the bug visible immediately: count is rising, so it will never equal 0 — an infinite loop. The fix: subtract 1 instead of adding. One change, then re-test.

Test the Weird Cases

An algorithm that works for the input 7 might still fail for:

  • 0 — does dividing or counting still make sense?
  • Negative numbers — did anyone plan for −5?
  • Huge values — a million? a billion?
  • Empty input — the user pressed enter without typing

These are edge cases, and bugs love hiding in them. When you test an algorithm — including any flowchart you draw — deliberately attack it with strange inputs. Finding a bug before users do is a victory, not a failure.

Explain It Out Loud

One more professional trick: explain your algorithm, step by step, out loud — to a friend, a parent, or even a rubber duck on your desk. Saying each step forces you to slow down, and mid-sentence you will often hear the bug yourself: "…then it checks if the answer is wrong and says Correct — wait."

Programmers really do this. It is called rubber duck debugging.

Worked Example — Debugging a Real, Slightly Trickier Bug

Here is pseudocode meant to find the average of a list of test scores, submitted by a student who is confused why it always reports a suspiciously low number:

SET total = 0
SET count = 0
FOR EACH score IN scores
    total ← total + score
NEXT
SET average = total / count
OUTPUT average

Applying the debugging method from this lesson, step by step: Reproduce it — running with scores = [60, 70, 80] gives an error or a strange result instead of the expected 70. Trace it — build a table tracking total and count through each turn of the loop:

Stepscoretotalcount
start00
turn 160600
turn 2701300
turn 3802100

Locate it — total climbs correctly, but count never changes at all, staying at 0 through every turn of the loop! Fix one thing — the loop is missing a line to increase count, so add count ← count + 1 inside the loop body. Re-test — tracing again confirms count now reaches 3, and average correctly computes 210 / 3 = 70.

Notice that the trace table didn't just reveal that something was wrong (dividing by zero, or a wrong answer) — it pinpointed exactly which variable was misbehaving and when, turning a vague "it's giving weird numbers" complaint into a precise, one-line fix. This is the payoff promised throughout this course: a mechanical, patient process beats guessing, every time.

Key Words

  • Bug — an error that makes an algorithm behave incorrectly
  • Debugging — finding and fixing bugs
  • Trace / dry run — following an algorithm by hand, exactly, with a real input
  • Trace table — a record of every variable's value at each step
  • Edge case — an unusual input (0, negative, empty, huge) where bugs often hide
Related Topics