An Algorithm Activity for Kids: The Sandwich Test

Your kid writes “put the peanut butter on the bread”. So you pick up the closed jar and set it on top of the sealed bag of bread, and you wait. That is the entire activity, and it only works if you commit to it completely. The comedy is not decoration on this algorithm activity for kids: the comedy is the lesson. A child who is laughing at you balancing a jar on a bread bag has just discovered that their instructions contained an enormous amount of information they never wrote down.

Key Takeaways

• Your child writes numbered instructions for making a sandwich; you follow them exactly and absurdly; they revise until it works.
• It teaches that an algorithm is a sequence of unambiguous steps, and that almost all human instructions depend on hidden assumptions.
• Works from 5 to 12. Under 7, let them be the robot first so the game does not feel like you winning.
• Expect version one to be five lines and fail on line two. Version two is usually three or four times longer.
• You must refuse to follow any instruction involving a sharp knife, heat or eating. The joke stops where safety starts, and saying so out loud is part of it.

What You’ll Need

Item	How much	Where to get it	If you don’t have it
Sliced bread, in its bag	1 loaf	Kitchen	Crackers or tortillas; the bag or wrapper matters
A spread in a closed jar	1 jar	Kitchen	Jam, cream cheese, butter, hummus or mashed avocado
Butter knife or plastic knife	1	Drawer	Spoon. Do not use a sharp knife for this activity
Plate	2	Cupboard	One for the wreck, one for the real sandwich
Paper and pencil	3 sheets	Anywhere	The instructions must be written, not spoken
Damp cloth	1	Sink	You will need it

Allergens: peanut butter contains nuts. Cream cheese and butter contain milk. Bread contains wheat and often milk or egg. Check before you start and substitute freely; jam and mashed avocado avoid all four.

Time: writing 10 min, first run 10 min, revisions 20 min, cleanup 5 min Cost: one sandwich’s worth of ingredients Mess level: medium, and the mess is the point

Do the Experiment: An Algorithm Activity for Kids

Step 1 – Set everything out, closed and sealed

Bread in its sealed bag, jar with the lid on, knife, two plates. Nothing opened, nothing prepared. Then announce the rules: they write the instructions, you are a robot, and the robot does exactly what is written and nothing else.

Step 2 – Have them write numbered instructions

Writing matters. Spoken instructions get patched mid-sentence, and the whole point is that the instruction set is fixed before it runs. Do not help, do not hint, and do not comment on how short it is. Five to eight lines is typical and correct for a first attempt.

Step 3 – Run the program with total commitment

Read line one aloud, then do it with maximum literalness. “Get the bread” means pick up the whole loaf, bag included. “Put the peanut butter on the bread” means balance the closed jar on the bag. “Spread it” means move the knife through the air, because nothing has told you to make contact with anything. Do not break character, do not explain, do not smirk your way out of it. The urge to help is strong; resist it for three solid minutes.

Step 4 – Stop at the first impossible instruction and say why

When you reach something you cannot perform, stop and say precisely what is missing: “I do not know what ‘open it’ means. Open what? Open how?” Then hand the paper back. Specific is the operative word; “that’s wrong” teaches nothing.

Step 5 – Rewrite, run again, count the lines

Version two will be much longer. Run it the same way, with the same literalness. It will usually fail again, in a smaller way, and that second failure is more valuable than the first because it is a near miss. Count the lines in each version and write the numbers down.

Step 6 – Swap roles, and mean it

Now your child is the robot and you write the instructions, deliberately ambiguous. “Put some bread on the plate.” “Use the right amount.” This step is not optional. It stops the activity being an adult scoring points, and it is also where they discover how hard writing good instructions is from the other side.

Step 7 – Introduce repeat and if, then rewrite once more

Show them two tools. A repeat: “repeat until the whole slice is covered.” A condition: “if the bread is still in the bag, take one slice out.” Rewrite version three using both. It will be shorter than version two and still work, which is the first time they feel why programmers care about loops.

Step 8 – Make the real sandwich and eat it

Run the final version on a clean plate with clean hands, then eat it. Ending with a working sandwich matters more than you would think, because the activity is otherwise a half-hour of being wrong.

What you should see: Version one fails within the first three instructions, nearly always on the bag or the lid. Expect five to eight lines in version one and fifteen to twenty-five in version two, which is a measurement worth writing down because the jump is the result. Laughter peaks at the jar-on-the-bag moment and again when you move the knife through empty air. With a five- or six-year-old, watch for the laughter turning into frustration at about the third failure; that is the signal to swap roles rather than push on.

What’s Actually Going On

An algorithm is a finite sequence of unambiguous steps that produces a result. Every word in that definition does work. Finite: it has to stop. Unambiguous: each step has exactly one meaning. Sequence: the order matters. “Make a sandwich” satisfies none of them, which is why it is an instruction for a person and not an algorithm.

