Debugging is not another way to say “you got it wrong”
An algorithm is an ordered set of clear steps for completing a task. Debugging means comparing what was expected with what actually happened, locating the first useful difference, changing the plan, and testing it again. Here, the child is learning to read a sequence and predict its effect—not merely racing to the goal.
Code.org’s current “Debugging with Laurel” lesson asks learners to read an existing algorithm, notice the effect of a bug, and test and revise until the program behaves as intended. Scratch educator materials similarly recommend testing small pieces at a time and talking through a problem with someone else when stuck.
This activity is not an intelligence, ability, or development test. It does not score or compare children by the number of cards they use. The useful skill is being able to explain: “What did I expect, what happened, and where did the first difference appear?”—then trying the revised sequence.
The Robot Route in 4 rounds
Use a 5-by-5 paper grid, large arrow cards, and a paper robot token. An adult moves the token on the table; each arrow always means one square.
1. Build a safe play area
Mark one square as the start and another as the goal. You may shade no more than two blocked squares. The robot can move one square up, down, left, or right.
Try this: Demonstrate all four commands first. There is no diagonal move, jumping, or leaving the paper, and the meanings do not change during a round.
2. Predict before you run the route
The child arranges the arrow cards from left to right, then predicts the final square without moving any card.
Try this: Ask, “Where will the robot be after the first three commands?” Give the child time to trace the sequence visually instead of supplying the answer.
3. Run one command at a time
The adult moves the token exactly one square for each card. Stop on the card that would send the robot off the page or into a blocked square; do not quietly correct later cards.
Try this: At the stopping point, ask: “What did we expect? What actually happened? Which card began the first difference?”
4. Make one change and test from the start
Choose the smallest useful edit: turn one card, move it, add a missing card, or remove an extra one. Return the robot to the start and rerun the whole sequence.
Try this: When the route works, let the child deliberately misplace one card. The adult becomes the debugger, while the child offers a clue rather than revealing the fix.
A four-question debugging loop
Use the same short sequence for every new route so that debugging becomes a method rather than random guessing.
1. What do we expect?
Name the goal square and describe the robot’s general direction in one sentence.
2. What actually happened?
Run the cards in order and stop at the first square that differs from the prediction.
3. What does that tell us?
Look for the first missing, extra, or misplaced command instead of changing everything at once.
4. Did the change work?
After one edit, return the robot to the start and test the complete route again.
Keep it safe and supportive
Do not make a child walk as a blindfolded “robot,” and do not play near stairs, roads, hot surfaces, or moving furniture. An adult should move the paper token on a table. If younger children are nearby, use large cardboard pieces instead of anything small enough to swallow, and have an adult complete any cutting in advance.
If the route feels hard, shorten it, remove blocked squares, or offer two possible cards. Do not write the answer for the child or compare their speed. No account, camera, location, school detail, photo, or other personal information is needed.
Use the same loop in a coding game
After the paper route, choose a Zeka.land game with a visible source and license. An adult should read its detail page first. Ask the child to explain which command changed—not only whether the level was completed.
Sources
This guide was drafted with AI assistance. Its sources, activity steps, child-safety language, artwork, and English localization were editorially checked during publication preparation.