I am a robot. I only do exactly what you say, word for word. Tell me how to walk from here to that chair.
Call out one instruction at a time. Watch carefully what I do.
The floor grid should already be taped before pupils enter (see Before the Lesson). For this hook, stand at a clear open spot facing a chair a few metres away. Do not use the grid yet; that comes in the investigation.
Accept the first instructions the class calls out and deliberately obey them literally.
Misinterpret on purpose: if someone says "go over there", take one tiny step in a random direction. If they say "turn", spin slowly in place until they stop you. If they say "walk forward", take one step only. Keep it playful, never mocking.
After 60–90 seconds, freeze and ask: Why did I not reach the chair? Draw out the idea that unclear words left you guessing. Promise: today we will learn to give instructions so clear that a robot (or a computer) cannot get them wrong.
Before the lesson: clear a floor space and tape the 4-by-4 grid of squares about 40 cm each so it is ready when pupils arrive; have start and target markers and instruction sticky notes ready for the investigation.
The chair walk went wrong because the steps were not clear enough. Two words for that:
Algorithm — a precise list of steps in a fixed order that gets a job done.
Bug — a mistake in the steps that makes the wrong thing happen.
Next we will write a real algorithm on the floor grid and fix any bugs we find.
Keep this board beat short (about five minutes). Project only the short text above. Bridge once from the chair walk: Was that an algorithm yet? Where was the bug? Then move straight to the floor so the words attach to action.
Use the table below as your own reference while you teach. Name debugging live in the floor run ("finding and fixing the bug") rather than as a third board word to memorise first. "Precise" is plain language inside the algorithm idea, not a separate term to learn.
| Concept | Why it matters | Example |
|---|---|---|
| Algorithm — a precise list of steps in a fixed order that gets a job done | It is the plan a computer, a robot, or a person can follow without guessing | Forward, turn right, forward, forward — the path from the start square to the star |
| Bug — a mistake in the steps that makes the wrong thing happen | One wrong or missing step can send the whole plan off course | Forgetting a turn so the robot walks into a wall instead of the target |
| Debugging — finding the mistake and fixing it, then trying again | Every coder does this; a bug is information, not a failure | Spot the missing turn, add it, run the sequence again and reach the target |
Misconception to head off: children often think the robot is "being silly" or that they themselves are bad at this. Name it clearly: the robot is doing its job; the algorithm needs a fix. A bug is useful because it shows exactly which step to change.
We have a floor grid with a start square and a target.
Your job: write an algorithm that walks the robot from start to target, staying on the grid squares.
Allowed words only: forward, turn left, turn right.
Rules: each forward moves one square. Each turn means you stay on the same square and face a new way (a quarter-turn on the spot — watch me show it with my feet).
Agree every step in order in your group. Dry-run it at your table first. Then one group will run theirs with me as the robot. If I go wrong, we debug together.
Before this step
The 4-by-4 grid should already be on the floor from before the lesson. Confirm one corner square is marked Start (a cone, book or card) and a nearby square is marked Target (a star card or another cone). Keep the path short: about 3–5 steps including turns so groups can finish sequences in time. Leave a clear walking lane around the grid. Place one set of instruction sticky notes on each group table: at least 6 forward, 3 turn left and 3 turn right.
Body demo of a quarter-turn (about 1 minute)
Before any writing, stand on one square and show: forward = one step onto the next square; turn left / turn right = stay on this square, pivot a quarter-turn so you face a new side. Have the class stand and copy one left and one right turn on the spot so "quarter-turn" is seen, not only read.
Modelled investigation (short path, about 3 minutes)
Stand on Start, facing along one row. Think aloud through one short path so the class sees the full cycle before they write their own.
- I wonder: Can I reach the target if the class only gives me clear steps?
- I predict: If every step is clear and in the right order, I will land on the target. If one step is missing or in the wrong order, I will go wrong.
- I test (with a planted bug): Use a deliberately incomplete sequence, e.g. two forwards when a turn is needed. Walk it literally and stop on the wrong square or grid edge.
- I observed: "I ended on the wrong square because step 2 said forward when I needed turn right."
- I think: "That missing turn was the bug. Finding and fixing it is called debugging." Insert the turn, re-run, land on the target.
Point out: we changed the algorithm, not the robot. That is debugging.
Group build with cut-off (about 10 minutes)
Give every group the same start, facing and short target so you can compare algorithms. Groups lay instruction sticky notes in order (or write on scrap paper). Circulate and press for precision: one square per forward; quarter-turn on the spot for each turn.
Hard cut-off: after about 8 minutes of building, call time. Sequences must be ready whether or not they feel perfect — debugging is the point.
Every group dry-runs (about 2 minutes, mandatory): before anyone comes to the front, each group finger-walks their sequence on a desk sketch of the grid, or one pupil quietly steps the path once on the floor while the group reads the sticky notes. They may fix one obvious bug at the table. This means every group owns a sequence and has at least tried to debug it, even if only one group runs publicly with you.
Protected public run and debug (about 8–9 minutes — do not skip)
Invite one group to the front. You are the robot. The rest of the class watches and is folded in by questioning: Are they right so far? What do you predict I will do next? Where might the bug be? If the run fails, the class helps name the buggy step, fix it, and you re-run once. Celebrate the fix.
Treat this front-run algorithm and its named bug as the shared class algorithm everyone may claim for the journal later. Tables that already dry-ran their own sequence may still use theirs if they prefer.
Only if time remains after a successful re-run, briefly show a second group's path on a slightly different nearby target — never at the cost of the first debug cycle.
Look-fors
- Groups argue about order, not just the words
- Someone names a bug as a specific step ("step 4 should be turn left")
- Children use the words algorithm, bug and debug without being prompted
- Every group has dry-run before the public run
Safety: calm walking only on the grid; no running; tape edges can trip, so remind the class to step carefully and keep bags clear of the floor space.
Now we will build an algorithm on the board. Three command cards are ready: forward, turn left and turn right.
Call out the order you think will get the robot to the goal. We will drag the steps into place, press run, and watch. If it goes wrong, we debug together.
Move the robot to the goal
Open the algorithm-sequencer interactive on the IWB in explore mode. Tell the class exactly what they will see: a grid, a robot sprite, a goal to reach, and three draggable commands — forward, turn left, turn right. The goal on screen is: reach the target without crossing the pond (or other obstacle shown).
Pupils do not drag on their own devices. They call out; you (or a rotating volunteer) drag the blocks into order and press run. After each run, ask the prompts on screen: Where is the bug? How would you fix it?
Keep at least one run that fails first so debugging stays visible. Celebrate the fix, not a perfect first try.
Link to the floor work: "This is the same thinking we just did with our feet — only now the robot is on the screen."
If the interactive is unavailable, rebuild the same sequence with the physical instruction sticky notes stuck to the board in order and walk it on the floor grid again.
Precise step-by-step instructions existed long before computers. Think of a recipe, packing a school bag, or walking directions from the school gate.
Where else in everyday life do people follow an algorithm? What goes wrong if one step is missing or in the wrong order?
Whole-class science talk, display-only. No writing into the platform. Place this talk before journal writing so everyday examples feed the leave-behind line.
Nature of STEM weave: draw out that algorithms are older than machines. Everyday examples work well: a soda-bread recipe (order of mixing matters), packing a school bag (put the lunchbox in after the books and it gets crushed), bus or walking directions from the school gate to the shop, a set of sports drills in order. People have always needed precise sequences; computers just obey them without common sense, which is why our wording has to be exact.
Prompts to use:
- What is the algorithm in a recipe or in packing a bag?
- What "bug" happens if you bake before you mix, or put the lunchbox in after the books so it gets crushed?
- How is that the same as our robot missing a turn?
Keep this tight (about five minutes). Land on the line you want them to leave with: computers and robots only do exactly what they are told, in order.
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.