The reason human instructions are so short is that they rely on enormous shared context. When you tell an adult to make a sandwich, you are relying on a lifetime of knowledge about bags, lids, spreading, hygiene, how much is too much, what to do if the bread is frozen. None of that is in the sentence. The literal robot removes the shared context, and what is left is the actual information content of the instruction, which turns out to be startlingly little. That gap between what you said and what you meant is where software bugs come from, essentially all of them.

The three structures you introduced in step 7 are not a simplification for children. Sequence, selection and iteration are the complete set of control structures needed to express any computation. Doing one thing after another, choosing between options, and repeating until a condition is met. Everything else in programming is convenience built on those three. A child who has written a sandwich procedure using a repeat and an if has written a program, in the only sense that matters.

There is one more concept hiding here, and it is the most useful one for a child’s self-image. The first version failing is not a mistake, it is a bug, and finding and fixing bugs is the normal state of the work rather than evidence of incompetence. Professional programmers spend more time debugging than writing. Telling a child that explicitly, at the moment their instructions fail, is probably the single most valuable sentence in this activity.

Finally, an honest update, because the world changed. If you type “make me a sandwich” into a modern AI assistant controlling a robot, it will not get stuck on the bag: it will infer the missing steps from a model of how sandwiches work. So does that make precision obsolete? No, and the reason is worth telling a teenager. The system now guesses your intent, which means it guesses wrong in ways you cannot see, and it will not stop to ask. The skill has moved from specifying every step to specifying the goal and the constraints precisely enough that a confident guesser cannot misread you. Jeannette Wing’s framing of computational thinking, written in 2006, holds up better than most things from that era because it was never about syntax: it was about formulating problems so that a machine can act on them.

How to Explain It to Your Kid

Ages 5–8: you be the robot first

Reverse the order. Let them be the robot and you give the instructions, badly, and let them laugh at your bad instructions while they do the ridiculous things. Then offer them a turn as the instruction writer. At this age the sentence that lands is: “The robot doesn’t know anything you didn’t tell it.” Keep the written list to five or six lines and accept drawings instead of words if writing is slow.

Ages 9–12: count the lines and name the bug

Make the line counts explicit: version one, eight lines; version two, twenty-two. Then ask them which single line in version one was doing the most hidden work. It is nearly always the spreading one. Introduce the word bug and use it neutrally. Then do the loop and the if, and get them to notice that version three is shorter than version two without being worse, which is a real engineering insight.

Ages 13+: specify it for a machine that guesses

Do the basic version quickly, then set the harder task: write a specification for a sandwich good enough that an assistant which fills in gaps on its own cannot produce something you would reject. They will need to state constraints rather than steps: no nuts, this much spread, this bread, cut this way, nothing touching the counter. Then ask the uncomfortable question: how would you know if it had quietly substituted something? Verification, not instruction, is where the interesting work now is.

The question to ask: “Write me instructions for tying a shoelace, for someone who has never seen a shoe. How many lines do you think it needs? Now count how many you actually wrote.”

Why Teaching This Early Pays Off

Precision in instructions is the skill underneath programming, and it is also the skill underneath writing a recipe, giving directions, filling in a form and explaining anything to anyone. A child who has watched their own instructions fail understands, physically, that clarity is not a style preference.

The specific payoff is a reframing of error. Most children experience being wrong as a verdict. In programming, being wrong is the first draft, and the loop of run, fail, inspect, fix is the whole job. Seeing that modelled with a sandwich, where the failure is funny and the fix is obvious, is a cheap way to build a tolerance for iteration. CS Unplugged’s Kidbots unit, used in classrooms for years, is built on exactly this mechanic of a human following instructions literally, which is good evidence it survives a room full of children.

Keep the claim modest. One sandwich does not teach anyone to code, and the research is clear that unguided activity underperforms: Kirschner, Sweller and Clark’s argument against minimal guidance applies directly, because a child left to wonder why their instructions failed learns much less than a child told, immediately and specifically, which word was ambiguous. Your job is not to be a funny robot. It is to be a funny robot who then names the problem out loud.

Before You Start: What Parents Should Know

Best age	5 to 12, with the role order reversed for under-7s. The upper end is about attention rather than difficulty; a teenager needs the specification version in the Ages 13+ section to stay interested.
Supervision	Constant, because you are in it. You are the robot, the referee and the person who decides when an instruction is unsafe to follow.
Real hazards	Knives. Use a butter knife or plastic knife only, and never follow an instruction literally if it involves a sharp knife, a hob, an oven or putting something in a mouth. Say this rule out loud at the start, so the child knows the robot has limits. Peanut butter is a common allergen; check for allergies before choosing the spread.
Setup	A wipeable table with everything in reach. The robot cannot fetch things that were not mentioned, so put everything out before you start.
Frustration point	The second or third failure, especially for under-7s. The laugh turns thin and then sour. Swap roles the moment that happens; it rescues the activity every time.
Don’t	Don’t help. Don’t soften a literal interpretation because you can see what they meant. And do not skip the final working sandwich, because ending on failure sours the whole thing.

