Debugging

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

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…

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:

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