Last time you wrote a plan as pseudo-code and a flow chart, then built it. Today you learn a new habit: step through a program by hand before you run it. You will fill a trace table, predict the output, then check. When the answer is wrong, you will find the bug and fix it.
Keep this tight. Recap in one sentence (plans before builds), then name today's skill: predict on paper first. Students will need paper or a notebook for trace tables; have that ready before the set-up.
A trace table is a simple grid. Each row is one instruction. You write the value of every variable after that instruction runs. By the last row, you know what the program will show, without running it yet.
Worked example. Read this short program:
- Set score to 0
- Change score by 10
- Change score by 5
- Say score
Filled trace table (columns: Step, Instruction, score):
| Step | Instruction | score |
|---|---|---|
| 1 | Set score to 0 | 0 |
| 2 | Change score by 10 | 10 |
| 3 | Change score by 5 | 15 |
| 4 | Say score | 15 (says 15) |
So your prediction is 15. Only then do you run the program and compare. If the run matches, you understood it. If it does not, the mismatch tells you where to look.
Draw a shared grid on the board headed Step | Instruction | score (add a Notes column if you have space). Fill one row per instruction as you go, and leave that grid up so every student uses the same layout for Programs A and B.
Model the worked example one row at a time. Pause after step 2 and ask what score will be next before writing 15. The habit you want is: pencil first, Run second.
Misconception to head off: some students will want to jump straight to Scratch. Hold them on paper for this step; the whole lesson depends on it.
Practise the predict-then-run habit on two short programs. For each one: draw a blank trace table with columns for Step, Instruction, each variable, and Notes, using the grid from the example as your model. Fill it by hand, write your prediction, then check.
Program A (score): whole class first
- Set points to 3
- Change points by 4
- Change points by −2
- Say points
Trace points after every step. What will it say?
Check for Program A: your teacher runs it on the board. Tick a match, or circle the row that went wrong and fix that row. If you miss the board run, ask for the expected output and still tick or correct your table. Final output after check: _______
Before Program B: a filled mini if-row
Sometimes a step is a decision. The if-row still gets a line in the table, and you write which branch runs in the Notes column. Here is a short filled example to re-read if you need it:
- Set lives to 1
- If lives = 0, say "Game over", else say lives
| Step | Instruction | lives | Notes |
|---|---|---|---|
| 1 | Set lives to 1 | 1 | |
| 2 | If lives = 0 … | 1 | Condition false, so else runs; says 1 |
Program B (lives and a decision): pairs
- Set lives to 2
- Change lives by −1
- If lives = 0, say "Game over", else say lives
Your table can start like this (finish the blank cells):
| Step | Instruction | lives | Notes |
|---|---|---|---|
| 1 | Set lives to 2 | 2 | |
| 2 | Change lives by −1 | ||
| 3 | If lives = 0 … | Which branch runs? |
Which branch of the if runs? What will it say?
Check for Program B: your teacher runs it on the board. Tick a match, or circle the row that went wrong and fix that row. If you miss the board run, ask for the expected output and still tick or correct your table. Final output after check: _______
Done looks like:
- A completed trace table for Program A with a written prediction
- A completed trace table for Program B with a written prediction and a note on which branch ran
- Both checked against the teacher Scratch runs, with any wrong row corrected
Put both programs on the board. Pace Program A as a fully teacher-led pass: build the shared table on the board row by row, then rebuild the four steps in Scratch on the IWB only (students stay on paper) and compare together. After the reveal, give about 20 seconds for late finishers to fill the Final output box from the board.
Before releasing Program B, take about one minute to model the mini if-row on the board (the same filled example now sits in student copy so anyone who looks down can re-read it):
- Set lives to 1
- If lives = 0, say "Game over", else say lives
Filled mini table: step 1 sets lives to 1; step 2 condition is false, so else runs and says 1. Stress that the decision still gets a row, and the Notes column records which branch ran.
Then release Program B as pair work on paper only. Circulate and look for students who change two variables in one row, or who skip the if and jump to a guess. When most pairs have a prediction, run Program B once on the IWB as a single teacher reveal and let pairs tick or correct their tables and fill the Final output box.
Answers (release only after predict time):
- Program A: 3 → 7 → 5. Says 5.
- Program B: lives 2 → 1. The condition lives = 0 is false, so it says 1 (not "Game over").
Common slip on B: students assume any lives program ends in "Game over". Press them to follow the condition as written. Point anyone stuck on the branch back to the mini if-row callout above Program B.
Keep both Scratch checks as teacher-led board runs so pairs spend their minutes on the if-row, not typing blocks. Aim to leave Program B with enough time for the decision row. The mandatory student Scratch rebuild comes in the next step on the fixed coin program.
Extension if a group is fast: open one of their earlier saved projects, pick a short stretch of three or four blocks, and trace that stretch the same way on paper.
Here is an unfamiliar program. It is supposed to count coins collected in a short round and finish on 5. It does not. Your job is to trace it, predict what it actually does, find the bug, fix it, then rebuild the fixed version in Scratch and watch it run.
Buggy coin program (supposed to end on 5):
- Set coins to 5
- Change coins by 3
- Change coins by −2
- Set coins to 1
- Say coins
Work in this order:
- Fill a trace table for the buggy program as written. What does it actually say?
- Write one sentence: which step breaks the intended path to 5, and why?
- Fix that step (change only what you must) so a fresh trace ends on 5. Change only one instruction; keep the program four or five steps; your second trace must end on 5.
- In pairs, rebuild your fixed version in Scratch (four or five blocks) and run it. Confirm it says 5 on screen. Tick your table if the live run matches.
Hint: the final value must be 5, not just "closer". If your new trace ends on another number, adjust the same step again.
Use the debugging routine you already know: read the symptom (wrong final value), find the step, form a hypothesis, test it with a new trace, then confirm with a live run.
Must-do:
- A trace of the buggy version with the real final value
- One sentence naming the broken step
- A fixed version of that step
- Fixed version rebuilt and run in Scratch, saying 5 on screen
Stretch if you have time:
- A second full trace table for your fixed version that ends on 5 (paper check before or after the Scratch run)
- A one-line comment above the fixed step explaining the mistake for another coder
Leave the buggy listing on the board. Do not hint at the bug until most of the class has a first trace. Student machines need Scratch ready for the mandatory pair rebuild at the end of this step.
The bug: step 4 says Set coins to 1 (overwrites) instead of something like Change coins by −1. Buggy trace: 5 → 8 → 6 → 1. Says 1. A clean fix is step 4 becoming "Change coins by −1", giving 5 → 8 → 6 → 5.
Accept any fix that is justified and can land on 5 (for example, deleting step 4 also yields 6, which is not 5, so that is not enough on its own; they must land on the target). The student constraint is one instruction changed, four or five steps kept, and the intended final value is 5. The student-facing hint steers anyone who deletes step 4 and stalls on 6.
Pacing for a mixed class: must-do is the buggy trace, the one-sentence diagnosis, the fixed instruction, and a short pair rebuild-and-run in Scratch so every student sees their fix execute. Stretch is the second full paper trace and a one-line comment. Protect about 5 minutes at the end of this block for the Scratch rebuild; four or five blocks is enough once the fix is written. If a pair is still on paper near the end, let them build only the fixed step change on a starter file you open, or join a neighbour's machine for the run-check so nobody skips the live confirm.
Look-fors while circulating:
- Students who spot "set" versus "change" as the key difference
- Students who guess the bug without tracing: nudge them back to the table
- Students who change several steps at once: ask them to change one thing and re-trace
- Pairs who jump into Scratch before a written fix: send them back to the paper step first
If someone finishes early, they should complete the stretch second paper trace and the one-line comment above the fixed step.
A trace table turns "I think it does this" into a step-by-step record you can check. Predicting before you run is how you catch bugs early: the mismatch between your table and the real output points at the broken step. That is testing and managing errors on purpose, not by guessing.
Take two quick contributions: one student names what their buggy step was, another names how they knew the fix would work (second trace or the Scratch run). Keep it to three minutes. Link back to the debugging routine from earlier in the strand without turning it into a lecture.
Unlock the full learning experience
You're previewing this lesson. Get full access to this lesson and hundreds more — each one ready to teach, with interactive activities, printable resources and pupil progress tracking built in.
This lesson is copyright of Coding Ireland 2017 - 2025. Unauthorised use, copying or distribution is not allowed.