When It Doesn’t Work

• The child gets upset rather than amused. You pushed one failure too far, or they are at the younger end. Swap roles so they are the robot, and let them be absurd at your expense. Then return to writing.
• They keep patching the instructions out loud. Hold the paper up and say the robot can only read. If it is not written down it does not exist. This single rule is what makes the activity work.
• Version two works first time. Excellent, and unusual. Raise the difficulty: the robot now also does not know what “spread” means, or you add a frozen loaf, or you swap to a jar with a safety seal under the lid.
• The instructions are too long to be fun. Introduce the repeat earlier than step 7. “Repeat until covered” replaces fifteen lines of spreading and the relief is immediate.
• You cannot keep a straight face and it collapses into silliness. That is fine as long as you still stop and name what was missing. The naming is the teaching; the silliness is just the delivery.

Take It Further

Write a specification instead of a procedure. Have them describe the finished sandwich precisely, with no steps at all: what is on it, how much, how it is cut, what must not touch it. Then you make something that technically satisfies every line and is still wrong. This is the gap between a specification and an intention, and it is what software requirements documents are actually about.

Do it with a route instead of a sandwich. Have them write instructions to get from the front door to their bedroom, and follow them literally, walking into walls where the instructions permit it. Add a repeat (“repeat until you reach the stairs”) and a condition (“if the door is closed, open it”). Lego robots and turtle graphics both work the same way, and this is a free version.

What to Watch For Over the Next 3 Months

• Week 4: They correct an ambiguous instruction from somebody else, usually in a game or a recipe, and sound slightly smug about it.
• Month 2: The word “bug” appears about something that is not a computer, used correctly: a plan that failed for a findable reason.
• Month 3: The question worth encouraging is about something they tried to get a device or an app to do and it misunderstood. That conversation is the one with the most road ahead of it.

Frequently Asked Questions

Why does the adult have to be so literal? It feels mean.

Because literalness is the entire mechanism. If you quietly fill in what they meant, nothing is revealed and the activity becomes making a sandwich. The way to keep it from feeling mean is the role swap: let them be the robot for your bad instructions too, and announce in advance that this is a game you will both lose.

What age is this for?

Five to twelve. Under seven, let them be the robot first. Over twelve, it needs the harder version, where they write a specification tight enough that a system which guesses the missing parts cannot produce something they would reject.

Isn’t this pointless now that AI can work out what you meant?

No, but the lesson shifts. A system that infers missing steps also infers them wrongly sometimes, silently and confidently. The skill becomes stating goals and constraints precisely, and then checking the result, rather than listing every step. That is a harder skill and a more valuable one.

How long should the instructions end up being?

Version one is usually five to eight lines. Version two is typically fifteen to twenty-five. Version three, once a repeat and a condition are allowed, usually comes back down to ten or twelve while still working. Writing those three numbers down is the cleanest piece of data in the activity.

---

About the author

Ricky Flores is the founder of HiWave Makers and an electrical engineer with 15+ years of experience building consumer technology at Apple, Samsung, and Texas Instruments. He writes about how kids learn to build, think, and create in a tech-saturated world. Read more at hiwavemakers.com.

---

Sources

1. CS Unplugged, University of Canterbury. “Kidbots” (giving precise instructions to a human robot). https://www.csunplugged.org/en/topics/kidbots/
2. Wing, J. M. (2006). “Computational thinking.” Communications of the ACM, 49(3), 33–35. https://doi.org/10.1145/1118178.1118215
3. Kirschner, P. A., Sweller, J., & Clark, R. E. (2006). “Why Minimal Guidance During Instruction Does Not Work.” Educational Psychologist, 41(2), 75–86. https://doi.org/10.1207/s15326985ep4102_1
4. Chi, M. T. H., & Wylie, R. (2014). “The ICAP Framework: Linking Cognitive Engagement to Active Learning Outcomes.” Educational Psychologist, 49(4), 219–243. https://doi.org/10.1080/00461520.2014.965823
5. Alfieri, L., Brooks, P. J., Aldrich, N. J., & Tenenbaum, H. R. (2011). “Does discovery-based instruction enhance learning?” Journal of Educational Psychology, 103(1), 1–18. https://doi.org/10.1037/a0021017
6. National Research Council. (2012). A Framework for K-12 Science Education. National Academies Press. https://doi.org/10.17226/13165

Related reading: coding without a computer, computational thinking versus coding, and teaching logic with truth tables.