---
title: "Computing for Young Minds"
author: "Michael Gannotti"
lang: en-US
date: "6 October 2026"
---
{width=100%}
\newpage
# Computing for Young Minds {.unnumbered}
Michael Gannotti
*A homeschool guide to computing for ages 11–14: plans, Python, the web, how computers work, safety and AI. Book 2 of the SMF WisdomForge Computing series.* Illustrated edition, 6 October 2026. Notes run in one series at the back; the superscript numbers link to them. The images are original still lifes, with no people and no brands.
# Contents {.unnumbered}
- Welcome
- How to Use This Book This Week
- If You Only Remember Five Things
- The Computing Hour
- Chapter 1 — What Computing Looks Like at 11–14: Plans, Algorithms, and Thinking It Through
- Chapter 2 — From Blocks to Text: First Programs in Python
- Chapter 3 — Debugging as a Discipline: Errors, Tests, and the Debug Log
- Chapter 4 — Functions, Lists, and Data: Bigger Programs and Spreadsheets That Answer Questions
- Chapter 5 — Building for the Web: HTML, CSS, and a First Taste of JavaScript
- Chapter 6 — How Computers and Networks Really Work — and Hardware You Can Program If You Like
- Chapter 7 — Safe, Smart, and Kind Online: Passwords, Scams, Social Media, and Your Footprint
- Chapter 8 — AI Up Close: Training Data, Bias, Prediction, and Whose Work It Is
- Chapter 9 — Records, Portfolio, and Transcript
- Chapter 10 — Resources
- A Note on Sources
- Notes
\newpage
# Welcome
You don't need to be a programmer to teach an 11- to 14-year-old real computing.
You do need to ask "What do you predict will happen?" before anyone presses run, and to leave the program in your student's hands when it breaks.
That is what this book is for.
## The book in one minute
Here is a picture. It is an illustration, not a real family.
Nora is twelve. She has built dozens of Scratch games: a maze, a quiz, a cat that dodges falling pizza. Today she opens a Python editor for the first time and types three lines. The third one is supposed to greet the player by name. She presses run.
Red text fills the bottom of the screen.
Her mother is sitting beside her. She can see the problem, more or less. She doesn't reach for the keyboard. "What does it say?"
Nora reads it aloud, a little offended. "Something was never closed. Line 3."
"So where's line 3?"
Nora finds it. She counts the brackets with her finger: one open, none closed. She adds the missing one and runs it again. The greeting appears. She grins, then frowns. "It could have just said that."
"It did," says her mother. "It said line 3."
That is the book in one minute. The computer did exactly what it was told. The error message was information, not judgment. The parent asked a question instead of fixing it. And the program that works now is Nora's, because Nora fixed it.
## Who this book is for
This book has two readers.
The first is you: the parent, grandparent, or co-teacher at the table. You may never have written a line of code. That's fine. Each chapter teaches you the idea first, in plain words, so you can hear where your student's thinking goes off track and ask one good question.
The second is your student. At 11 to 14, young people can hold a plan in their heads, write it down, test it, and argue with you about it. They want more say in their own work, and they're ready for it. Every chapter has a section written to them directly, as "you," longer and more grown-up than the student pages in a book for younger children.
## What your student will learn
Over a year, your student will plan and write real programs in Python, a language you type rather than snap together, readable enough for beginners and used by professionals. They'll learn to find and fix their own bugs calmly. They'll build a small website. They'll find out how computers and networks actually move information around. They'll learn how to stay safe and kind online, how AI tools work, and whose work it is when one of them helps.
The pace is about two or three Computing Hours a week. Each Hour is forty to sixty minutes long, and about half of the book's activities need no screen at all: paper, index cards, a deck of cards, masking tape on the floor.
## The line the whole book runs on
**Predict before you run; debug before you rewrite; explain it before you call it yours.**
*Predict before you run* means writing down what you think a program will do before you start it, so there's something to check against.
*Debug before you rewrite* means that when something breaks, you find the one wrong thing and fix it, instead of deleting everything and starting over.
*Explain it before you call it yours* means that your work is what you planned, wrote, tested, and can explain, and that you say plainly what help you used.
Hold those three habits, and the rest of this manual is practice.
## You are not alone
About 3.4 percent of school-age children were homeschooled in 2022–23, by the federal count.^[1](#note-1)^ Many of those families have taught computing for years with very little help, piecing together a website here and a free course there. This book is the help: one clear way to run a week, and a menu of activities you can choose from.
## What this book will not do
It won't hand you a 180-day stack of worksheets. You'll get a weekly shape and a menu of named activities, and you choose.
It won't sell you a curriculum, a gadget, or a subscription. The home Python editor this book recommends is free and needs no account.
It won't promise a test score. It won't tell you that coding makes young people better at everything, either. Coding teaches coding. Other good things may come along, and that's a welcome possibility, not a promise.
It won't give anyone under 13 an account or a chatbot. At 11 and 12, you create and hold every login, and any AI tool runs on your account with you at the keyboard. At 13 and 14, your student can use some tools under their terms, with you nearby.
It won't title your student's year with a book name or hand out a certificate. If you keep records, use a plain title a stranger can read, such as **Computer Science**.
It isn't a reprint of any earlier computing book. It was written fresh for this age.
## Where this book sits
*Computing for Young Minds* is the second title in the SMF WisdomForge Computing series. *Computing for Little Thinkers* (ages 5–10) comes before it, and *Computing for Emerging Adults* (15–18) comes after. *Computing Refresh for Adults* is for grown-ups who want their own turn.
Little Thinkers is not required. A student who never used it starts at Chapter 1 and is fine. A student who did will recognize the shape of the week and the habit of predicting first, and will find almost everything else new.
## How the book is built
The front matter gives you a plan for this week, five things to remember, and **The Computing Hour**: the five-step session shape, Family safety basics, a short note on screen time, and the one box about AI. Each is said carefully, once, and the chapters point back to it.
Eight teaching chapters follow. They cover plans and algorithms; first programs in Python; debugging; functions, lists, and data; building for the web; how computers and networks work; staying safe online; and how AI works. Then come two chapters for you: records and a portfolio, and resources.
Every teaching chapter uses the same eight headings, a talk box with an exact opening question, and named activities for inside the home and outside it. Each chapter gives moves for two bands, **11–12** and **13–14**. Place your student by skill, not birthday.
## Where to begin
This week, you can learn one question, "What do you predict will happen?", and practice waiting after you ask it.
Your student can write instructions for something ordinary, like making a sandwich, and watch you follow them exactly as written. The results are usually funny, and very instructive.
You don't need to know Python yet. You need a kitchen table, a notebook, and a question you're willing to wait for.
Bring a pencil. The computer can wait five minutes.
— Michael Gannotti
\newpage
# How to Use This Book This Week
You can start this week. You don't need to read the whole book first, buy anything, or know any Python. Here is a plan for your first week, and then a short tour of how the rest of the book works.
## This week
**Monday (you, about 40 minutes).** Read **The Computing Hour**, the session shape every chapter uses. Then read the first two sections of Chapter 1, "Why this matters" and "For the parent: understand it yourself." That's all the preparation you need.
**First Computing Hour.** Unplug and Plan with PLAN-01 The Literal Sandwich Spec: your student writes instructions for making a sandwich, and you follow them exactly as written, like a very literal computer. Then Predict with PY-02 Predict the Print: a four-line program on paper, a written guess, and a check. No screen is needed today. Start the Debug Log with the sandwich bugs. The Debug Log is a dated notebook (paper or a plain file) that holds predictions, bugs, clues, and fixes. Photograph the marked-up spec. Close with the exit lines: "I predicted… It did… Next I'd change…" and "Help I used: …" (today: none).
**Second Computing Hour.** Play ALG-01 Guess My Number, where your student finds your secret number by halving the range each time. Then install Thonny together (PY-01 Hello, Editor). Thonny is a free Python editor for beginners. It comes with Python built in, needs no account, and works offline once it's installed.^[2](#note-2)^ Your student types a first program, runs it, and saves it as `2026-10-12-hello.py` in two places: the family drive (or a USB stick) and one backup.
**Optional, this week or next.** Write SAFE-08 Family Device Agreement together: where devices live, who holds the passwords, and what to do if something online feels wrong. It belongs to Chapter 7, but many families like to set the rules before the computer comes out. If a phone is arriving soon, do it now.
**Other days.** Ten minutes is plenty: a Paper Parsons (PLAN-07, cut-up lines of a program to put in order) or a short typing warm-up.
## What to save from week one
- the marked-up sandwich spec (a photo is fine);
- `2026-10-12-hello.py`, saved in two places;
- one dated page of the Debug Log;
- the family agreement, if you wrote it.
That is the beginning of a portfolio. Chapter 9 shows you how to keep it.
## How each chapter is built
Every teaching chapter uses the same eight headings, in the same order:
1. **Why this matters**: the idea in a page.
2. **For the parent: understand it yourself**: what you need to know to hear a wrong turn.
3. **How to teach it this week**: the first activities, and the chapter's **talk box**, which gives an exact opening question, follow-ups, and how to wait.
4. **Practice that actually builds learning**: more activities, each with a bank code.
5. **For the student**: written to your student directly.
6. **If it isn't clicking**: what to try when it's not working.
7. **Tools, including AI**: what to use, and what not to, at each age.
8. **What "done enough" looks like**: how to know it's time to move on.
Activities are marked **In-home** or **Out-of-home**, and each lists time, materials, safety and privacy, the fun, the skill, and the crumb (what to save). Moves for the two bands are marked **11–12** and **13–14**. "Ready 12" marks a 13–14 move that some 12-year-olds can take. Place by skill, not birthday.
## What order to go in
Do Chapters 1–3 in order: plans and algorithms, then first Python, then debugging. After that, Chapters 4–8 can go in any order that suits your family. If a phone or a first account is arriving, move Chapter 7 earlier. Chapters 9 and 10 are for you; dip into them whenever you need them.
## The bank
The book holds 100 named activities, each with a code such as PLAN-01 or PY-04. Forty-nine of them need no screen at all. You won't do them all, and you shouldn't try. Pick what fits the week and skip the rest without guilt.
## A year in outline (optional)
| Weeks | Focus | A project to finish |
|---|---|---|
| 1–4 | Chapter 1, plans and algorithms (agreement in week 1) | A flowchart and pseudocode for a family routine |
| 5–10 | Chapter 2, Python basics | A guess-the-number game |
| 11–14 | Chapter 3, debugging | A planted-bug swap |
| 15–20 | Chapter 4, functions, lists, and data | A quiz program; a small data investigation |
| 21–25 | Chapter 5, the web | A three-page site and a demo day |
| 26–30 | Chapter 6, computers and networks | A pixel picture; a secret-code challenge |
| 31–33 | Chapter 7, safety (going deeper) | A settings tour |
| 34–36 | Chapter 8, AI | A next-word guesser; a Whose Work audit |
A Cold Trace (AS-01) once a month and a demo day once a semester run all year. Treat this as a picture of one year, not a schedule to keep.
## Siblings and co-ops
Siblings can work as a pair: one types (the driver), one reads and checks (the navigator), and they switch every ten minutes. Two computers side by side, with lots of talk, works just as well. In one study of students entering sixth grade, pairs and students on their own computers learned about the same, and the solo students finished a little faster.^[3](#note-3)^ Pairing is a good way to work together, not a promise of better scores.
A younger sibling, say nine, can join the unplugged cards and play the literal computer. For their own Hour, *Computing for Little Thinkers* fits. A co-op can hold one demo day a semester.
## Special situations
**A student far ahead of you.** Your job doesn't change: ask for the prediction, be the first user, and ask for the explanation. Let your student teach it back to you.
**A student new to all of this at 13.** Start at Chapter 1. The 13–14 moves go quickly, and the Scratch side-by-side work is optional.
**No computer at home.** Use the 49 unplugged activities, plus Computing Hours at the public library (OUT-02).
**Learning differences.** Use shorter screen blocks, larger fonts, code read aloud, and cut-up programs to put in order instead of a blank file. The Hour's five steps stay the same.
**A student who has already used chatbots at 11.** No shame and no scolding. Move to parent-operated use, and talk through the terms and why they exist.
## A week with no screens
Sick laptop, travel, or a week at grandma's: run the Hour on paper. Trace a program by hand, sort cards, play Guess My Number in the car. Paper weeks are real computing weeks.
## When life happens
You will miss days. Pick up where you left off. Two short Hours in a busy week still count. The habits matter more than the calendar.
\newpage
# If You Only Remember Five Things
Some weeks you won't open the book at all. On those weeks, these five are enough.
## 1. Predict before you run.
Before anything runs, your student writes one line: *I predict it will…* A prediction turns a program into an experiment. When the guess is wrong, you've learned exactly where your student's picture of the code differs from the computer's, and that's the most useful thing that can happen in an Hour. No run without a prediction line.
## 2. Debug before you rewrite — read the error, change one thing, log it.
When the program surprises you, nobody deletes anything. First write what you expected and what actually happened. Then read the error message, which usually names a line. Change one thing, run it again, and write one line in the Debug Log: the bug, the clue, the fix. "I'll just start over" becomes "Save this as a new version, then tell me the one thing that's wrong."
## 3. Explain it before you call it yours. "Help I used:" every time, even "none."
Your student's work is what they planned, wrote, tested, and can explain. If they can't explain a line, it isn't theirs yet. Every Computing Hour ends the same way:
"I predicted… It did… Next I'd change…"
"Help I used: …"
A tutorial, a sibling, you, an AI tool: all of it counts, and none of it is shameful. Anything a tool generated is made by a tool, not your student's own work.
## 4. Paper first, then screen; save in two places; screens out of the bedroom.
Every Hour starts with the screen dark and a plan on paper. About half of this book's activities never need a screen at all. When there is a file, it lives in two places: the family drive (or a USB stick) and one backup, with a date-first name a stranger could read. The computer lives in a shared room, and phones and laptops sleep outside bedrooms.
## 5. You hold the passwords at 11–12 and share them at 13–14; AI is parent-operated under 13 and supervised after.
At 11 and 12, you create and hold every login, and any AI tool runs on your account with you at the keyboard. At 13, many services let a young person sign up. A big reason is a federal privacy law that requires a parent's consent only for children under 13.^[4](#note-4)^ Thirteen is a rule for companies, not a readiness test. At 13 and 14, your student may hold passwords for tools the family has approved, with two-step login turned on and a copy kept by you, and may use AI tools whose terms allow their age, with you nearby. Check the current terms before you start. The details live in **The Computing Hour**, under Family safety basics and the AI box.
---
If you remember only one sentence, make it this one:
**Predict before you run; debug before you rewrite; explain it before you call it yours.**
\newpage
# The Computing Hour
{width=100%}
Forty to sixty minutes. Five steps. Paper first, screen second, and a clear stop.
"Hour" is the family word. At 11–12 a session runs about 40–50 minutes, roughly 20–30 of them on a screen. At 13–14 it runs about 50–60, and a project day can stretch to about 75 with a movement break. Later chapters say "run the Computing Hour" and point back here, so you learn it once.
Every Hour runs on one line:
**Predict before you run; debug before you rewrite; explain it before you call it yours.**
## Parent warm-up (about three minutes)
Read today's talk-box opening aloud once. Run the day's program yourself, on your own copy, so nothing surprises you except the interesting things. Check where today's file will be saved. Put your own phone face down.
## The five steps
| Step | 11–12 | 13–14 | What happens |
|---|---|---|---|
| 1. **Unplug and Plan** | 5–10 min | 5–10 min | Paper first: pseudocode, a flowchart, a test table, or one unplugged card. |
| 2. **Predict** | 2–5 min | 2–5 min | A written prediction line in the Debug Log before anything runs. |
| 3. **Build and Test** | 15–25 min | 20–35 min | Small steps, run often, test against the plan. |
| 4. **Debug and Log** | 5–10 min | 5–15 min | Expected/Actual, read the error, one change at a time, one Debug Log line. |
| 5. **Save and Explain** | 3–5 min | 3–5 min | Save a new version in two places. Explain it, and say what helped. |
### 1. Unplug and Plan
The screen stays dark. Your student puts a plan on paper: a few lines of pseudocode (a plan for a program written in plain words), a flowchart, or a test table that lists inputs and the outputs they expect. Some days the whole step is one unplugged card from the chapter. Ask the talk-box opening here. A plan doesn't need to be right. It needs to exist, so there is something to test against.
### 2. Predict
Before anything runs, your student writes one line in the **Debug Log**, a dated notebook (paper or a plain file) that holds predictions, bugs, clues, and fixes. No run without a prediction line. The model for this step is PY-02 Predict the Print: a short program on paper, a written guess, then the run.
```python
score = 3
score = score + 2
print("Score:", score)
print(score * 2)
```
This prints `Score: 5` on one line and `10` on the next. A student who predicted `Score: 3` has just met the most useful idea in Chapter 2: a variable is a labeled box whose contents can change, and line 2 changed it. A wrong prediction is not a failure; it is a window into your student's thinking.
### 3. Build and Test
Your student types, runs, and tests in small steps, running after every few lines and testing against the plan. Most weeks follow the same arc: use a working program, change one part, then make something new.
Your hands stay off the keyboard. Your job is **first user**: when the program is ready, you try it the way a stranger would and report what happened, without fixing anything.
### 4. Debug and Log
A bug is a mistake in the instructions; debugging is finding and fixing it. When the program surprises them, your student writes an Expected/Actual line before touching the code (BUG-01): what I expected, what actually happened. Then they read the error message, if there is one, and change one thing at a time, running after each change. One short line goes in the Debug Log (BUG-08): the bug, the clue, the fix.
A Debug Log entry is evidence of good work, not a confession. Chapter 3 is all about debugging.
### 5. Save and Explain
Save a new version with a name a stranger could read, date first, such as `2026-10-12-guess-game-v2.py`, in two places. Screens off. Then your student says (at 11–12) or writes (at 13–14) the exit lines:
"I predicted… It did… Next I'd change…"
"Help I used: …"
The second line is said every time, even when the answer is "none." A tutorial, a sibling, the documentation, you, an AI tool: all of it counts, and none of it is shameful. Said every Hour, honesty becomes ordinary.
## Who runs it
**11–12.** You run Unplug and Plan for the first month: you bring the plan or the card and ask the opening. Your student runs Predict through Save and Explain from week one. By midyear your student writes the plan, and you check it.
**13–14.** Your student is the session lead. They write the plan, run the clock, keep the Debug Log, and call the save. You are the first user, the question-asker, and the keeper of the safety rules. Once a week, take five minutes to read the Debug Log together.
Place by skill, not birthday. A 14-year-old who is new to all of this may want a month with you running the plan. In the chapters, "ready 12" marks a 13–14 move some 12-year-olds can take.
## The rescue order
When your student is stuck, use the same order every time: **ask → wait → hint → short demo on your own copy → hand it back.**
Ask a real question. Wait. Offer a hint that points without solving: "Look at line 4." If a demo is truly needed, show it on your own paper or file, then close it and hand the turn back. Your hands stay off your student's keyboard. A program they fixed is theirs.
## The talk-box shape
Every teaching chapter has a talk box. The shape never changes.
**The opening question** is real. It asks about your student's own plan, prediction, evidence, or judgment, and it has no answer to recite. Each chapter gives its exact opening.
**Three to five follow-ups**, drawn from these:
- prediction: "What will it do?"
- evidence: "What did you see that makes you say that?"
- location: "Which line is the last one that did what you expected?"
- change: "What's the one thing you'd change?"
- revision: "You can change your prediction. Run it again."
**How to wait.** After you ask, count to five in your head. The habit comes from classroom studies of "wait time," used here as a pause, not a stopwatch.^[5](#note-5)^ When the question is about code on the screen, let them read as long as they need. Look at the code, not at your student.
**What a stuck silence usually means.** The question was vague. There was no wait. Your student fears being judged, which runs strong at this age, so keep every comment about the code. They're waiting for you to fix it, because you have before. There was no prediction to compare. Or the screen is louder than the question; lower the lid for a moment.
**One "don't say / say instead" line in every chapter.** For example: don't say "That's wrong"; say "Show me the line where it stops doing what you expected."
## The try-it shapes
Every named try-it gives you six things: **time**, **materials**, **safety and privacy**, **the fun**, **the skill**, and **the crumb** (what to save). Each heading carries a bank code, such as *In-home — PLAN-01 The Literal Sandwich Spec* or *Out-of-home — OUT-02 Library Computer Hour*. Each teaching chapter has at least one of each.
OUT-02 is worth knowing now. A whole Computing Hour can run on a public library computer, with you beside your student, the file saved to your own USB stick, and both of you logged out before you leave. A home with no computer can do about half of this book's activities on paper and the rest at the library.
## When the Hour goes wrong
| If the Hour looks like… | Try this |
|---|---|
| The computer won't start, or the internet is down | Thonny, the book's home Python editor, runs offline. If the machine itself won't start, make it a paper day: trace the program by hand. |
| An error nobody understands | Expected/Actual first. Read the error's last line aloud, then find the line number. Log it. Tomorrow is allowed. |
| "I'm deleting it and starting over" | "Save this as a new version first. Then tell me the one thing that's wrong." |
| Racing ahead and skipping Predict | No run without a written prediction line. Hands on the table until it's there. |
| Tears, or a slammed laptop | Stand up, get water, come back in five minutes. Stop while it's still fixable. |
| A sibling interrupts or takes over | Driver and navigator, swapping every ten minutes, or an unplugged card for the sibling. |
| You're itching to type | Hands in your lap. Point with words: "Look near line 6." Demo on your own copy if you must. |
## Family safety basics
These are ordinary and non-negotiable. Chapters point back here; Chapter 7 teaches them in depth.
- **You hold the keys.** At 11–12 you create and hold every login, and your student never signs up for anything alone. At 13–14 your student may hold passwords for tools the family has approved. You keep a sealed copy or a family password-manager entry, and two-step login (a password plus a second thing, such as a code) is turned on.
- **The 13 shift.** A federal law called COPPA requires sites and apps that collect personal information from children under 13 to get a parent's consent first, and photos, videos, and voice recordings count as personal information.^[4](#note-4)^ That protection ends at 13, a big reason so many services set 13 as their minimum age. Thirteen is a rule for companies, not a readiness test. Your family's rules sit on top.
- **Shared room, phone-free bedrooms.** The computer lives in a shared space. Phones and laptops stay out of bedrooms overnight, and screens go off an hour before bed.
- **Stop, Save, Tell.** If something online is scary, mean, or threatening: stop replying, save it instead of deleting it, and tell a parent. Nobody is in trouble for telling.
- **First names only.** No school, town, or face in anything shared beyond the family. Screenshots are cropped to the work.
- **Two places.** Every file lives in two places: the family drive (or a USB stick) and one backup. Not a shared bot computer, and not a chatbot.
- **Updates on, unknown downloads off.** At 11–12 you approve every new app. Publishing anything online is optional, and it's your call.
- **Old hardware.** Adults open old machines, unplugged. Nobody opens batteries, power supplies, or old tube screens.
## A note on screen time
The American Academy of Pediatrics replaced its older media guidance in 2026. Its policy statement puts the weight on content and on what screens push out: sleep, meals, movement, and homework. It suggests phone-free meals, bedrooms, the hour before bed, and homework; parent-set controls for privacy, downloads, content, purchases, and time; and a family-tailored range of roughly one to two hours or more a day of entertainment media for school-age children and teens, with school media counted separately.^[6](#note-6)^
The World Health Organization asks families to limit recreational screen time and to keep children and teens moving at least an hour a day. It gives no number for screens.^[7](#note-7)^ On sleep, the CDC points to the sleep-medicine recommendations: 9 to 12 hours in every 24 for children 6 to 12, and 8 to 10 hours for teens 13 to 18.^[8](#note-8)^ A late-night bug goes in the Debug Log and waits for morning.
These are guidelines for families, not a stopwatch rule, and they change as the research does. The Computing Hour is purposeful school media. About half its work is unplugged, and it ends with screens off.
## The AI box
**What AI is here for.** AI can explain, suggest, and check, sometimes well and sometimes confidently wrong. Your student does the planning, predicting, writing, testing, and debugging. Anything an AI produces is made by a tool, never your student's own work. Chapter 8 explains how it works.
**Ages 11–12: parent-operated.** Most consumer AI services set 13 as their minimum age, and at least one major one sets 18.^[9](#note-9),[10](#note-10)^ So at 11–12, AI runs on your account, on your device, with you at the keyboard or reading every exchange. Your student can dictate a question, read the answer beside you, and check it against a source. No student accounts on chatbots, AI tutors, or coding assistants, even inside a course that offers one. CodeAI (formerly Code.org), for example, labels its AI Tutor for students 13 and up, so in this book it stays off at 11–12.^[11](#note-11),[12](#note-12)^
**Ages 13–14: supervised, under the terms, with you.** Use only a service whose terms allow your student's age, and a teen or linked account where the service offers one. Sit nearby with the screen visible. Turn off training on your student's conversations, and turn off memory, where you can. Leave image generation off unless a lesson needs it. No companion, "friend," or role-play apps. Teen settings help; they are not a substitute for you in the room. Check the current terms before you start.
**You may, within the rule for your student's age:**
- have it explain an idea or an error message *after* your student has written Expected/Actual and a guess;
- ask for practice problems or a hint ladder, held back until your student has tried;
- at 13–14, get a code suggestion, then have your student explain every line before deciding whether to use any of it, with a "Help I used" line;
- check a claim it made against a real source.
**Please keep these off the table:**
- having it write your student's program, page, or project;
- using it during the AI-free checks: Cold Trace, Debug on the Spot, and Build From a Blank;
- filing generated code, pages, pictures, or text as your student's work, or as a portfolio piece;
- pasting private messages, photos, names, or your address into a chatbot;
- uploading photos of your children or family to any AI tool;
- companion, "friend," or role-play apps;
- an AI "detector" to judge your student's work, because "explain it to me" is the check;
- trusting a source it cites before you've opened it yourself.
**Whose work is it?** Your student's work is what they planned, wrote, tested, and can explain. If they can't explain a line, it isn't theirs yet. Every project carries a Whose Work Is It? card (AI-06): who or what helped, what was asked, what came back, what was kept, what was changed, and how it was tested.
**One caution from research, with a label.** In a study of high-school math students, those given an unrestricted chatbot did better on practice problems and worse on a later test taken without it; a version with guardrails avoided most of the harm.^[13](#note-13)^ That is high-school math, not 11–14 or code. The rule it supports is the one this book already uses: your student plans, predicts, and debugs first.
**The Grok Bot caution.** If you use Grok Bot, remember that all of your bots share one computer. Keep photos of your children and family off it, and keep your student's portfolio on a family drive.^[14](#note-14)^
## Dose honesty
There is no national table of how many minutes a middle-schooler should code. The standards many schools use imagine the equivalent of a yearlong course across grades 6–8, a school design rather than a home rule.^[15](#note-15)^ Two or three Computing Hours a week across a school year is a full course of experience. On other days, ten minutes is plenty: a Paper Parsons, a Cold Trace, a typing warm-up. Less is still real. Short and frequent beats long and rare.
## The life of the habit
Keep the Debug Log going all year. Do a Cold Trace (AS-01) once a month: a short program traced on paper, without help, dated. Finish a project every four to six weeks. Hold a demo day once a semester for family or a co-op. When the habit leaks out of the Hour, notice it and say so in a sentence.
## Five things to say
1. **Opening.** "Show me the plan. What happens first?" Then count to five in your head.
2. **Predict.** "Write the line: I predict it will… No run without it."
3. **First user.** "I'm going to try it like a stranger would." Then report: "It asked my name, I typed a number, and it crashed. Over to you."
4. **The bug moment.** "What did you expect, what happened instead, and what's your best clue?"
5. **Save and Explain.** "Save it as a new version, two places. Then tell me: 'I predicted… It did… Next I'd change…' and 'Help I used: …'"
## Ready to begin
You have the five steps, the rescue order, the talk-box and try-it shapes, Family safety basics, the screen-time note, and the AI box. Chapter 1 puts the focus line to work. Find bread, a jar, and a pencil.
\newpage
# Chapter 1
## What Computing Looks Like at 11–14: Plans, Algorithms, and Thinking It Through
{width=100%}
## Why this matters
Here is a picture. It is an illustration, not a real family.
Eli is thirteen. His father has asked him to write instructions for making a peanut butter sandwich, and has promised to follow them exactly as written. Eli finds this beneath him. He writes four lines in about a minute: "Get the bread. Put peanut butter on it. Put the other slice on top. Done."
His father picks up the whole loaf, still in its bag, and sets it on the counter. Then he picks up the jar of peanut butter and places it, lid on, on top of the loaf. He looks up. "Done."
Eli laughs, and then he starts to argue. "You know what I meant." His father nods. "I do. A computer won't."
Twenty minutes later Eli has a page of instructions that open the bag, take out exactly two slices, twist the lid counterclockwise, and use the knife. His father asks one more question: "What if the jar is already open?" Eli adds a line that starts with IF.
That is computing at this age. Computing is telling a machine exactly what to do, and then finding out, calmly, why it did something else. A computer never guesses what you meant. It does what you said, in the order you said it, every time.
Eleven- to fourteen-year-olds are ready for this in a new way. They can hold a plan in their heads, write it down, test it, and defend it. They can imagine what might go wrong before it does. They are also ready to make the jump from *using* computers to *making* them do things. That jump is what this book is about.
It helps to know what computing is not. The organization that writes the computer science standards many American schools use says plainly that computer science is not "using technology tools like word processors, slide decks, or generative AI tools." It adds, about AI, "CS is what powers AI."^[16](#note-16)^ A student who can type a fast essay or get an answer from a chatbot is a skilled user. A student who can write the steps, predict what they'll do, and fix them when they go wrong is starting to do computing.
This chapter lays the foundation, and almost none of it needs a screen. Your student will write exact instructions, break big jobs into small ones, draw flowcharts, trace programs by hand, and compare two ways of doing a job. Every later chapter stands on these habits, and on the line the whole book runs on:
**Predict before you run; debug before you rewrite; explain it before you call it yours.**
## For the parent: understand it yourself
You don't need to know a programming language to teach this chapter. You need a handful of ideas in plain words, and the patience to play a very literal computer.
### The big ideas, in plain words
People sometimes call this whole set of habits computational thinking. In this book we'll just say what it is: breaking a job into parts, spotting patterns, writing exact steps, and checking them.
- **An algorithm** is a set of exact steps for doing a job. A recipe is an algorithm. So is the route you drive to the store. In computing, the steps have to be exact enough that something with no judgment at all could follow them.
- **Decomposition** means breaking a big job into smaller jobs. "Make dinner" is too big to program. "Boil water," "cook pasta," and "heat sauce" are getting closer.
- **Pseudocode** is a plan for a program written in plain words, with a few capitalized keywords such as SET, IF, and REPEAT. It isn't any real programming language, and that's the point: your student can think about the steps without worrying about brackets.
- **A flowchart** is the same plan as a picture. Ovals mark the start and end, rectangles are actions, and diamonds are decisions with a "yes" arrow and a "no" arrow.
- **A decision** (IF) lets a program do different things in different situations. **A loop** (REPEAT) does the same steps more than once.
- **A variable** is a labeled box that holds a value, such as a score, and the value can change as the program runs.
- **Tracing** means following a program by hand, line by line, and writing down what's in each box after every step.
The middle-school standards ask students to model an algorithm "with a flowchart or pseudocode" and to "verify the accuracy of an algorithm for given inputs."^[17](#note-17)^ In ordinary words: write the plan, then check that it works on real examples. That's this chapter.
### A program you can trace together
Here is a short program in pseudocode:
```
SET total TO 0
SET n TO 1
REPEAT 4 TIMES
ADD n TO total
ADD 1 TO n
SAY total
```
Trace it with your student on paper, in a table with one column for `total` and one for `n`. After each trip through the loop, write the new values. The first trip makes `total` 1 and `n` 2. Then 3 and 3, then 6 and 4, then 10 and 5. The program says **10**.
Plenty of adults guess wrong the first time. That's normal, and it's exactly why tracing matters. Your student will never trace a program perfectly by looking at it. Writing down each box after each step is how people who program for a living check their own thinking.
### Why paper first
Paper is not a lesser kind of computing. With the screen dark, your student has to hold the whole plan in mind instead of trying random changes to see what sticks. Paper is also where planning mistakes are cheapest. A wrong step in a sandwich spec costs a laugh. The same wrong step in a two-hundred-line program costs an evening.
And on paper, you can see your student's thinking. On a screen, you mostly see the result.
### The student you have
Young teens are building more capacity for complex thought and a stronger sense of right and wrong. They make more of their own choices and become more independent, although parents are still very important.^[18](#note-18)^ That's the practical case for this book's shape: your student writes more of the plan and runs more of the Hour, and you become the first user, the question-asker, and the keeper of the safety rules.
Young teens are also more sensitive to being judged by others than younger children or adults.^[19](#note-19)^ You'll see it when a bug feels like a verdict on the person. Keep every comment about the code: "Line 3 never runs when the jar is open" lands very differently from "You forgot again." Let your student choose what gets shown to anyone outside the family.
One more thing about the student you have. Children pick up the idea that computing is "for" some kids and not others as early as first grade.^[20](#note-20)^ Say plainly, and more than once, that computing is for anyone who likes making things work and figuring out why they don't.
### What the evidence says, honestly
Coding teaches coding. That much is solid. Whether it also helps with math, reading, or general problem-solving is a fair question, and the honest answer is "sometimes, a little, and less than people claim." A large review of studies found that learning to program helps most with skills close to programming, helps less with skills further away, and shows smaller effects when students are compared with others doing a different active task.^[21](#note-21)^ So treat any spillover as a welcome possibility, not a promise.
The good news about this age is solid too. In one carefully designed middle-school course, seventh and eighth graders learned real computer science concepts and carried some of them over to a text programming language, though loops and variables stayed hard for many.^[22](#note-22)^ This is a useful study, not a promise that every home will see the same result. It does match what you'll see at your table: this age can do real work, and some of it will take longer than you expect.
Fast thumbs are not the same thing as exact steps. Most 11- to 14-year-olds have never been asked to write a plan and test it, and that's the skill this book teaches.
### Why the third clause matters
The focus line ends with "explain it before you call it yours." That isn't a homeschool invention. The guidance for one widely taken high-school computer science course says students who use AI tools must be ready "to explain their code in detail."^[23](#note-23)^ At 11–14 this starts small and spoken: "Help I used: none." Chapter 8 goes further.
### Wrong answers you should be able to hear
| What you hear | What it usually means | What you can say |
|---|---|---|
| "You know what I meant." | The steps leave something to guessing. | "I do. The computer won't. Which line needs to be more exact?" |
| "It's obvious." | A hidden step nobody wrote down. | "Then it'll be quick to write. Show me where it goes." |
| "I'll just start over." | Overwhelm. | "Keep this page. Tell me the one thing that's wrong." |
| "It works, so it's right." | One example tested, no others. | "What's the strangest input you can think of? Let's try it." |
| "It says 4." (for the program above) | Guessing instead of tracing. | "Let's write the boxes after each trip around the loop." |
## How to teach it this week
This week's Hours run on the five steps from **The Computing Hour**. Here is how they fit the first activity:
1. **Unplug and Plan.** Your student writes the sandwich spec on paper. Ask the talk-box opening.
2. **Predict.** Your student writes one line: "I predict the sandwich will…"
3. **Build and Test.** You follow the spec exactly, one line at a time.
4. **Debug and Log.** Your student writes an Expected/Actual line (BUG-01), fixes one step, and you run the spec again from the top. Start the Debug Log (BUG-08) with the sandwich bugs: the bug, the clue, the fix.
5. **Save and Explain.** Photograph the marked-up spec. "I predicted… It did… Next I'd change…" and "Help I used: none."
### Exact words you can say
- Opening: "What are the steps — and where could they go wrong?"
- When a step is vague: "Computer does not understand. Which bread? How many slices?"
- After a funny result: "What did you expect? What happened instead?"
- At the fix: "Change one line. Then we start again from the top."
- An edge case: "What if the jar is already open?"
- At the end: "Save it. Then tell me: 'I predicted… It did… Next I'd change…' and 'Help I used: …'"
### In-home — PLAN-01 The Literal Sandwich Spec
- **Time:** about 20 minutes.
- **Materials:** bread, a spread (or a pretend version: a box for the loaf, a jar of anything), a butter knife, paper, and two colors of pen.
- **Safety and privacy:** use a butter knife, and check for food allergies in the room. Any photo is of the paper only.
- **The fun:** a parent who follows instructions with total, deadpan literalness.
- **The skill:** writing precise instructions, and thinking of the cases that could break them.
- **The crumb:** the marked-up spec, with the fixes in a second color.
**How it goes.** Your student writes the spec first, without you watching. Then you follow it line by line, exactly as written, and nothing more. "Put peanut butter on the bread" with no mention of the lid or the knife gets an unopened jar resting on the loaf. Keep a straight face. When it goes wrong, stop and let your student find the first line that failed, fix it in the second color, and run the whole spec again from the beginning.
The 11–14 twist is the edge case. Once the spec works, ask: "What if the jar is already open? What if there's only one slice left?" A good spec handles the ordinary case. A better one says what to do when things aren't ordinary.
**11–12:** your student can say the steps aloud first while you write them, then copy them out. You play the computer.
**13–14:** your student writes the spec alone, then plays the computer for a younger sibling's spec, or for yours. Try to write a spec they can't break. They will break it.
### In-home — PLAN-03 Pseudocode Recipe Card
- **Time:** about 15 minutes.
- **Materials:** an index card, a pencil, and a simple family recipe.
- **Safety and privacy:** paper only; no cooking needed.
- **The fun:** turning grandma's pancakes into something a robot could follow.
- **The skill:** plain-language pseudocode with IF and REPEAT.
- **The crumb:** the card.
**How it goes.** Pick a recipe and rewrite it in pseudocode, with at least one decision and one loop:
```
SET cups_of_flour TO 2
REPEAT cups_of_flour TIMES
ADD 1 cup of flour TO bowl
ADD milk TO bowl
STIR
IF batter is lumpy THEN STIR again
```
Then swap: you read the card aloud as a literal computer, and your student listens for gaps. Where does the butter go? How long is "stir"?
**11–12:** one decision and one loop is plenty. **13–14:** add a decision with two outcomes (IF … ELSE), or a loop that repeats until something happens.
### In-home — PLAN-04 Flowchart the Morning
- **Time:** about 20 minutes.
- **Materials:** a large sheet of paper, a pencil, and an eraser.
- **Safety and privacy:** first names only if it's posted on the fridge.
- **The fun:** discovering how many decisions happen before breakfast.
- **The skill:** a flowchart with decision diamonds and a loop.
- **The crumb:** the flowchart.
**How it goes.** Your student draws the morning routine as a flowchart, from "alarm rings" to "out the door." Every decision is a diamond with exactly one question and two arrows, yes and no: "Is it a school day?" "Is the bathroom free?" At least one arrow should loop back: "Snooze pressed? Yes → back to alarm rings." Then you follow the flowchart with your finger, out loud, and your student checks whether it really describes their morning.
The usual trouble is a diamond with three questions in it. One question per diamond. If a diamond needs "and," it's two diamonds.
### In-home — ALG-01 Guess My Number
- **Time:** about 10 minutes.
- **Materials:** paper and a pencil for keeping count.
- **Safety and privacy:** none needed. It works in the car.
- **The fun:** beating a parent at their own game, in very few guesses.
- **The skill:** searching by halving, and counting the steps.
- **The crumb:** the guess counts for 1–100 and for 1–1,000.
**How it goes.** You pick a secret number from 1 to 100. Your student guesses, and you say only "higher," "lower," or "yes." Count the guesses. Play a few rounds, then ask: "What's the best first guess? Why?"
The best plan is to guess the middle every time, which throws away half of the remaining numbers with each guess. Played that way, any number from 1 to 100 takes at most 7 guesses. Here's the surprise: 1 to 1,000 takes at most 10. Ten times as many numbers, only three more guesses. Let your student discover that by playing before you explain it. Chapter 2 turns this game into a real program.
**13–14:** ask your student to explain why each guess halves the problem, and to predict the most guesses needed for 1 to 2,000 before testing it.
### Talk box (this chapter)
**Opening:** "What are the steps — and where could they go wrong?"
**Follow-ups:**
1. Prediction: "What will happen at this step, exactly as it's written?"
2. Evidence: "What did you see that makes you say it worked?"
3. Location: "Which step is the last one that did what you expected?"
4. Change: "What's the one line you'd change?"
5. Edge case: "What's the strangest situation this plan might meet?"
**How to wait.** After you ask, count to five in your head. When the question is about code on the screen, let them read as long as they need. This chapter mostly lives on paper, so look at the page, not at your student. Your eyes on the plan say "we're examining the steps," not "I'm examining you."
**What a stuck silence usually means.** The question was too big ("Why didn't it work?"), so shrink it: "Was it this step or that one?" Your student may be bracing for a verdict, so name a bug of your own first. They may be waiting for you to fix it, so put the pencil down on your side of the table. Or there was no prediction, so there's nothing to compare. Go back and make one.
**Don't say / say instead.** Don't say "That's not how you make a sandwich." Say "I did exactly what line 2 says. Is that what you wanted?"
### How to fade help
Use the rescue order from **The Computing Hour**: ask → wait → hint → short demo on your own copy → hand it back.
- **First Hour:** you may point to the step that broke: "Look at line 2."
- **Second Hour:** ask only where it first went wrong.
- **By week's end:** ask the opening question and let your student run the fix.
When you notice good work, name it exactly. "You added a line for when the jar is already open, before I even asked" teaches more than "Great job."
### This week at a glance
| Day | Focus | Try-it |
|---|---|---|
| Hour 1 | Exact steps and edge cases | PLAN-01 The Literal Sandwich Spec; start the Debug Log |
| Hour 2 | Searching by halving | ALG-01 Guess My Number |
| Hour 3 | Plans on paper | PLAN-03 Pseudocode Recipe Card or PLAN-04 Flowchart the Morning |
| Other days | Ten minutes | PLAN-07 Paper Parsons; a trace table |
| Errand | Algorithms around you | OUT-01 Algorithms in the Wild |
| End of week | A baseline | AS-01 Cold Trace (see "done enough") |
## Practice that actually builds learning
Pick one or two of these per Hour over the next few weeks. Each is short, and most need nothing but paper.
### In-home — PLAN-02 Break It Down Tree
- **Time:** about 15 minutes.
- **Materials:** a large sheet of paper and a pencil.
- **Safety and privacy:** none needed.
- **The fun:** finding out how many tiny jobs hide inside one big one.
- **The skill:** decomposition: breaking a real job into parts a program could do.
- **The crumb:** the tree, dated.
**How it goes.** Write a big job at the top: "Host a family game night" or "Make tacos for six." Your student breaks it into three or four smaller jobs, then breaks each of those again, until every bottom box is something a person, or a program, could just do. "Choose a game" becomes "list the games we own," "count the players," and "cross off games for fewer players." Stop when the boxes are small enough to act on.
**13–14:** circle the boxes a computer could actually handle (counting, sorting, checking a list), and the ones that need a person.
### In-home — PLAN-05 Trace Table by Hand
- **Time:** about 15 minutes.
- **Materials:** paper ruled into columns, and a short program in pseudocode.
- **Safety and privacy:** none needed.
- **The fun:** being the computer, and catching your own wrong guess.
- **The skill:** tracing variable values line by line.
- **The crumb:** the trace table.
**How it goes.** Use the `total` and `n` program from "For the parent." Your student writes a prediction first, then traces it with one row per trip around the loop, and compares. Then change one line, such as REPEAT 5 TIMES, and predict again before tracing. The habit to build is predicting first, so a wrong guess becomes a clue instead of an embarrassment.
### In-home — PLAN-06 Two Algorithms, One Job
*For 13–14; ready 12.*
- **Time:** about 20 minutes.
- **Materials:** paper, a pencil, and a calculator for checking.
- **Safety and privacy:** none needed.
- **The fun:** finding a shortcut that does a hundred steps' work in one.
- **The skill:** comparing two algorithms by counting their steps.
- **The crumb:** the two step counts, side by side.
**How it goes.** The job: add up every whole number from 1 to 100. Algorithm A adds them one at a time: 1 + 2 = 3, 3 + 3 = 6, and so on. Count the additions: 99. Algorithm B pairs the numbers from the ends: 1 and 100 make 101, 2 and 99 make 101, all the way to 50 and 51. That's 50 pairs of 101, so the answer is 50 × 101 = 5,050, in one multiplication. Both get the same answer. One takes far fewer steps. That's what programmers mean by *efficient*.
Ask your student to predict how the step counts change for 1 to 1,000.
### In-home — PLAN-07 Paper Parsons
- **Time:** about 10 minutes.
- **Materials:** a short program printed or written out, cut into strips, one line per strip; tape.
- **Safety and privacy:** use scissors with care.
- **The fun:** a puzzle where every piece is a line of code.
- **The skill:** reading a program's order and structure.
- **The crumb:** the taped strip, in the right order.
**How it goes.** Cut up a short program, such as the pancake card or this one, mix the strips, and have your student put them in order:
```
SET coins TO 0
REPEAT 5 TIMES
ADD 3 TO coins
IF coins > 10 THEN SAY "Enough for a snack"
```
Indented strips stay indented, so your student can see which lines belong inside the loop. Putting lines in order is a gentler start than writing from a blank page. One study, with university students, found that this kind of puzzle took less time than writing or fixing the same code, with similar learning.^[24](#note-24)^ It is not a study of 11- to 14-year-olds, but it explains why Parsons puzzles turn up again in later chapters.
### In-home — ALG-02 Card Sort Race
- **Time:** about 20 minutes.
- **Materials:** a deck of playing cards; paper for keeping a tally.
- **Safety and privacy:** none needed.
- **The fun:** a race where the slower method sometimes wins.
- **The skill:** two sorting methods, and counting comparisons.
- **The crumb:** the comparison tally.
**How it goes.** Deal eight cards face up in a row. Method one (selection sort): scan the whole row for the smallest card, move it to the front, then scan the rest for the next smallest, and so on. Method two (insertion sort): take cards one at a time from the left and slide each one back to its correct place among the cards already sorted. One player counts aloud every time two cards are compared.
Selection sort always takes 28 comparisons for eight cards, however they start. Insertion sort depends on the deal. Give it eight cards already in order, and it needs only 7. Ask your student to predict which method wins on an already-sorted row, then on a reversed one, and test both.
### In-home — ALG-03 Sorting Network on the Floor
- **Time:** about 20 minutes.
- **Materials:** masking tape, four index cards with numbers on them, and four people (or four stuffed animals moved by hand).
- **Safety and privacy:** clear the floor first. If you take a photo, take it of the tape, with no faces.
- **The fun:** a sorting machine you walk through.
- **The skill:** a sorting network: comparisons that happen side by side.
- **The crumb:** a photo of the floor network, with no faces.
**How it goes.** Tape four parallel lanes on the floor, with three rows of meeting squares. In row one, lane 1 meets lane 2, and lane 3 meets lane 4. In row two, lane 1 meets lane 3, and lane 2 meets lane 4. In row three, lane 2 meets lane 3. Each walker holds a number card and walks forward. At a meeting square, the two walkers compare cards: the smaller number takes the left lane out, the larger takes the right. Whatever order you start in, the cards come out sorted in three rows and five comparisons.
The idea comes from CS Unplugged, a free collection of computing activities without computers, which lists sorting networks for ages 5 to 14 and has a larger version with more lanes.^[25](#note-25)^ **13–14:** ask why two pairs can compare at the same time. Doing many comparisons at once is one way computers speed up big jobs.
### In-home — ALG-04 Battleships Search
- **Time:** about 20 minutes.
- **Materials:** two sheets of paper, each with a row of fifteen boxes; thirty small sticky notes; two pencils.
- **Safety and privacy:** none needed.
- **The fun:** a hidden-number duel.
- **The skill:** searching one by one versus searching by halving.
- **The crumb:** the score sheet with the number of looks for each round.
**How it goes.** Each player secretly writes fifteen numbers in their boxes and covers each with a sticky note. The other player names a target number and uncovers one box at a time to find it, counting each look. Round one: the numbers are in random order. The searcher may need all fifteen looks. Round two: the numbers are written in order from smallest to largest. Now the searcher can open the middle box and throw away half the row, just like Guess My Number. Fifteen sorted boxes take at most 4 looks. CS Unplugged has a printable version of this game.
**11–12:** play round one and two, and talk about the difference. **13–14:** explain why sorting first pays off only when you'll search more than once.
### Out-of-home — OUT-01 Algorithms in the Wild
- **Time:** about 20 minutes during an errand or walk.
- **Materials:** a notebook and a pencil.
- **Safety and privacy:** stand well back from the curb when watching traffic lights. Watch machines; leave other people out of notes and photos. At a self-checkout, watch without using someone else's lane. See Family safety basics in **The Computing Hour**.
- **The fun:** spotting the hidden program in something you see every day.
- **The skill:** writing pseudocode for a real machine.
- **The crumb:** the pseudocode page.
**How it goes.** Pick one machine: a traffic light, an elevator, or a self-checkout at the store. Watch it for a few minutes and talk about what it seems to do and when. Then sit on a bench and write its algorithm in pseudocode:
```
REPEAT forever
SHOW green FOR some seconds
SHOW yellow FOR a few seconds
SHOW red
IF a car is waiting on the side road THEN let it go
```
Then hunt for edge cases. What does the elevator do if people on two floors press the button at once? What if someone scans the same item twice? Your student won't know the real program, and that's fine. The point is a plausible one, exact enough to argue about.
**13–14:** write a second version that handles one edge case, and say which is better and why.
### Blocked, then mixed
**Blocked practice for the new move.** For the first week or two, every Hour includes the same core move: write exact steps, predict, and test them. Sandwich on Monday, pancakes on Wednesday, the morning on Friday.
**Mixed practice.** After that, mix it up. One Hour might hold a Paper Parsons, a trace table, and a round of Guess My Number. Mixing helps your student learn *when* to use each move, not just how.
### One incorrect example to diagnose
Here is an illustration, not a real family. A twelve-year-old writes a flowchart for "get ready for bed." One diamond reads: "Teeth brushed and pajamas on and homework done?" The "no" arrow points to "do the missing thing." The parent follows it and stops: "Which missing thing?"
**Diagnosis.** Three questions in one diamond, so the "no" answer can't say what to do next.
**Rescue.** One question per diamond. Split it into three diamonds, each with its own "no" arrow to a specific action. Then follow the chart again with your finger.
## For the student
This chapter is about something programmers do all day that most people never see: thinking it through before touching the keyboard.
You might picture a programmer typing fast, code flying across the screen. Real programming looks more like this: read the problem, plan, write a little, test it, find out why it didn't work, fix it, test again. A lot of the time goes into planning, reading, testing, and fixing. The typing is often the quick part.
That's why this chapter happens mostly on paper. It might feel like the baby version of coding. It isn't. Paper is where you can see the whole plan at once, and where mistakes are cheap.
**A computer does what you say, not what you mean.** That's the most important idea in this book. If you write "put peanut butter on the bread" and forget to say "open the jar," a computer won't open the jar. It isn't being stubborn. It has no idea what a jar is. It follows the steps, exactly, in order.
So your job is to write steps so exact that something with zero judgment could follow them. Steps like that are called an **algorithm**. Writing them in plain words with a few keywords (SET, IF, REPEAT) is called **pseudocode**, which means "pretend code." It's the plan before the program.
**A tiny example.** Here's a plan in pseudocode:
```
SET lives TO 3
REPEAT 2 TIMES
SUBTRACT 1 FROM lives
IF lives > 0 THEN SAY "Keep going" ELSE SAY "Game over"
```
What will it say? Write your prediction down before you read on.
Start with 3 lives. Lose one: 2. Lose another: 1. Is 1 more than 0? Yes. So it says "Keep going." If you predicted "Game over," find the step where your thinking went a different way. Maybe you counted three trips through the loop instead of two. That's a bug in your trace, and finding it is exactly the skill.
**Your Debug Log.** Starting this week, you keep a Debug Log: a dated notebook (paper or a plain file) that holds predictions, bugs, clues, and fixes. Before you run anything, write a prediction. When something surprises you, write two things before you change anything: what you expected, and what actually happened. Then write the clue and the fix. It takes thirty seconds. In a month, it'll show you how much you've learned, and it'll save you from fixing the same bug twice.
**The line this book runs on.** You'll see it everywhere: *Predict before you run; debug before you rewrite; explain it before you call it yours.* In your own words, it means:
- Guess first, so you'll know if you're right.
- When it breaks, find the broken part. Don't throw the whole thing away.
- If you can't explain it, it isn't yours yet. And always say what help you used, even if the answer is "none."
**This part is hard for everyone.** Writing steps exact enough for a computer is harder than it looks, for adults too. People who program for a living still write plans that miss a case. The difference is that they expect it, look for it, and fix it without drama.
**Try this today.** Write the instructions for something you do every day: making toast, tying a shoe, logging in to a game. Then hand them to someone and ask them to follow them exactly, with no guessing. Watch where it goes wrong. Fix one line at a time.
**Explain it back.** Tell someone in two or three sentences: why does a computer need more exact steps than a person does? Use your own example.
**If you're 13 or older:** write a spec that someone else, maybe a younger sibling, has to follow, and then try to break theirs. Look for the edge cases: the jar that's already open, the last slice of bread, the elevator button pressed twice.
**Challenge.** Play Guess My Number with 1 to 100 until you can always win in 7 guesses or fewer. Then predict: how many guesses for 1 to 1,000? Test it. Can you explain why the answer is so small?
**What to save.** Your sandwich spec with the fixes, your first Debug Log page, and your Guess My Number counts. Date them all.
## If it isn't clicking
**The steps are too vague.** Play the literal computer again, and be truly literal. "Put it on the plate" gets "Put what? Which plate?" Then have your student read their own spec aloud, slowly, as if they'd never seen a sandwich.
**Flowchart spaghetti.** Arrows cross everywhere and diamonds hold three questions. One decision per diamond. Start again on a fresh sheet with just three boxes, then add one at a time.
**"This is boring. I want to code."** Fair enough. Show PY-02 Predict the Print on paper today: a four-line Python program, a written prediction, and a check. It's real code, and it uses exactly the same habit. Install Thonny tomorrow (Chapter 2). Then come back to planning, and point out that the prediction they just made was a trace.
**Tracing goes wrong every time.** Slow down to one line at a time, and write the boxes after every line, not just at the end of each loop. Use sticky notes as boxes and physically replace the number each time.
**Your student is far ahead of you.** Wonderful. Your job doesn't change: ask for the prediction, be the first user, and ask for the explanation. Have your student teach you the trace.
**A thirteen-year-old new to all of this.** Start here anyway. The 13–14 moves go fast.
## Tools, including AI
**What you need:** a pencil, an eraser, paper, index cards, a deck of playing cards, and masking tape. That's the whole list.
**Optional:** CS Unplugged (free, printable) for the sorting network and searching games.^[25](#note-25)^
**AI:** none needed for this chapter. Planning, predicting, and tracing are the student's own work, and they're the muscles everything else depends on. For the rules on AI at each age, see the AI box in **The Computing Hour**.
## What "done enough" looks like
Your student is ready to move on when they can:
- write pseudocode for an everyday job that includes at least one decision (IF) and one loop (REPEAT);
- trace a five-line program on paper and predict what it will say;
- explain, in their own words, why guessing the middle finds a number so fast;
- write an Expected/Actual line before fixing something;
- say the exit lines without prompting: "I predicted… It did… Next I'd change…" and "Help I used: …"
**11–12:** spoken explanations are fine; the pseudocode can be short. **13–14:** written explanations, and at least one comparison of two algorithms by counting steps.
### AS-01 Cold Trace (baseline)
At the end of this chapter, do a first Cold Trace. It's a ten-minute check your student does alone: no help from you, no screen, and no AI. Hand over this program and ask for a prediction of what it says, with a trace table:
```
SET coins TO 4
REPEAT 3 TIMES
ADD 2 TO coins
IF coins > 8 THEN SAY "Piggy bank full" ELSE SAY "Keep saving"
```
(The answer: `coins` goes 6, 8, 10, so it says "Piggy bank full.")
Date the sheet and file it. Right or wrong, this is a baseline, not a grade. You'll do a Cold Trace once a month, and by spring this first sheet will show your student how far they've come.
If most of the list is in place, move on to Chapter 2, where these plans become real Python. Planning never goes away. It just gets a keyboard.
\newpage
# Chapter 2
## From Blocks to Text: First Programs in Python
{width=100%}
## Why this matters
Many students arrive at this chapter with years of block coding behind them. They've snapped together Scratch games with scores, timers, and sprites that bounce off walls. That was real programming. The ideas in those blocks (steps in order, decisions, loops, variables) are the same ideas inside every program on every computer.
Text code is the next step. Most software is written by typing lines in a programming language, and this chapter starts your student doing exactly that, in Python.
Text brings three new powers. It's precise: every character means something. It's fast: once your fingers know the way, typing a line is quicker than dragging a block. And it's readable by others: your student can read code that other people wrote, and the documentation that explains how a language works.
Text also brings a new kind of trouble. In blocks, pieces only fit where they belong. In text, a missing bracket stops everything, a capital letter in the wrong place is a different word, and the computer replies in red. This chapter is about making that move with no drama and no loss of confidence. Red text is information, not judgment. Your student will learn to read it, find the line it names, change one thing, and run it again.
The habit that makes it all work is the first clause of the focus line, now with real code: predict before you run.
## For the parent: understand it yourself
You can teach this chapter without being a programmer. You need to know what a handful of Python lines do, well enough to read them aloud and ask good questions. Here they are.
### Why Python
Python is a programming language that reads more like English than most. Its makers describe it as "friendly & easy to learn" and open, and it's used for web development, science, education, and games.^[26](#note-26)^ It's free. It's also the language of the home editor this book recommends. Your student won't stay with Python forever, and doesn't need to. The habits learned here move to any language.
### Five ideas, one at a time
**Printing and running.** `print()` shows something on the screen. Running a program means telling the computer to follow its lines from top to bottom.
```python
print("Hello, world!")
```
This prints `Hello, world!` The quotation marks tell Python it's text, not an instruction.
**Variables.** A variable is a labeled box whose contents can be replaced. The equals sign in Python doesn't mean "is equal to forever." It means "put this value in this box now."
```python
snack = "apple"
count = 2
count = count + 1
snack = "pretzel"
print(count, snack)
```
This prints `3 pretzel`. The box called `count` held 2, then 3. The box called `snack` held "apple," then "pretzel." The old contents are gone.
**Types: text versus numbers.** Python treats `"12"` (text, in quotes) and `12` (a number) as different things. You can do arithmetic with a number, not with text. This matters most with `input()`, which asks the person at the keyboard to type something. Python's documentation says it "reads a line from input, converts it to a string," which is programmer talk for text, "and returns that."^[27](#note-27)^ So a typed age arrives as text and has to be turned into a number with `int()`:
```python
name = input("What is your first name? ")
age = input("How old are you? ")
next_year = int(age) + 1
print("Hi,", name)
print("Next year you will be", next_year)
```
If your student types Sam and 12, this prints `Hi, Sam` and `Next year you will be 13`. Leave out `int()` and write `age + 1`, and Python stops with a `TypeError`: it can't add a number to text. That error is one of the most common in the first month, and now you'll recognize it.
**Decisions: if, elif, else.** `if` checks whether something is true. `elif` (short for "else if") checks another possibility. `else` catches everything left over.
```python
answer = input("Left or right? ")
if answer == "left":
print("You find a quiet library.")
elif answer == "right":
print("You find a noisy market.")
else:
print("You stand still. Nothing happens.")
```
Two equals signs (`==`) mean "is this equal?" One equals sign means "put in the box." Type `left` and you find the library. Type `Left`, with a capital, and you stand still, because to Python those are different words. The indented lines, four spaces in, belong to the line above them. In Python, indentation is part of the meaning.
**Loops: for and while.** A `for` loop repeats a set number of times:
```python
for number in range(1, 6):
print(number * 3)
```
This prints 3, 6, 9, 12, and 15, each on its own line. `range(1, 6)` counts from 1 and stops *before* 6, a detail that trips up nearly everyone at first. A `while` loop repeats as long as something stays true, which is perfect for games that go on until the player wins. You'll see one in the guess-the-number game below.
### Blocks to text: what the research says
Studies of block and text programming have mostly been done with high-school students, so read them as a picture of older beginners. In one, students who started with blocks learned more in the first weeks and were more interested in further computing courses, while students who started with text felt their work was closer to what professional programmers do. A follow-up found the difference had disappeared after the students spent ten weeks in a professional text language.^[28](#note-28),[29](#note-29)^
The practical lesson: blocks were never babyish, and starting text now leaves nobody behind. Scratch is designed especially for ages 8 to 16, so it's fine to keep it around for quick sketches and fun.^[30](#note-30)^ This chapter uses Scratch on purpose in the first weeks, side by side with Python, so your student can see that the ideas they already know have new clothes.
### How to teach code: read before you write
The method this book uses is called PRIMM: **P**redict, **R**un, **I**nvestigate, **M**odify, **M**ake. Your student reads a short working program first and predicts what it will do. Then they run it and compare. Then they investigate ("What happens if I change this number?"), modify it to do something a little different, and finally make something of their own. A large study in schools found that students aged about 11 to 14 who learned this way did a little better on a programming test than students who didn't.^[31](#note-31)^ It is a small edge, not a miracle, and it matches the Hour's shape.
The weekly arc is the same idea in three words: **Use, Modify, Create.** Use a working program, change one part, then build your own. It grew out of programs for middle- and high-school students.^[32](#note-32)^ It also takes the terror out of the blank page.
The standards for this age ask students to use variables of different types, to analyze how loops, decisions, and variables work in a piece of code, and to "use reference documentation in program development."^[17](#note-17)^ PRIMM and Use-Modify-Create cover all three.
### Installing Thonny
Thonny is the book's home editor for Python. It's free, it comes with Python built in, it needs no account, and it runs offline once installed. It has a step-by-step mode that runs a program one piece at a time, and a Variables view that shows what's in every box.^[2](#note-2)^ Install it yourself before your student does, so you've seen the screens. The top half is where you write the program. The bottom half, called the Shell, is where the output and any red error messages appear.
### Wrong answers you should be able to hear
| What you hear | What it usually means | What you can say |
|---|---|---|
| "The computer is broken." | Expected and actual differ, and there's no clue yet. | "It did exactly what we told it. Which line is the last one that did what you expected?" |
| "x = 5 means x equals 5 forever." | Mixing up "put in the box" with "is equal." | "It's a box. What's in the box after line 4?" |
| "I typed it exactly right." | A capital letter, a missing bracket, or a missing colon. | "Read it to me one character at a time." |
| "It says error, so it's all wrong." | One error stops the run, but most lines are fine. | "Which line does it name? Let's start there." |
| "I'll just start over." | Overwhelm. | "Save this as a new version first. Then tell me the one thing that's wrong." |
## How to teach it this week
This week's Hours run on the five steps from **The Computing Hour**, with Python on the screen. Here's how a typical Hour fits:
1. **Unplug and Plan.** Read the day's program on paper, or translate a Scratch script on paper. Ask the talk-box opening.
2. **Predict.** Your student writes a prediction line in the Debug Log for every program before it runs.
3. **Build and Test.** Your student types and runs the program in Thonny, then changes one thing at a time.
4. **Debug and Log.** When it surprises them: an Expected/Actual line first (BUG-01), then read the error's last line and the line number it names, change one thing, and run again. One line in the Debug Log (BUG-08).
5. **Save and Explain.** A new version, date-first name, in two places. "I predicted… It did… Next I'd change…" and "Help I used: …" From this chapter on, "Help I used" is a habit, not an occasional question.
### Exact words you can say
- Opening: "What do you predict this line will do — and why?"
- When the screen goes red: "Read me the last line. What line number does it name?"
- When your student wants to change three things: "Pick one. Run it. Then we'll see."
- When it works: "Before we move on, what did line 3 do?"
- At the end: "Save it, two places. Then tell me: 'I predicted… It did… Next I'd change…' and 'Help I used: …'"
### In-home — BLK-01 Scratch Side-by-Side
- **Time:** about 20 minutes.
- **Materials:** Scratch open on the screen (no account needed to make a project), paper, and Thonny.
- **Safety and privacy:** no sharing projects online; that's a family decision for later.
- **The fun:** discovering that you already know Python's ideas.
- **The skill:** matching each block to a line of Python.
- **The crumb:** a two-column sheet: blocks on the left, Python on the right.
**How it goes.** Build this tiny script in Scratch: *when green flag clicked*, *set score to 0*, *repeat 3*, *change score by 1*, and after the loop, *say score*. Run it. The sprite says 3. Now write the Python beside it:
```python
score = 0
for i in range(3):
score = score + 1
print(score)
```
Predict, then run it in Thonny. It prints `3`. Draw a line from each block to its Python line. Notice what Python needs that Scratch didn't: a colon at the end of the `for` line, and four spaces before the line inside the loop. Those are the jobs the C-shaped block was doing.
**11–12:** do this twice more with your student's own small scripts. **13–14:** one is enough; move on to BLK-03.
### In-home — PY-01 Hello, Editor
- **Time:** about 20 minutes.
- **Materials:** a computer with Thonny installed.
- **Safety and privacy:** files go in a family folder, with a first name only in any file name.
- **The fun:** making the computer say something you chose.
- **The skill:** opening the editor, `print()`, running, and saving with a name a stranger could read.
- **The crumb:** the first file, named date first.
**How it goes.** If you did this in your first week (How to Use This Book This Week), do it again with a twist. Your student types `print("Hello, world!")`, predicts, and presses Run. Then three more `print` lines, saying anything they like. Save it with the date first, such as `2026-10-12-hello.py`, in two places. Then make a deliberate mistake: delete the closing bracket and run it. Read the red text together, find the line number, and fix it. Your student has now caused, read, and fixed an error on purpose, on day one.
### In-home — PY-02 Predict the Print
- **Time:** about 15 minutes.
- **Materials:** a short program on paper; the Debug Log; Thonny.
- **Safety and privacy:** none needed.
- **The fun:** betting against the computer, and sometimes winning.
- **The skill:** predicting the output of a short program, running it, and investigating any surprise.
- **The crumb:** the prediction line and the result line.
**How it goes.** Use the four-line program from **The Computing Hour** (score starts at 3, then line 2 adds 2) or any short program from "For the parent." Your student writes a prediction for every line of output, then types and runs the program, and writes what actually happened beside the prediction. If they differ, investigate: "Which line did something you didn't expect?" Then change one number and predict again.
### In-home — PY-03 Variable Boxes
- **Time:** about 10 minutes.
- **Materials:** sticky notes and a marker.
- **Safety and privacy:** none needed.
- **The fun:** being the computer's memory.
- **The skill:** seeing that a new value replaces the old one, and that text and numbers are different.
- **The crumb:** a photo of the boxes after the trace.
**How it goes.** Take the `snack` and `count` program from "For the parent." Each variable gets a sticky note with its name on top. Your student reads the program aloud, line by line. Each time a box gets a new value, they cross out the old one, or peel off the note and write a new one. At the end, read what's in each box. Then ask: "What would happen if `count` were `"2"`, in quotes?" Text in quotes can't be added to a number. Writing a word like "TEXT" or "NUMBER" in the corner of each note helps.
### Talk box (this chapter)
**Opening:** "What do you predict this line will do — and why?"
**Follow-ups:**
1. Prediction: "And the line after that?"
2. Evidence: "What in the code makes you think so?"
3. Location: "Which line is the last one that did what you expected?"
4. Change: "What's the one change you'd try first?"
5. Revision: "You can change your prediction. Run it again."
**How to wait.** After you ask, count to five in your head. When the question is about code on the screen, let them read as long as they need. Reading code is slow, even for experienced programmers. Look at the screen, not at your student.
**What a stuck silence usually means.** The program is too long to hold in mind, so cover all but the first two lines with a sheet of paper. Your student doesn't know what one piece means, such as `range` or `==`, and is embarrassed to say so; ask, "Which word on this line is the least familiar?" They're waiting for you to fix it, so put your hands in your lap. Or the red text feels like a verdict. Read the last line aloud yourself, calmly, as if it were a weather report.
**Don't say / say instead.** Don't say "You typed it wrong." Say "Read me line 3, one character at a time."
### This week at a glance
| Day | Focus | Try-it |
|---|---|---|
| Hour 1 | Same ideas, new clothes | BLK-01 Scratch Side-by-Side |
| Hour 2 | The editor, and a first error on purpose | PY-01 Hello, Editor; PY-02 Predict the Print |
| Hour 3 | Boxes that change | PY-03 Variable Boxes, then type and run the program |
| Other days | Ten minutes | PLAN-07 Paper Parsons with Python lines; a typing warm-up |
| Errand | A full Hour away from home | OUT-02 Library Computer Hour |
## Practice that actually builds learning
Over the next four to six weeks, work through these roughly in order. Each new idea gets a week or so of practice before the next arrives.
### In-home — BLK-03 Block-to-Line Translator
- **Time:** about 15 minutes.
- **Materials:** two or three Scratch scripts drawn or printed on paper, and a pencil.
- **Safety and privacy:** none needed.
- **The fun:** cracking a code you already half know.
- **The skill:** translating blocks into Python on paper.
- **The crumb:** the translated lines.
**How it goes.** Give your student a Scratch script on paper, such as *ask "What's your name?" and wait*, then *say (join "Hi, " (answer))*. Their job is to write the Python without a computer: `name = input("What's your name? ")` and `print("Hi,", name)`. Then try one with *if … then … else*. Type the translation into Thonny afterward to check. **13–14:** translate a script with a loop inside a decision, and get the indentation right on paper first.
### In-home — BLK-02 Remix and Explain
*For 11–12.*
- **Time:** about 25 minutes.
- **Materials:** a working Scratch project, opened from your family's files or the Scratch site, with you present.
- **Safety and privacy:** no sharing, comments, or account sign-ups during this activity. If you open a project someone else made, it stays a private remix.
- **The fun:** changing one rule in a game and seeing what breaks.
- **The skill:** Use, Modify, Create: changing one part of a working program and explaining the change.
- **The crumb:** the saved remix, with a credit line naming the original maker.
**How it goes.** Your student plays the project, then changes exactly one rule: the speed, the score for a hit, the number of lives. Before running it, they predict what will be different. Afterward, they explain the change in one sentence and write a credit line: "Original by ___. I changed ___." That credit line is the start of a habit the whole book cares about.
### In-home — PY-04 Ask and Answer
- **Time:** about 20 minutes.
- **Materials:** Thonny.
- **Safety and privacy:** use a first name, or a made-up one, in any program that asks a name.
- **The fun:** a program that talks back.
- **The skill:** `input()`, text versus numbers, and `int()`.
- **The crumb:** the program file.
**How it goes.** Start with the name-and-age program from "For the parent." Predict, run, and type Sam and 12 (or any first name). Then plant the bug on purpose: change `int(age) + 1` to `age + 1` and predict what will happen. Run it, and read the `TypeError` together. The last line of the error names the problem. Fix it. Then modify: ask for a favorite number and print double it.
### In-home — PY-05 Choose Your Path
- **Time:** about 30 minutes.
- **Materials:** paper for a path map; Thonny.
- **Safety and privacy:** none needed.
- **The fun:** a tiny text adventure where the player's choices matter.
- **The skill:** `if`, `elif`, and `else`.
- **The crumb:** the program file plus the path map.
**How it goes.** Start with the left-or-right program from "For the parent." Before typing, your student draws a path map on paper: a box for each choice and an arrow for each answer. Then they predict what happens for "left," "right," "Left," and "banana," and run all four. The "Left" surprise is the lesson: to Python, a capital letter makes a different word. Then modify: add a third path, or a second question inside one path. **13–14:** make the program accept "Left" too, and explain how.
### In-home — PY-06 Loop It
- **Time:** about 25 minutes.
- **Materials:** Thonny; the Debug Log.
- **Safety and privacy:** none needed.
- **The fun:** making the computer do a hundred things with two lines.
- **The skill:** `for` loops with `range()`, and counting patterns.
- **The crumb:** the program file.
**How it goes.** Start with the three-times-table loop from "For the parent." Predict all five lines of output before running. Then change `range(1, 6)` to `range(1, 11)` and predict the last number. Many first predictions include the stopping number. That's the lesson: `range` stops just before it. Then modify: print the five times table, or count down from 10.
### In-home — PY-07 Turtle Patterns
- **Time:** about 30 minutes.
- **Materials:** Thonny.
- **Safety and privacy:** none needed.
- **The fun:** a program that draws.
- **The skill:** loops that draw shapes, using Python's turtle module.
- **The crumb:** a screenshot of the pattern.
**How it goes.** Python's turtle module is a little on-screen pen that moves and turns when told. It comes from the drawing tools of Logo, an educational language from 1967.^[33](#note-33)^
```python
import turtle
pen = turtle.Turtle()
for side in range(4):
pen.forward(100)
pen.right(90)
turtle.done()
```
This opens a window and draws a square, 100 steps on each side. Before running it, your student predicts the shape. Then: what would make a triangle? (Three sides, turning 120 each time.) A hexagon? A star? Let them predict the angle before each run. **13–14:** draw a square inside a loop that turns a little after each square, and predict the pattern before running it.
### In-home — PY-08 Guess-the-Number Game
- **Time:** about 40 minutes, across two weeks.
- **Materials:** Thonny; the Debug Log.
- **Safety and privacy:** none needed.
- **The fun:** a real game, written by your student, that a sibling can play.
- **The skill:** a `while` loop, random numbers, and decisions, in a Use-Modify-Create project.
- **The crumb:** the version 1 and version 2 files.
**How it goes.** This is Chapter 1's Guess My Number, as a program. Week one is Use: your student types this, predicts what will happen, and plays it.
```python
import random
secret = random.randint(1, 20)
guess = 0
while guess != secret:
guess = int(input("Guess a number from 1 to 20: "))
if guess < secret:
print("Too low.")
elif guess > secret:
print("Too high.")
print("You got it!")
```
`random.randint(1, 20)` picks a whole number from 1 to 20, including both ends.^[34](#note-34)^ `!=` means "is not equal to." The loop keeps asking until the guess matches. Ask: "Using the halving trick, what's the most guesses you should ever need?" (Five.)
Week two is Modify and Create. Save the first version, then save a copy as version 2 and change it: a range of 1 to 100, a different message for each try, or a limit on guesses. **11–12:** one change, predicted and tested. **13–14:** add a guess counter that reports "You got it in 4 guesses," and a question at the end that offers to play again. Chapter 3 comes back to this game to debug it.
### PLAN-05 and PLAN-07, now in Python
Chapter 1's trace tables and Paper Parsons work just as well with Python. For a trace table (PLAN-05), use the `snack` and `count` program, with a column for each variable. For a Paper Parsons (PLAN-07), cut the guess-the-number game into strips, one line each, mix them, and have your student put them back in order, keeping each strip's indentation. Both make good ten-minute practice on days without a full Hour.
### Out-of-home — OUT-02 Library Computer Hour
- **Time:** about 45 minutes.
- **Materials:** a public library computer, your own USB stick, a notebook, and the day's program on paper.
- **Safety and privacy:** you sit with your student the whole time. Save only to your own USB stick, not to the library computer. Sign in to nothing personal, and log out and close the browser before you leave. See Family safety basics in **The Computing Hour**.
- **The fun:** a change of scene, and proof that your skills travel.
- **The skill:** running a full Computing Hour on a computer that isn't yours, and saving to your own drive.
- **The crumb:** the file, saved in two places once you're home.
**How it goes.** Before you go, check what the library computers allow: some have Python installed, some allow a browser editor, and some allow neither. Run the five steps as usual: plan on paper, predict in the notebook, build and test, debug and log, and save to your USB stick. At home, copy the file to its second place. For a family with no computer at home, this is how the screen half of this book happens.
### Blocked, then mixed
**Blocked practice for the new move.** For a week, every Hour practices the newest idea: a week of variables, then a week of decisions, then a week of loops.
**Mixed practice.** Once loops arrive, mix. A good Hour might hold a Predict the Print with a decision in it, a short trace table, and fifteen minutes on the game. Mixing teaches your student to recognize which tool a problem needs.
### One incorrect example to diagnose
Here is an illustration, not a real family. A thirteen-year-old's folder holds `game.py`, `game2.py`, `final.py`, `final_final.py`, and `final_final2.py`. The version that worked last Tuesday is in one of them. Nobody knows which.
**Diagnosis.** No date in the names, no way to tell what changed, and nothing saved in a second place.
**Rescue.** Date first, then a short description, then a version number: `2026-10-19-guess-game-v2.py`. One line in the Debug Log says what changed. Every save goes to two places.
## For the student
You've probably made things with blocks. Now you're going to type.
Python is a real programming language, used by people who build websites, run science experiments, and make games. It reads a lot like English. But typing code is fussier than snapping blocks together, and the computer is completely literal about it. Here's what you need to know.
**Capitals matter.** `print` works. `Print` doesn't. To Python, they're two different words, and it only knows one of them. If you type `Print("hi")`, you'll get an error that says `name 'Print' is not defined`. Python is telling you it's never heard of `Print`. Recent versions even suggest the fix.
**Brackets come in pairs.** Every `(` needs a `)`. Every opening quotation mark needs a closing one. When one is missing, Python stops and tells you which line the problem is on.
**Indentation means something.** In Scratch, the C-shaped blocks showed which steps were inside a loop. In Python, the indentation does that job. Lines that belong inside a loop or an `if` start four spaces in. Forget them, and you'll see an `IndentationError` whose message starts `expected an indented block`.
**A tiny example.** Read this, and predict exactly what it prints before you read on:
```python
lives = 3
for turn in range(2):
lives = lives - 1
print("Lives left:", lives)
```
It prints `Lives left: 1`. The loop runs twice, and each time it takes one away. If you predicted 0, check `range(2)`: it runs two times, not three. If you predicted the message would print twice, look at the indentation: `print` isn't indented, so it's outside the loop and runs once, at the end.
**Red text is information, not judgment.** Everyone who programs sees error messages every day. Here's how to read one. Look at the last line first; it says what kind of problem it is. Then find the line number. Go to that line, and also check the line just above it, because sometimes the real mistake is a little earlier. Change one thing. Run it again.
**Reading the docs.** Python has official documentation that explains every built-in function. When you meet a new one, look it up and read just the first sentence or two. For `input()`, the docs say it reads a line and returns it as a string, which means text. That one sentence explains why you need `int()` to do math with what someone types. You don't have to understand the whole page. Looking things up is what programmers do.
**This part is hard for everyone.** The first weeks of typing code are slow and full of small errors. Missing colons, missing brackets, a capital where it shouldn't be. Every programmer has been there, and the errors get rarer surprisingly fast.
**Help I used.** From now on, at the end of every Hour, you'll say (or write, if you're 13 or older) what help you used: a book, the docs, a parent, a sibling, a tutorial. "None" is a fine answer when it's true. Saying it every time is how you keep your work honestly yours.
**Try this today.** Write a program that asks someone's favorite animal and then prints a sentence using it. Predict what it'll print before you run it. Then break it on purpose: delete a bracket, run it, and read the error. Fix it.
**Explain it back.** Show someone your program and explain each line in your own words. If there's a line you can't explain, that's the line to look at next.
**If you're 13 or older:** look up one function you haven't used yet in the Python documentation, such as `len()` or `round()`. Read the first sentence, predict what it does in a small program, and test it.
**Challenge.** Change the guess-the-number game so it tells you how many guesses you took. Predict where in the program the counting line has to go before you try it.
**Save like someone will need to find it.** Name every file with the date first, then a few words, then a version number: `2026-10-19-guess-game-v2.py`. When you're about to make a big change, save a copy as the next version first. Then if the change goes badly, the version that worked is still there, and you can compare the two to find exactly what broke. A file called `final_final2.py` helps nobody, including you next month.
**What to save.** Every program, with a date-first name, in two places. Your Debug Log entries. Your version 1 and version 2 of the game.
## If it isn't clicking
**Typing is slow and painful.** That's normal for the first month. Do five-minute typing warm-ups on other days, and keep programs short, under ten lines. Typing speeds up faster than you'd think.
**Indentation errors keep coming.** Count the spaces with your finger: four per level. If your editor can show spaces as dots, turn that on. Read the line above the error; it often ends in a colon that wants indented lines below it.
**"I liked Scratch better."** Keep a Scratch project going alongside Python, for fun. Blocks aren't the enemy. Do one more Scratch Side-by-Side so the connection stays visible.
**Racing ahead and skipping Predict.** No run without a written prediction line. Hands on the table until it's there. The prediction is the part that builds understanding; the run just checks it.
**Error messages cause panic.** Read the last line aloud yourself, calmly. Then ask only, "What line number does it name?" That's the whole first job.
**Your student is far ahead.** Let them read the docs for a new function and teach it to you. Your role is the same: ask for the prediction, be the first user, and ask for the explanation.
## Tools, including AI
**Thonny** is the home default: free, with Python built in, no account, and offline once installed.^[2](#note-2)^
**Raspberry Pi Code Editor** runs Python in a web browser and can be used without creating an account. Saving projects online needs an account, and for creators under 13, a parent or guardian sets it up with their own email address. These rules have been changing, so check the current terms before you start.^[35](#note-35)^ It's a good choice for a library computer or a borrowed laptop.
**CodeAI (formerly Code.org) Python Lab** runs Python in the browser and is designed for students aged 13 and up.^[36](#note-36)^ Use it at 13–14 only, with you present.
**Not Trinket.** It shut down on 31 August 2026, and older guides still point to it.^[37](#note-37)^
**No Replit or GitHub accounts at 11–12.** Both require users to be at least 13, and Replit asks for a parent's permission under 18.^[38](#note-38),[39](#note-39)^ Neither is needed for this chapter.
**AI: none in this chapter, at either age.** At 11–12, there are no coding assistants or AI tutors anyway. At 13–14, keep the first text weeks AI-free too, so your student builds the reading muscle that everything else depends on: reading a line, predicting it, and reading the error. AI tools come back, supervised, in later chapters. The AS checks below are always AI-free. For the rules at each age, see the AI box in **The Computing Hour**.
## What "done enough" looks like
Your student is ready to move on when they can:
- write and run a program that asks a question, stores the answer, decides with `if`/`elif`/`else`, and repeats with a loop;
- predict the output of a short program before running it;
- read an error message's last line and find the line it names;
- save files with date-first names a stranger could read, in two places;
- say "Help I used: …" at the end of every Hour without being asked.
**11–12:** programs of five to ten lines; reading code aloud together is fine. **13–14:** a `while` loop and random numbers; reads the documentation for one new function alone; the guess-the-number game with a counter and replay.
**The checks (always AI-free).** Keep the monthly Cold Trace (AS-01), now with a short Python program. Add a Debug on the Spot (AS-02): plant one bug, such as a missing `int()` or a capital `Print`, and have your student fix it while explaining aloud. Then an Explain Your Code (AS-03): your student explains their own game, line by line, to you. If they can explain every line, it's theirs. Write a one-line note on each, dated, for the portfolio.
If most of the list is in place, move on to Chapter 3, where debugging becomes a discipline of its own.
\newpage
# Chapter 3
## Debugging as a Discipline: Errors, Tests, and the Debug Log
{width=100%}
## Why this matters
Here is an illustration, not a real family. Picture a twelve-year-old who has spent forty minutes on a guessing game. She presses Run. The screen fills with red text. She pushes her chair back, says "It's broken," and reaches for the key that deletes everything. This is one of the most important moments in learning to program, and it looks like failure. It isn't. It's the start of the real work.
A bug is a mistake in the instructions. Debugging is finding and fixing it. Every program bigger than a few lines has bugs on the way to working, and professionals plan for that. Two experienced programmers put it plainly in a well-known book for working developers: no one writes perfect software, so debugging will take up a big part of the day.^[40](#note-40)^ That isn't a confession. It's a job description.
This chapter is the middle of the book's focus line: **Predict before you run; debug before you rewrite; explain it before you call it yours.** Chapter 2 taught your student to predict what a line will do. This chapter teaches what to do when the prediction and the screen disagree. The national computer science standards for ages 11–14 describe the same skill in plain words: use systematic ways to test a program, improve it, and write down the changes.^[17](#note-17)^ "Systematic" is the key word. Debugging is a method, not a mood.
The word has a story your student will enjoy. People called small faults in machines "bugs" long before computers; Thomas Edison talked about bugs in electrical circuits in the 1870s. In 1947, engineers working on the Mark II computer at Harvard found a moth stuck in one of its parts, taped it into their logbook, and labeled it "first actual case of bug being found." The Smithsonian, which now holds that logbook, says it was probably not Grace Hopper's own, but she and the rest of the team helped make "bug" and "debug" ordinary words.^[41](#note-41)^ The engineers did something worth copying: they wrote it down. By the end of this chapter, your student will keep a Debug Log of their own: a dated notebook (paper or a plain file) that holds predictions, bugs, clues, and fixes.
This chapter also carries the feelings that come with mistakes. Students this age care a great deal about how they look to others, and red text can feel like a grade on them rather than a note about the code.^[19](#note-19)^ You can change that. The way you react to the first error message of the week teaches more than anything on this page.
## For the parent: understand it yourself
You don't need to be a programmer to teach debugging. You need a calm voice, a few good questions, and the habit of looking at the code instead of the clock.
**The everyday picture.** A cake comes out flat. You don't throw away the kitchen. You ask what you expected (a tall cake), what happened (a flat one), and what the best clue is (the baking powder tin is still sealed). Then you change one thing next time. Debugging is that, written down.
**The precise picture.** Python can go wrong in three ways, and it helps to name them:
- A **syntax error** means the computer can't read it. A colon or a parenthesis is missing, so Python stops before running anything.
- A **runtime error** means it crashes while running. The program starts, reaches a line it can't carry out, and stops with a message.
- A **logic error** means it runs and does the wrong thing. No red text at all. The answer is simply wrong.
Here is a two-line program with a syntax error:
```python
score = 0
if score > 10
print("Big score")
```
Python stops and reports `SyntaxError: expected ':'`, with a small arrow under the end of line 2. Add the colon and it runs.
Here is a runtime error:
```python
score = 5
print("Score: " + score)
```
The program starts and then stops on line 2 with `TypeError: can only concatenate str (not "int") to str`. In plain words: you tried to glue words to a number. Writing `str(score)` turns the number into text, and the line works.
And here is a logic error:
```python
average = 3 + 6 + 9 / 3
print(average)
```
It prints `12.0`. The student expected `6.0`. Python did the division first, the way math rules say it should, so only the 9 was divided. Parentheses fix it: `(3 + 6 + 9) / 3` prints `6.0`. Nothing turned red. Only a prediction caught it, which is why the book keeps asking for one.
**How to read the red text.** The Python documentation gives the two habits that matter most. The last line of an error message says what happened. The message also names the line where Python noticed the problem, but that is not always the place that needs fixing; a missing parenthesis on line 4 can be reported on line 5.^[42](#note-42)^ So the order is: read the last line first, then the line number, then look at that line and the one above it. Error wording can differ slightly between Python versions. Thonny, the free beginner's editor this book uses, comes with its own recent Python, so your screen may not match these examples word for word.^[2](#note-2)^
**The method.** Professional debugging comes down to a short loop, and your student can learn every step:
1. Write the Expected/Actual line: "I expected… It did…"
2. Read the clue: the error message, or the wrong output.
3. Make one guess about the cause.
4. Change one thing.
5. Run it again and look.
6. Write it in the Debug Log.
The "one thing" matters. The same developers' book notes that if you changed only one thing and the program stopped working, that one thing is probably responsible.^[40](#note-40)^ Change five things and you learn nothing, even if it starts working.
**Tests before trouble.** A test table lists inputs and the outputs you expect before you run anything. The best rows are the awkward ones: zero, a negative number, an empty answer, a very large number. Programmers call these edge cases, and the developers' book advises testing boundary conditions hard.^[40](#note-40)^ A program that works for 5 and breaks for 0 isn't finished.
**Tools for seeing inside.** Two help most. A *print detective* adds temporary `print()` lines that show what a variable holds at each step, then deletes them when the bug is found. Thonny also has a step-through debugger. Press Ctrl+F5 instead of F5 and the program runs one step at a time; F6 takes a big step and F7 a small one. Choosing View, then Variables, shows every labeled box and its contents as the program runs.^[2](#note-2)^
**The rubber duck.** Many programmers explain their code, line by line, out loud, to a rubber duck. This is a habit from working practice, not a research finding. The developers' book tells of a colleague who kept a small rubber duck on his computer while he coded, and says that the simple act of explaining what the code is supposed to do "often causes the problem to leap off the screen and announce itself." If no person is around, they add, "a rubber duck, or teddy bear, or potted plant will do."^[40](#note-40)^ It works because saying each step forces you to notice the step you skipped.
**Saving versions.** A student who saves `2026-10-19-guess-game-v1.py`, then `2026-10-20-guess-game-v2.py`, then `v3`, date first, with one line in a changelog for each and every file saved in two places, can always go back. Nobody has to fear trying a change.
**The feelings.** Expect some perfectionism, some "I'm bad at this," and at least one slammed laptop lid. Keep your feedback about the code: "Line 7 is missing something," not "You always forget." Praise the find, not only the fix: "You spotted that the arrow was one line late. That's real debugging."
### Wrong answers you should be able to hear
- **"The computer is broken."** It almost never is. Reply: "Maybe. What did you expect, and what did it do?" The computer did exactly what it was told. That's the problem, and also the good news.
- **"I'll just start over."** A fresh file throws away the clue along with the bug. Reply: "Deleting the file is not a strategy. Let's read the last line of the message first."
- **"It works, so it's right."** It worked for one input. Reply: "What happens with zero? With a negative number? Let's write three tests."
- **"I fixed it."** But the student can't say what changed. Reply: "Great. Which line, and why did that fix it? Put it in the log."
- **"Python is stupid."** Frustration talking. Reply: "It's very literal. Let's find the line where it stopped doing what you meant."
### Your five-minute warm-up
Tomorrow, before the student arrives, type the three short programs above into Thonny and run each one. Read the last line of each message aloud. Then practice this chapter's opening question once, out loud, and practice saying nothing afterward while you count to five in your head. That's the whole preparation.
## How to teach it this week
Run the week on the usual five steps of the Computing Hour. Here is how each step leans toward debugging.
- **Unplug and Plan (5–10 minutes).** On paper, write the Expected/Actual line format and the Debug Log headings: date, prediction, bug, clue, fix, what I learned.
- **Predict (2–5 minutes).** Before running, the student says what will appear on screen, including "it will crash on line 3" if they suspect it.
- **Build and Test.** The student runs the program, compares it with the prediction, and fills in a test table.
- **Debug and Log.** One bug, one guess, one change, one log line.
- **Save and Explain.** The student saves a new version and says: "I predicted… It did… Next I'd change…" and "Help I used: …" (even if it's "none").
### In-home — BUG-01 Expected/Actual Line
- **Time:** 5 minutes, every time something goes wrong.
- **Materials:** the Debug Log (a notebook or a single document) and a pencil.
- **Safety and privacy:** none needed.
- **The fun:** it turns "ugh" into a sentence, which calms everyone down.
- **The skill:** writing what you expected and what happened before touching the code.
- **The crumb:** one Debug Log line.
Try this exact sentence the first time the screen surprises your student: "Before you change anything, finish this: 'I expected… It did…'" Write it on a card and prop it against the screen for the first two weeks. The rule is simple: no keyboard until the line is written.
**11–12:** You can write it while they say it. **13–14:** They write it themselves, and you only check that it exists.
### In-home — BUG-02 Read the Red Text
- **Time:** 15 minutes.
- **Materials:** Thonny, the three error programs from the parent section, and an index card.
- **Safety and privacy:** offline; nothing to sign up for.
- **The fun:** decoding the message like a spy reading a note.
- **The skill:** finding the error type and the line number, and knowing which kind of error it is.
- **The crumb:** an error decoder card.
Run each broken program. For each one, the student copies the last line onto the card and writes a plain translation beside it. Add a fourth: the `IndentationError` that appears when the line under an `if` isn't pushed in. (Python 3.13 reports `expected an indented block after 'if' statement on line 2`; other versions word it slightly differently.) Add a fifth: misspell `score` as `scroe` and get a `NameError`. Recent versions even suggest `Did you mean: 'score'?` A finished card might read:
- `SyntaxError` = it can't read this line. Look for a missing colon, parenthesis, or quote.
- `IndentationError` = the spacing is wrong. Lines inside an `if` or loop move in four spaces.
- `NameError` = I used a name Python doesn't know. Check spelling and capitals.
- `TypeError` = I mixed things that don't mix, like words and numbers.
Thonny highlights unclosed quotes and parentheses, which it calls the most common beginner syntax errors.^[2](#note-2)^ Point that out; it's a free clue.
### In-home — BUG-08 The Debug Log
- **Time:** 5 minutes at the end of each Hour.
- **Materials:** a dated notebook (paper or a plain file) that holds predictions, bugs, clues, and fixes, kept beside the computer or in the student's project folder.
- **Safety and privacy:** first names only if it's ever shown to anyone.
- **The fun:** watching the list grow is satisfying, and old entries are funny a month later.
- **The skill:** writing down the bug, the clue, the fix, and what was learned, with the date.
- **The crumb:** the monthly log page.
A good entry is short:
> 6 Oct. Bug: game said "Too high" when I was too low. Clue: both messages said "Too high." Fix: line 11 now says "Too low." Learned: copy-paste can copy the mistake too.
Tell your student, more than once, that a full Debug Log is evidence of good work. A blank one usually means the bugs got fixed in silence, or not at all.
### How to fade your help
Follow the rescue order: **ask → wait → hint → short demo on your own copy → hand it back.** Ask the opening question. Wait. If silence goes on, give a hint that points to a place, not an answer: "Look at line 7 and the line above it." If that fails, fix a *similar* bug in your own copy while they watch, then hand the keyboard back. The student's file stays the student's.
**11–12:** Expect to reach "hint" often in the first week. Co-write test tables together. Plant two bugs, not three, for the planted-bug game.
**13–14:** The student leads the Hour and you are **first user**: you try the program like a stranger, report what happened, and fix nothing. Plant three bugs, including one logic bug. Then swap: the student plants bugs for you.
**Ready 12:** A twelve-year-old who reads error messages without being asked is ready for the logic-bug round.
### A worked Hour (illustration)
Here is an illustration, not a real family. Picture a thirteen-year-old and his father on a Wednesday. In Unplug and Plan, the son copies the Debug Log headings into his notebook. In Predict, his father points to a guessing game the son wrote last week and asks, "What will happen when you type 5?" The son says, "Too low or too high, then another guess." He runs it. It crashes on line 10 with `TypeError: '<' not supported between instances of 'str' and 'int'`.
His father asks the opening question and counts to five in his head. The son reads the last line twice. "It says I'm comparing a string and a number. The guess is a string." He remembers from Chapter 2 that `input()` always gives text. He changes one thing: `guess = int(input("Guess 1 to 10: "))`. He runs it. It works. He writes the log entry, saves `2026-10-21-guess-game-v2.py`, and says, "I predicted it would say too low or too high. It crashed. Next I'd change the message so it tells you how many tries are left. Help I used: none." Twenty minutes, one bug, one clear win.
## Practice that actually builds learning
### In-home — BUG-03 Planted Bugs
- **Time:** 20 minutes.
- **Materials:** a working program saved under a new name, Thonny, and a sheet for the bug list.
- **Safety and privacy:** offline.
- **The fun:** a treasure hunt where you made the treasure.
- **The skill:** finding three bugs a parent planted in working code.
- **The crumb:** a bug list with line numbers.
Start from a program that works. You plant the bugs in a copy. (At 13–14, the student plants some for you, too.) Here is a guessing game with three planted bugs:
```python
import random
secret = random.randint(1, 10)
guess = 0
tries = 0
while guess != secret
guess = int(input("Guess 1 to 10: "))
tries = tries + 1
if guess < secret:
print("Too high")
elif guess > secret:
print("Too high")
print("Got it in", trys, "tries")
```
Python first stops at line 7 with `SyntaxError: expected ':'`. Fix that and the game runs, but it says "Too high" for a low guess (line 11, a logic bug). When the player finally guesses right, it crashes on line 15 with `NameError: name 'trys' is not defined`. One bug of each kind. The student writes each one on the list: line, kind, fix.
**11–12:** Plant two bugs, one syntax and one runtime. Tell them how many there are. **13–14:** Plant three, including a logic bug, and don't say which line. Then the student plants bugs in a working program for you, and you narrate your hunt. Watching a parent read an error message calmly is a lesson in itself.
### In-home — BUG-04 Rubber Duck Explain
- **Time:** 10 minutes.
- **Materials:** a rubber duck, a stuffed animal, or a houseplant, plus the stuck program.
- **Safety and privacy:** none needed.
- **The fun:** it's silly, and it works anyway.
- **The skill:** explaining code line by line out loud.
- **The crumb:** one sentence: the line where I found it.
Say once, plainly, that this is a working programmer's habit, not a classroom game. The student reads each line to the duck and says what it does: "Line 9 adds one to tries. Line 10 checks if the guess is too small…" The rule is every line, no skipping the "obvious" ones, because the bug usually lives in an obvious one. Your job is to leave the room or stay silent.
### In-home — BUG-05 One Change at a Time
- **Time:** 15 minutes.
- **Materials:** a buggy program and a change log (three columns: change, result, keep or undo).
- **Safety and privacy:** offline.
- **The fun:** a controlled experiment, like a science lab.
- **The skill:** change one thing, run it again, write it down.
- **The crumb:** the change log.
Give the student a program with one stubborn logic bug. The rule is one edit per run, logged. If a change doesn't help, undo it before trying the next. Students who change five things at once sometimes get lucky, but they can't explain why it works, and the next bug beats them.
### In-home — BUG-06 Test Table First
- **Time:** 20 minutes.
- **Materials:** paper, a pencil, and the program about to be written.
- **Safety and privacy:** none needed.
- **The fun:** trying to break your own program before anyone else can.
- **The skill:** writing inputs and expected outputs before coding, including edge cases (zero, negative, empty, very large).
- **The crumb:** a test table with pass/fail marks.
Before writing a small program that gives a reaction to a score, the student fills in a table:
| Input | Expected | Actual | Pass? |
|---|---|---|---|
| 12 | Big score | | |
| 10 | Keep going | | |
| 0 | Keep going | | |
| -3 | That can't be right | | |
| (nothing typed) | Asks again | | |
The row for 10 is the interesting one: is 10 a big score or not? Writing the table forces the decision before the code hides it. **11–12:** Write the table together. **13–14:** The student writes it alone, with at least two edge cases you didn't suggest.
### In-home — BUG-07 Print Detective
- **Time:** 15 minutes.
- **Materials:** Thonny and a program that gives a wrong number.
- **Safety and privacy:** offline.
- **The fun:** spying on your own variables.
- **The skill:** adding temporary `print()` lines to watch values change.
- **The crumb:** a before/after snippet.
This program is meant to add 1 + 2 + 3 + 4 + 5:
```python
total = 0
for number in range(1, 5):
print("number is", number, "total is", total)
total = total + number
print(total)
```
The student expected 15. It prints 10. The detective line (line 3) shows `number` going 1, 2, 3, 4 and then stopping. The clue is in plain sight: `range(1, 5)` stops before 5. Changing it to `range(1, 6)` prints 15. Then the detective line comes out. Save the before and after.
Show the same bug with Thonny's step-through (Ctrl+F5, then F7 for small steps, with View, then Variables, open). Some students like the printed trail; others like watching the boxes change. Both are real tools.
### In-home — PROJ-02 Version Saves and Changelog
- **Time:** 10 minutes.
- **Materials:** the project folder and a plain text file called `changelog.txt`.
- **Safety and privacy:** save in two places (see Family safety basics in **The Computing Hour**).
- **The fun:** a time machine for code.
- **The skill:** saving v1, v2, v3 with a one-line changelog.
- **The crumb:** the changelog file.
Before any big change, the student saves a copy with today's date first and the next version number, like `2026-10-20-guess-game-v2.py`, and writes one line in the changelog: `2026-10-20 v2: guess is now a number; fixed crash on line 10.` If v3 goes badly, v2 is waiting. Both live in two places.
### In-home — PY-08 Guess-the-Number Game
- **Time:** 40 minutes over two Hours.
- **Materials:** Thonny and the guessing game from Chapter 2.
- **Safety and privacy:** offline.
- **The fun:** a game the family will actually play.
- **The skill:** a `while` loop, random numbers, and `if` checks, now debugged and improved.
- **The crumb:** version 1 and version 2 files.
Use the game as this week's lab. The student makes one improvement per version (a tries counter, a limit of five guesses, a "play again?" question) and logs every bug met along the way. The family plays as **first user**, one at a time. Siblings are excellent at typing "banana" when asked for a number, which is a test case worth having.
### In-home — AS-02 Debug on the Spot
- **Time:** 15 minutes, about once a month.
- **Materials:** a short program with one planted bug the student hasn't seen.
- **Safety and privacy:** offline; no AI, no notes beyond the error decoder card.
- **The fun:** a calm show of skill.
- **The skill:** fixing a planted bug while explaining aloud.
- **The crumb:** your one-line note.
The student reads the program aloud, predicts, runs it, and fixes the bug while saying what they're doing. You write one line: "Found the missing colon in under two minutes; read the last line first without being asked." This check is always AI-free.
### Out-of-home — OUT-01 Algorithms in the Wild
- **Time:** 20 minutes on a walk or an errand.
- **Materials:** a pocket notebook.
- **Safety and privacy:** road rules; stay together in stores and parking lots; no photos of strangers or staff.
- **The fun:** catching machines making mistakes.
- **The skill:** writing pseudocode (a plan for a program written in plain words) for a machine you meet, then finding its bug.
- **The crumb:** a pseudocode page with the bug circled.
This week the walk becomes a "bug in the world" hunt. Look for systems that follow rules and sometimes get them wrong: a self-checkout that says "unexpected item" when nothing is there, a crosswalk button that seems to do nothing, an automatic door that opens for a passing leaf. The student writes the likely rule ("IF something moves near the sensor THEN open") and then the Expected/Actual line for the mistake. At home, they suggest one change to the rule. Keep it about machines, not people, and keep guesses labeled as guesses.
### Talk box (this chapter)
**Opening:** "What did you expect, what happened instead, and what's your best clue?"
**Follow-ups:**
- Prediction: "If you make that change, what do you think it will do?"
- Evidence: "What did you see that makes you say that?"
- Location: "Which line is the last one that did what you expected?"
- Change: "What's the one thing you'd change first?"
- Revision: "You can change your prediction. Run it again and see."
**How to wait.** After asking, count to five in your head. When the question is about code on the screen, let them read as long as they need. Look at the code, not at the student. That simple shift tells them you're both working on the program, not watching them.^[5](#note-5)^
**What a stuck silence usually means.** The question was too vague ("What's wrong?"), so make it smaller: "Read me the last line of the message." There may have been no wait time. They may fear looking foolish, which is strong at this age, so keep every comment about the code. They may be waiting for you to fix it, because you have before. There may have been no prediction, so nothing to compare. Or the screen is louder than the question; lower the lid for a moment and talk on paper.
**Don't say / say instead.** Don't say "That's wrong." Say "Show me the line where it stops doing what you expected."
### Blocked, then mixed
For the first week, practice one error type at a time: a day of syntax errors, a day of runtime errors, a day of logic bugs. Blocked practice builds the decoder card. In the second week, mix them. Hand over three programs without saying which kind of error each has. Naming the kind is half the skill, and only mixed practice teaches it.
### One incorrect example to diagnose
Here is an illustration, not a real family. Show your student this folder, from an imaginary student:
`game.py`, `game2.py`, `game_final.py`, `game_final_final2.py`, `game_NEW.py`
Ask: "Which one works? Which one has the fix for the crash? What would you do differently?" Let them find the problem (no way to tell what changed, or which is newest) and propose the fix: numbered versions and a changelog line for each. Students who laugh at this folder rarely build one.
### Siblings and co-ops
Planted bugs work beautifully across ages. An older sibling plants, a younger one hunts, and the planter must explain each bug afterward. In a co-op, pairs swap programs and fill in each other's test tables. The rule for everyone: talk about the code, not the coder.
## For the student
Here's something true: every programmer you have ever heard of has seen thousands of red error messages. They didn't get good by avoiding errors. They got good at reading them.
A bug is a mistake in the instructions. Debugging is finding and fixing it. Bugs come in three kinds:
- A **syntax error** means Python can't read your code. It stops before running anything. Usually a missing colon, parenthesis, or quote.
- A **runtime error** means the program starts, then crashes on a line it can't do.
- A **logic error** means the program runs fine and gives the wrong answer. These are the sneaky ones, because nothing turns red.
**How to read red text.** Start at the bottom. The last line names the error and says what happened. Then find the line number. Look at that line, and the line above it, because Python sometimes notices a mistake one line late.
Here's a worked example. You run this:
```python
score = 5
print("Score: " + score)
```
The last line of the message says `TypeError: can only concatenate str (not "int") to str`. Translate it: "You tried to stick words and a number together." Line 2 is where it happened. Your guess: the number needs to become text. Change one thing: `print("Score: " + str(score))`. Run it. It prints `Score: 5`. Write it in your Debug Log:
> Date. Bug: crash on line 2. Clue: TypeError, words plus number. Fix: str(score). Learned: + only joins text to text.
That's the whole method: **Expected/Actual, clue, guess, one change, run, log.**
**One change at a time.** When something's wrong, it's tempting to change five things at once. If it starts working, you won't know which change did it. If it gets worse, you won't know which change broke it. One change, one run, every time.
**Test your program before someone else does.** Before you write a program, write a test table: some inputs and what you expect. Include the awkward ones. What if someone types 0? A negative number? Nothing at all? A huge number? Programs usually work for the easy cases. The edges are where bugs live.
**Spy on your variables.** If a number comes out wrong, add a temporary line like `print("total is", total)` inside your loop and watch it change. Or press Ctrl+F5 in Thonny and step through one line at a time with F7. Delete the spy lines when you're done.
**Talk to the duck.** Explain your code out loud, line by line, to a rubber duck or a stuffed animal. Professional programmers really do this. Saying every step forces you to notice the one you skipped.
**Keep the log.** A Debug Log is a dated notebook (paper or a plain file) that holds predictions, bugs, clues, and fixes. Add one line on what you learned. It takes two minutes. Months from now, you'll flip back and see bugs that once took you an hour and now take you ten seconds. That's what getting better looks like from the inside.
### Try this today
Ask your parent to plant two bugs in a program that already works. Find them. For each one, write the line number, the kind of error, and your fix.
### Explain it back
Tell your parent, without looking at this page, the difference between a syntax error and a logic error. Then give an example of each from your own code.
### This part is hard for everyone
Logic errors are hard. There's no message to read, only an answer that's wrong, and your brain keeps reading what you *meant* instead of what you *wrote*. That isn't a sign you're bad at this. It's why programmers use test tables, print lines, and ducks.
**The ten-minute rule.** If you've been stuck for ten minutes: stand up. Explain it to the duck. Write the Expected/Actual line. *Then* ask for help. And one more thing: deleting the file is not a strategy. The clue is in there.
### Challenge
Write a short program that works. Save a copy. Plant three bugs in the copy: one syntax, one runtime, and one logic. Give it to your parent and watch them hunt. You'll learn a surprising amount about bugs by hiding them well.
**If you're 13 or older:** make your logic bug an off-by-one, like `range(1, 5)` where you meant 1 to 5. Then write a test table that would catch it.
### What to save
- Your error decoder card.
- Your Debug Log, dated.
- Your test table with pass/fail marks.
- Each version of your program, named date first (like `2026-10-19-guess-game-v2.py`), and your changelog.
Every entry in that log is proof you solved something. Keep it in two places.
## If it isn't clicking
**They change five things at once.** Slow down to BUG-05. Sit beside them with the change log and say "one" out loud before each run. After a week it becomes habit.
**They won't read the error messages.** Many students glance at red text and look away, as if it were shouting. Go back to the error decoder card. Cover everything except the last line with an index card, and ask only, "What does this line say, in your words?"
**Frustration takes over.** The ten-minute rule exists for this. Stand up, take a short walk around the house, and come back to paper. If a lid gets slammed, stay calm and keep it about the code: "That bug is being stubborn. Let's write down what we know before we look again." End the Hour early if you need to, on a small win.
**They blame the computer.** "It's broken" usually means "I don't know where to look." Hand them a location question: "Which line is the last one that did what you expected?" Then follow the rescue order: ask → wait → hint → short demo on your own copy → hand it back.
If two weeks pass and every bug still needs you, step back to paper. Trace a five-line program by hand, writing each variable's value as it changes. Debugging on screen gets easier once tracing on paper feels natural.
## Tools, including AI
**Thonny**, a free Python editor that works offline, is the main tool here. It highlights unclosed quotes and parentheses, and its step-through debugger and Variables view (described above) show what the program is really doing.^[2](#note-2)^ Nothing else is required. A rubber duck helps.
**AI and error messages.** For the rules, see the AI box in **The Computing Hour**. Here is what's different for debugging. The student's own Expected/Actual line and best guess always come first.
**11–12:** Rarely, after your student has written Expected/Actual and a guess, you may ask a chatbot on your own account to explain an error message and read the explanation aloud. Then check it against the code together. The AI explains; the student fixes.
**13–14:** Under the service's terms, with you nearby and the screen visible, your student may ask an AI to *explain* an error message, never to fix the code. Add a line to the Debug Log: "Help I used: asked AI what `IndentationError` means after my guess."
A preview of something that comes up again in Chapter 8: for 13–14, any code an AI suggests goes through **AI-07 Explain Every Line**. The student explains every line before deciding whether to use any of it, and anything kept goes on a Whose Work card as made by a tool. Debugging is also a good honesty check. A student who can find and fix a bug in their own program wrote that program. AS checks like Debug on the Spot are always AI-free.
Services change their rules often, so check the current terms before anyone uses one.
## What "done enough" looks like
Your student has met this chapter's goals when they can:
- name the three kinds of error and give an example of each;
- read an error message from the last line, then the line number, without being reminded;
- find a planted bug while explaining aloud (AS-02 Debug on the Spot);
- show a dated Debug Log with real entries, including what they learned;
- write a test table, with edge cases, before writing a small program;
- save numbered versions with a changelog.
**Placement by skill.** A twelve-year-old who reads errors calmly and finds logic bugs is ready for the 13–14 moves. A fourteen-year-old who still deletes files when stuck needs more weeks of BUG-01 and BUG-05, and that's fine.
**The life of the habit.** The Debug Log doesn't end with this chapter. Every program from here on gets Expected/Actual lines and log entries. Once a month, read back through the log together. Your student will see bugs they once found hard and now spot in seconds. That's the best kind of progress report, and they wrote it themselves.
\newpage
# Chapter 4
## Functions, Lists, and Data: Bigger Programs and Spreadsheets That Answer Questions
{width=100%}
## Why this matters
By now your student can write a program of ten or twenty lines. Somewhere around thirty lines, something changes. The same five lines show up three times. A program needs to remember twelve quiz questions, not one. A question comes up that a single number can't answer. This chapter gives your student the three tools that carry programs past that point: functions, lists, and data.
A **function** is a named chunk of code you can use again. A **list** is items in order, numbered from 0. **Data** is information collected to answer a question. Together they let a student build a quiz game the family will actually play, keep a packing list that updates itself, and turn two weeks of bird-feeder tallies into a chart that tells the truth.
The national computer science standards for ages 11–14 name these skills directly: use a procedure (a function) to organize code for clarity and reuse; use variables to store and change data; and use a computing tool to sort, filter, group, and summarize data. The same standards ask students to see how design choices in a chart change what people conclude, and how decisions about collecting data can lead to misleading results.^[17](#note-17)^ That last part matters as much as the code. A student who can ask "Who's missing from this data?" is learning something many adults never do.
There's a satisfying idea underneath all of this. A spreadsheet formula like `SUM` is a function, with inputs and an output, just like the ones your student will write in Python. Once they see that, a spreadsheet stops being a mysterious office program and becomes another place to compute.
The focus line still holds: predict before you run; debug before you rewrite; explain it before you call it yours. Functions add one question to the Predict step: what goes in, and what comes out?
## For the parent: understand it yourself
### Functions
**The everyday picture.** A recipe card that says "Make the pancake batter" is a function. You write the steps once, give the card a name, and from then on you just say "make the batter." If the card says "for ___ people," that blank is an input.
**The precise picture.** In Python, `def` defines a function. The name in the parentheses is a **parameter**, an input the function needs:
```python
def draw_box(size):
for row in range(size):
print("#" * size)
draw_box(3)
draw_box(5)
```
This prints a 3-by-3 square of `#` marks, then a 5-by-5 square. The four indented lines run only when the function is called. Recall from earlier chapters: a variable is a labeled box whose contents can change, and a loop means do it again. Here `size` is a variable that gets a new value each time the function is called.
**Return versus print.** This is the idea that trips up nearly everyone. `print` shows a value on the screen and then forgets it. `return` hands the value back so the program can keep using it.
```python
def c_to_f_print(c):
print(c * 9 / 5 + 32)
def c_to_f(c):
return c * 9 / 5 + 32
answer = c_to_f_print(100)
print("Saved:", answer)
answer = c_to_f(100)
print("Saved:", answer)
```
The output is `212.0`, then `Saved: None`, then `Saved: 212.0`. The first function showed the answer and kept nothing; Python's word for "nothing" is `None`. The second handed the answer back. A function that returns can be tested: `c_to_f(0)` gives `32.0`, and `c_to_f(-40)` gives `-40.0`, which is a pleasing edge case.
### Lists
**The everyday picture.** A row of numbered cubbies, where the first cubby is number 0.
**The precise picture.** A list holds items in order. The Python documentation describes positions as "zero-based": the first item is at position 0.^[43](#note-43),[44](#note-44)^ You can add to the end with `append`, take out an item with `remove`, count items with `len`, and walk through every item with a `for` loop:
```python
packing_list = ["socks", "toothbrush", "book"]
packing_list.append("flashlight")
packing_list.remove("book")
print(len(packing_list))
for item in packing_list:
print("Pack the", item)
print(packing_list[0])
```
This prints `3`, then three "Pack the…" lines (socks, toothbrush, flashlight), then `socks`. If the student types `packing_list[3]`, Python stops with `IndexError: list index out of range`. Three items live at positions 0, 1, and 2. That off-by-one surprise is worth meeting on purpose.
### Data and spreadsheets
**Question first.** Good data work starts with a question, not a pile of numbers: "Which bird visits our feeder most in the morning?" The question decides what to count, when, and for how long.
**Spreadsheets.** A spreadsheet is a grid. Each row is one observation (one morning, one bird). Each column is one kind of information (date, time, bird, how many). Each box is a cell, named by its column letter and row number, like `B4`. Clean data means one kind of thing per column and the same spelling every time: "sparrow," not "Sparrow" in one row and "sparow" in the next.
**Formulas are functions.** `=SUM(D2:D31)` takes a range of cells as input and returns their total. `AVERAGE`, `MAX`, and `COUNTIF` work the same way. `=COUNTIF(C2:C31, "sparrow")` counts how many cells in column C say "sparrow." Spreadsheet programs differ in small ways (some want a semicolon between the parts instead of a comma), so if a formula won't take, check the program's own help page for its exact form. Any spreadsheet program your family already has will do.
**Sort, filter, group.** Sorting puts rows in order. Filtering hides the rows you don't need right now. Grouping gathers rows that share something (all the cardinals) so you can total each group.
**Charts that tell the truth.** The same numbers can tell different stories. If 41 sparrows and 37 cardinals are drawn as bars on an axis that starts at 35, the sparrow bar is three times as tall as the cardinal bar (6 units against 2). Start the axis at zero and the bars look nearly equal, which is the honest picture. The standards ask students to see exactly this: design choices change how people read the same data.^[17](#note-17)^
**Who's missing?** If you only count birds at 8 a.m., you'll miss the ones that come at dusk. If you only ask your friends, you'll miss everyone who isn't your friend. Every dataset leaves someone or something out. Saying so is part of an honest answer. Chapter 8 returns to this idea when it explains how AI learns from data.
**Data about data.** A phone photo carries more than the picture. Phones and cameras automatically record details about when, where, and how a photo was taken, and that hidden information can travel with the photo when it's shared. Phones let you turn off the camera's access to location.^[45](#note-45)^ This hidden information is called metadata. It makes a good data lesson here, and Chapter 7 covers what it means for privacy. Before anyone shares a photo, see Family safety basics in **The Computing Hour**.
### Wrong answers you should be able to hear
- **"The list starts at 1."** Natural, and wrong in Python. Reply: "Let's test it. Print `packing_list[0]` and see what comes out."
- **"Print and return are the same thing."** They look the same on screen. Reply: "Store the answer in a variable and print the variable. What do you get?"
- **"My chart proves it."** A chart shows; it rarely proves. Reply: "What does the axis start at? Who's missing from the data?"
- **"The average tells you everything."** Reply: "What's the biggest number? The smallest? Would one strange day change the average a lot?"
- **"It works, so I'm done."** Reply: "What does your test table say about zero, a negative number, and an empty list?"
### Your five-minute warm-up
Type the `c_to_f` example into Thonny and run it. Say out loud why the first "Saved" line shows `None`. Then open any spreadsheet, type five numbers in a column, and try `=SUM` and `=AVERAGE` on them. Practice this chapter's opening question once, and then count to five in your head.
## How to teach it this week
This chapter is two or three weeks of work, not one. A good order: functions and lists first, then data, then a small project that uses all three.
Use the Hour's steps as usual:
- **Unplug and Plan.** Function machines on paper; index cards for lists; a question card for data.
- **Predict.** For every function call, the student says what goes in and what will come out. For every list line, which position and which item.
- **Build and Test.** Write the function or list program, run the test table.
- **Debug and Log.** Expected/Actual for every surprise; one Debug Log line.
- **Save and Explain.** "I predicted… It did… Next I'd change…" and "Help I used: …"
### In-home — FN-01 Function Machine
- **Time:** 10 minutes.
- **Materials:** a cardboard box or a drawn box, small slips of paper, rule cards.
- **Safety and privacy:** none needed.
- **The fun:** guessing the secret rule.
- **The skill:** input, rule, output.
- **The crumb:** rule cards.
You hold a secret rule card ("double it and add one"). The student feeds in a number on a slip; you pass back the output. After three or four tries, they guess the rule and test it on a number they haven't tried. Then swap roles. Finish by writing the rule as Python: `def machine(n): return n * 2 + 1`.
### In-home — LIST-01 Index Cards in a Row
- **Time:** 10 minutes.
- **Materials:** index cards, a marker, a table.
- **Safety and privacy:** none needed.
- **The fun:** acting out a program with your hands.
- **The skill:** positions starting at 0; `append` and `remove`.
- **The crumb:** a photo of the row (no faces).
Write a small number above each card position, starting at 0. Lay out three items. Call out commands: "append flashlight" (add to the end), "remove book" (slide the rest left), "what's at position 2?" The student moves cards and answers. The slide-left after a removal is the moment the numbering clicks.
### How to fade your help
Follow the rescue order: **ask → wait → hint → short demo on your own copy → hand it back.** For functions, the best hint is a question about inputs: "What does this function need to know to do its job?"
**11–12:** Start with functions that print and take one parameter. Use one list at a time. In spreadsheets, stick to `SUM` and `AVERAGE` at first.
**13–14:** Add `return` and test tables for every function. Use two lists side by side, or pairs. Add `COUNTIF` and grouping. Write a short investigation that names its limits. The student leads; you're **first user**, trying each program like a stranger and reporting without fixing.
**Ready 12:** A twelve-year-old who explains why the first "Saved" line shows `None` is ready for FN-03.
### A worked Hour (illustration)
Here is an illustration, not a real family. Picture a twelve-year-old and her mother on a Tuesday. In Unplug and Plan, the girl lays out four index cards and numbers them 0 to 3. Her mother asks, "What goes in, what comes out — and how would you test it?" about a list program the girl has sketched. In Predict, the girl says `print(packing_list[3])` will show "flashlight." She runs it: `IndexError`. Her mother waits. The girl looks at her cards. "Oh. I removed the book. There are only three now. The last one's at 2." She changes one thing, runs it, and writes the log line. "I predicted flashlight. It crashed. Next I'd print the length first. Help I used: my cards."
## Practice that actually builds learning
### In-home — FN-02 Define Your Own
- **Time:** 25 minutes.
- **Materials:** Thonny.
- **Safety and privacy:** offline.
- **The fun:** inventing a command Python didn't have.
- **The skill:** `def` with parameters.
- **The crumb:** the program file.
Start with `draw_box(size)` from the parent section, then let the student design their own: `draw_triangle(height)`, or `greet(name, times)`. Students who did turtle drawings in Chapter 2 (PY-07 Turtle Patterns) can write `draw_square(size)` with the turtle and call it at four sizes to make a pattern. Before writing any function, they write the paper version first: name, inputs, what it does.
### In-home — FN-03 Return to Sender
*For 13–14; ready 12.*
- **Time:** 25 minutes.
- **Materials:** Thonny, paper.
- **Safety and privacy:** offline.
- **The fun:** a converter you can trust.
- **The skill:** `return` versus `print`; a unit converter with a test table.
- **The crumb:** the program file plus the test table.
The student writes `c_to_f(c)` and fills in a test table before running it (this is BUG-06 Test Table First, back from Chapter 3): 0 → 32, 100 → 212, -40 → -40, 37 → 98.6. Then they write the opposite converter and check that converting there and back gives the starting number.
### In-home — FN-04 Refactor the Repeats
*For 13–14.*
- **Time:** 25 minutes.
- **Materials:** a program the student wrote earlier with repeated code.
- **Safety and privacy:** offline.
- **The fun:** making a program shorter and better at the same time.
- **The skill:** finding repeated code and replacing it with a function.
- **The crumb:** before and after files.
Look through an old program for lines that appear twice or more with only a small difference. That difference becomes the parameter. The program must give exactly the same output before and after, which is a test in itself. Save both versions.
### In-home — LIST-02 Packing List Program
- **Time:** 25 minutes.
- **Materials:** Thonny.
- **Safety and privacy:** offline.
- **The fun:** a tool for the next family trip.
- **The skill:** `append`, `remove`, `len`, and a loop over a list.
- **The crumb:** the program file.
Start from the packing list example. Add an `input()` loop so the user can type items to add, and "done" to stop. Print the final list with numbers. A good test: what happens if you `remove` something that isn't in the list? (Python raises a `ValueError`.^[43](#note-43),[44](#note-44)^) Can the student make the program check first with `if item in packing_list:`?
### In-home — LIST-03 Quiz Machine
- **Time:** 40 minutes over two Hours.
- **Materials:** Thonny, a friend or family member to take the quiz.
- **Safety and privacy:** offline; quiz-takers' first names only.
- **The fun:** a game other people play.
- **The skill:** two lists side by side, a score variable, and feedback.
- **The crumb:** the program file plus a friend's score.
```python
questions = ["7 x 8?", "Capital of France?", "Bits in a byte?"]
answers = ["56", "paris", "8"]
score = 0
for i in range(len(questions)):
reply = input(questions[i] + " ")
if reply.strip().lower() == answers[i]:
score = score + 1
print("Right!")
else:
print("The answer was", answers[i])
print("Score:", score, "out of", len(questions))
```
If someone answers 56, Paris, and 7, it prints "Right!" twice, then "The answer was 8," then `Score: 2 out of 3`. Ask your student to explain `.strip().lower()`: it tidies spaces and capitals so " Paris" still counts. **11–12:** Five questions on a topic they love. **13–14:** Ten questions, and a message that changes with the score.
### In-home — LIST-04 Find the Biggest
- **Time:** 20 minutes.
- **Materials:** a deck of cards, then Thonny.
- **Safety and privacy:** none needed.
- **The fun:** beating a famous algorithm (exact steps to reach a goal) at its own game.
- **The skill:** the maximum algorithm by hand, then in code.
- **The crumb:** a trace table and the file.
Deal cards face down in a row. The student turns them over one at a time, keeping only the biggest so far in hand. Then the same in code:
```python
temps = [14, 19, 11, 23, 17]
biggest = temps[0]
for t in temps:
if t > biggest:
biggest = t
print(biggest)
```
It prints `23`. Then compare with Python's built-in `max(temps)`, which gives the same answer. This is also a good place to revisit ALG-04 Battleships Search from Chapter 1: finding the biggest in an unsorted list means checking every item, just as a search through unsorted numbers does.^[46](#note-46)^
### In-home — DATA-01 Question First
- **Time:** 15 minutes.
- **Materials:** an index card.
- **Safety and privacy:** pick questions that don't need other people's private information.
- **The fun:** choosing a question you actually care about.
- **The skill:** writing a question and deciding what data would answer it.
- **The crumb:** the question card.
On the card: the question, what to count, where, when, for how long, and one thing that might make the answer wrong. "Which bird visits our feeder most? Count each visit, 8:00–8:15 a.m., for 14 days. Might be wrong because: we're only watching mornings."
### In-home — DATA-02 Spreadsheet Basics
- **Time:** 25 minutes.
- **Materials:** any spreadsheet program the family already has.
- **Safety and privacy:** keep the file on the family drive.
- **The fun:** seeing a messy notebook become a tidy table.
- **The skill:** rows, columns, cells; entering clean data.
- **The crumb:** the sheet file.
Headings in row 1: Date, Time, Bird, Count. One observation per row. Agree on spellings before typing. Then the student finds three "dirty" entries you slipped in (a typo, a capital, a number typed as words) and cleans them.
### In-home — DATA-03 Formulas Are Functions
- **Time:** 20 minutes.
- **Materials:** the sheet.
- **Safety and privacy:** none needed.
- **The fun:** making the spreadsheet do the arithmetic.
- **The skill:** `SUM`, `AVERAGE`, `MAX`, and `COUNTIF` as functions with inputs and outputs.
- **The crumb:** the sheet with formulas shown.
For each formula the student says, before pressing Enter, what goes in (the range) and what will come out. **11–12:** `SUM` and `AVERAGE`. **13–14:** add `MAX` and `COUNTIF`. Most spreadsheets have a setting to show formulas instead of results; turn it on for the saved copy.
### In-home — DATA-04 Sort, Filter, Group
- **Time:** 20 minutes.
- **Materials:** the sheet.
- **Safety and privacy:** none needed.
- **The fun:** asking the data new questions.
- **The skill:** sorting, filtering, grouping, and summarizing.
- **The crumb:** a summary table.
Sort by bird, then by count. Filter to show only one bird. Then build a small summary table: each bird and its total, using `COUNTIF` or the spreadsheet's grouping tool. **13–14:** Compare two groups (weekdays and weekends) and write one sentence about the difference and one about why it might not mean much.
### In-home — DATA-05 A Chart That Tells the Truth
- **Time:** 25 minutes.
- **Materials:** the summary table.
- **Safety and privacy:** none needed.
- **The fun:** making a chart lie, then making it honest.
- **The skill:** choosing a chart; spotting a misleading axis.
- **The crumb:** the chart plus a one-line caption.
Make a bar chart of bird totals. Then change the axis so it starts just below the smallest bar and watch the differences balloon. Change it back to zero. The student writes one honest caption: "Sparrows came most often (41 visits), but cardinals were close (37)."
### In-home — DATA-06 Who Is Missing?
- **Time:** 15 minutes.
- **Materials:** the question card and the data.
- **Safety and privacy:** none needed.
- **The fun:** catching your own blind spot.
- **The skill:** spotting a biased sample: what or who the data leaves out.
- **The crumb:** a two-sentence note.
Ask: "What didn't we count? When weren't we watching? What would change the answer?" The note: "We only watched mornings, so birds that come in the evening are missing. Our answer is about morning visitors, not all visitors."
### Out-of-home — OUT-03 Data Walk
- **Time:** 20 minutes.
- **Materials:** a clipboard, a tally sheet, a pencil.
- **Safety and privacy:** road rules; stay together; count things, not people's faces; no photos of strangers.
- **The fun:** fieldwork.
- **The skill:** counting something outdoors and bringing the data home.
- **The crumb:** the tally sheet.
Pick something countable from a safe spot: cars by color at a corner, dogs on a park loop, kinds of trees on one block. Agree on categories before you start, including "other." At home, the tally goes into the spreadsheet for DATA-02 through DATA-06. The student who owns a micro:bit can log light or temperature instead; see the optional PHYS-02 Sensor Logger in Chapter 6.
### In-home — PROJ-01 Project One-Pager
- **Time:** 20 minutes.
- **Materials:** one sheet of paper.
- **Safety and privacy:** none needed.
- **The fun:** planning something real.
- **The skill:** problem, user, features, test plan, and schedule on one page.
- **The crumb:** the one-pager.
Before a bigger project (the quiz machine with ten questions, or a bird report with a chart), the student writes one page: what problem it solves, who will use it, three features, how it will be tested, and what gets done in which Hour. PLAN-07 Paper Parsons, from Chapter 1, makes a good warm-up: cut a finished function into strips, mix them up, and put them back in order.
### Talk box (this chapter)
**Opening:** "What goes in, what comes out — and how would you test it?"
**Follow-ups:**
- Prediction: "If you call it with 0, what will it give back?"
- Evidence: "What in the output makes you say it's working?"
- Location: "Which position in the list is the last one that's right?"
- Change: "What's the one thing you'd change to make it work for an empty list?"
- Revision: "Want to change your prediction? Run it again."
**How to wait.** Count to five in your head. When the question is about code on the screen, let them read as long as they need. Look at the code or the spreadsheet, not at the student.^[5](#note-5)^
**What a stuck silence usually means.** The question may be too big; shrink it to one input. They may not know what "returns" means yet; go back to the function machine. They may be afraid the answer is obvious and they're missing it. There may be no test table to compare against. Or the spreadsheet is full of colors and charts, and the question got lost; hide the chart for a minute.
**Don't say / say instead.** Don't say "No, lists start at zero." Say "Let's ask Python. Print position 0 and see."
### Blocked, then mixed
Spend a few days on functions alone, then lists alone, then spreadsheets alone. Then mix: one Hour might ask for a function that takes a list and returns its biggest number. That mixed task is where students discover the ideas belong together.
### One incorrect example to diagnose
Here is an illustration, not a real family. Show your student this function, from an imaginary student who says it finds the biggest temperature:
```python
temps = [-5, -2, -9]
biggest = 0
for t in temps:
if t > biggest:
biggest = t
print(biggest)
```
It prints `0`. Zero isn't even in the list. Ask: "What did this student assume?" (That temperatures are never below zero.) "What test would have caught it?" (A list of all negative numbers.) "What's the fix?" (Start with `biggest = temps[0]`.) A test table with edge cases would have found it in a minute.
### A week without a screen
Everything in this chapter has a paper version, which is handy for travel weeks or a broken laptop. Function machines need only slips of paper. Index cards act out every list command. A tally sheet and a pencil can do the work of `COUNTIF`: count the marks, group them by bird, add the groups. Charts can be drawn on graph paper, which is the best way to feel how much an axis choice matters, because you have to decide where zero goes with your own pencil. A student can even "run" a function by hand, writing a trace table with one column for each variable and one row for each step. When the laptop comes back, the code feels familiar instead of new.
### Encouragement that means something
Praise the move, not the student. Try these:
- "You wrote the test table before the code. That's what careful programmers do."
- "You noticed the axis didn't start at zero. Plenty of adults miss that."
- "You turned three copies of the same lines into one function. The program's easier to read now."
- "You wrote down who was missing from your data. That makes your answer more honest, not less."
Specific praise tells your student exactly what to do again. "Great job" tells them only that you're pleased.
### Siblings and co-ops
The quiz machine is made for groups: each student writes five questions on a shared topic, then everyone takes everyone's quiz. Data walks work well with two counters on two different corners, then a comparison at home. Charts make a good co-op show-and-tell, especially the "lying" version beside the honest one.
## For the student
If you've copied and pasted the same five lines three times, you've found a function.
A **function** is a named chunk of code you can use again. You write the steps once, give them a name, and call the name whenever you need them. Inputs go in the parentheses after the name. Those inputs are called parameters.
```python
def draw_box(size):
for row in range(size):
print("#" * size)
draw_box(3)
```
This prints three rows of `###`. Call `draw_box(5)` and you get a bigger square, with no new code.
**Print or return?** `print` shows something on the screen. `return` hands an answer back so your program can keep using it. If you write `answer = some_function(100)` and then `print(answer)` shows `None`, your function printed instead of returning. It showed you the answer and then threw it away.
A **list** is items in order, numbered from 0. That "from 0" part catches everyone at first:
```python
pets = ["cat", "dog", "fish"]
print(pets[0])
print(len(pets))
```
This prints `cat`, then `3`. Three items, at positions 0, 1, and 2. Ask for `pets[3]` and Python says `IndexError: list index out of range`. Now you'll know why. You can add to the end with `pets.append("hamster")`, take out an item with `pets.remove("dog")`, and visit every item with `for pet in pets:`.
**Data** is information you collect to answer a question. Always start with the question. "Which bird comes to our feeder most?" tells you what to count, when, and how. A spreadsheet holds the data in rows and columns. And here's the neat part: spreadsheet formulas are functions. `=SUM(D2:D31)` takes a range of cells in and gives a total out. Same idea as Python.
### A worked example
Say your question is "Which bird visits most in the morning?" You count for two weeks and type it into a sheet. `=COUNTIF(C2:C40, "sparrow")` tells you how many sparrow visits there were. You do the same for each bird and make a bar chart. Sparrows: 41. Cardinals: 37. Your caption says: "Sparrows came most often, but cardinals were close. We only watched in the mornings, so evening birds are missing."
That last sentence is what makes it honest.
### Functions and lists together
The real power shows up when you combine them. A function can take a whole list as its input:
```python
def total(numbers):
result = 0
for n in numbers:
result = result + n
return result
print(total([3, 2, 1]))
```
This prints `6`. Now you can total any list you like with one short call. That's how bigger programs stay readable: small functions with clear names, each doing one job, each tested on its own.
A tip for when things go wrong: when a list program gives a strange answer, add `print(my_list)` and `print(len(my_list))` just before the line that misbehaves. Seeing what's really in the list solves most list bugs in under a minute. Then take those lines out again.
### Try this today
Write a function called `double(n)` that returns `n * 2`. Before you run anything, fill in a test table: what should `double(0)`, `double(-3)`, and `double(1000)` give? Then run it and check.
### Explain it back
Tell your parent the difference between `print` and `return`, using a function you wrote. Show them what happens when you store the result in a variable.
### This part is hard for everyone
Return versus print confuses almost every new programmer, because both put something on the screen when you test them. The difference only shows up when you try to *use* the answer. If it feels slippery, that's normal. Store the answer in a variable and print the variable. That test always tells you which one you wrote.
Lists starting at 0 also feel wrong for a while. Keep index cards with the numbers written above them nearby until it doesn't.
### Challenge
Build a quiz machine with two lists: one for questions, one for answers. Keep score. Give it to two people, and write down their scores (first names only). Then improve one thing based on what confused them.
**If you're 13 or older:** write a function `biggest(numbers)` that returns the largest number in a list without using `max()`. Test it with an empty list. What happens? Decide what it *should* do, and make it do that.
### What to save
- Your function files, with a test table for each.
- Your quiz machine and a friend's score.
- Your spreadsheet, with formulas shown.
- Your chart, with a one-line honest caption.
- Your question card and your "who's missing?" note.
- Your Debug Log entries.
Save everything in two places.
## If it isn't clicking
**Functions feel pointless.** That usually means the programs are still small enough not to need them. Go back to FN-01 Function Machine, then find a real repeat in an old program. The point of a function shows up the moment you'd otherwise copy and paste.
**Return makes no sense.** Step back to paper. The function machine passes a slip back through the slot; that's `return`. A machine that shouts the answer and keeps the slip is `print`. Then run the "Saved:" example again.
**Off-by-one errors keep happening.** Bring back the index cards with positions written above them. Before each list line, the student points to the card. Add `print(len(my_list))` lines as print detectives.
**The spreadsheet feels like busywork.** The question isn't theirs. Let them pick one they care about, even if it's "Which of my games do I actually play most?" (Track it on paper for a week; no app needed.)
If none of this works, slow down. Use the rescue order: ask → wait → hint → short demo on your own copy → hand it back. It's fine to spend an extra week on lists.
## Tools, including AI
**Thonny**, the free offline Python editor from earlier chapters, is all the programming needs.^[2](#note-2)^ Its Variables view (View, then Variables) is especially good for lists, because you can watch items appear and disappear.
**Spreadsheets.** Use whatever spreadsheet program the family already has, on a computer in a shared room. Keep files on the family drive.
**Optional data source.** A student with a micro:bit can collect light or temperature readings and bring them into a spreadsheet; see the optional strand in Chapter 6.
**AI.** For the rules, see the AI box in **The Computing Hour**. What's different here:
**11–12:** AI is parent-operated only. If you use it at all, it might suggest practice problems (answers hidden until your student tries).
**13–14:** After your student has chosen a chart type and said why, they may ask an AI, with you present, what kind of chart it would suggest and compare the reasons. If an AI suggests a formula or a function, it goes through AI-07 Explain Every Line before anything is used, with a "Help I used" line and a Whose Work card marking it as made by a tool. Check the current terms of any service first.
## What "done enough" looks like
Your student is ready to move on when they can:
- write a function with a parameter and explain what goes in and what comes out;
- at 13–14, explain `return` versus `print` and test a function with a table that includes edge cases;
- use a list with `append`, `remove`, `len`, and a loop, and explain why the first item is at 0;
- start a data project with a written question;
- use `SUM` and `AVERAGE` (and at 13–14, `COUNTIF` and grouping) and say what each formula takes in and gives back;
- make an honest chart and name who or what is missing from the data.
**AS checks.** Once this month, run AS-01 Cold Trace on a short list program (predict the output without running it), AS-02 Debug on the Spot with a planted off-by-one, and AS-03 Explain Your Code on the quiz machine. All three are AI-free.
**Placement by skill.** A twelve-year-old who handles `return` comfortably can take on FN-03. A fourteen-year-old still unsure about positions needs more time with index cards, and that's a fine use of a week.
**The life of the habit.** From now on, every program bigger than twenty lines should have at least one function, and every question about the world should start with a question card. Keep the bird sheet. It makes a good portfolio piece next to the chart that tells the truth.
\newpage
# Chapter 5
## Building for the Web: HTML, CSS, and a First Taste of JavaScript
{width=100%}
## Why this matters
Every site your student has ever visited started as a blank file. Somebody typed a few lines of text, saved it, and opened it in a browser. That is still how it works, and your student can do it this week with tools your computer already has.
Building a web page teaches something Python alone doesn't: that a program has an audience. A page is made to be read by someone else, on someone else's screen, possibly with their eyes or possibly with a screen reader that speaks the page aloud. That turns every choice (what goes first, what a link says, what a picture's description says) into a question about another person. It's a gentle way to teach that good code is considerate code.
A web page has three layers, and this chapter takes them in order:
- **HTML** gives the page its structure: headings, paragraphs, lists, links, pictures.
- **CSS** gives it style: colors, fonts, spacing.
- **JavaScript** gives it behavior: a button that does something when clicked.
The national computer science standards for ages 11–14 ask students to use reference documentation while they program and to improve their work based on user feedback, making it easier to use and more accessible.^[17](#note-17)^ Web pages are a natural place for both. Your student will look things up in MDN Web Docs, a free reference and course for web developers run by Mozilla, and test pages on real people at a small family "demo day."^[47](#note-47)^
One more thing makes the web a good fit at this age: no account is needed. A page saved on your own computer opens in your own browser, and nobody else sees it. Publishing a page online is a separate decision, made by you, later or never. This chapter keeps the work local.
## For the parent: understand it yourself
**The everyday picture.** Think of a house. HTML is the frame and the rooms: this is the kitchen, this is a hallway. CSS is the paint, the furniture, and how far apart things sit. JavaScript is the light switches: press one and something happens.
**The precise picture.** An HTML file is plain text with **tags** in angle brackets. Most tags come in pairs: `
` opens a top-level heading and `
` closes it. Here is a small but complete page, saved as `index.html`:
```html
Birds at Our Feeder
Birds at Our Feeder
I counted birds every morning for two weeks.
What I saw most
Sparrows
Cardinals
```
Double-click the file and it opens in the browser: a big heading, a sentence, a smaller heading, and a bulleted list. The `` holds information about the page (its title on the browser tab, and a link to the style file). The `` holds what you see.
**CSS** lives in a second file, `style.css`, and says how things should look:
```css
body {
font-family: sans-serif;
background-color: rgb(250 248 240);
margin: 2em;
}
h1 {
color: rgb(20 80 140);
}
```
Each block starts with a **selector** (which things to style: `body`, `h1`) and lists **properties** and values inside curly braces. A color written as `rgb(20 80 140)` gives amounts of red, green, and blue, each from 0 to 255.^[48](#note-48)^ Chapter 6 explains why it's those three numbers, and why 255.
**The box model.** Every element on a page is a box. From the inside out: the **content**, then **padding** (space inside the edge), then a **border**, then a **margin** (space outside, pushing other boxes away). Most layout puzzles in CSS are box puzzles.
**JavaScript** is a programming language that runs in the browser. Students who know Python will recognize variables, `if`, and functions with different punctuation. This chapter uses it for one small job: when a button is clicked, change some text.
**Accessibility as good manners.** Some people use a screen reader, which reads a page aloud. Many screen readers let a person jump from heading to heading, so headings work like a table of contents.^[49](#note-49)^ That's why a page should use real headings in order (`h1`, then `h2`) instead of just making text big. MDN's accessibility guide adds three habits a student can learn this week:^[49](#note-49)^
- Every picture gets **alt text**, a short description in the `alt` attribute that gives a direct representation of what the picture shows. A purely decorative picture gets an empty one: `alt=""`.
- **Link text makes sense on its own.** "Read about how web pages work" is good; "click here" tells a screen-reader user nothing.
- **Text stands out from its background.** The guide asks for a contrast of at least 4.5 to 1 between text and background color. Pale gray on white usually fails.
**Reading the documentation.** Programmers look things up all day; it's part of the job, not a sign of weakness. MDN is the reference this book uses for HTML, CSS, and JavaScript.^[47](#note-47)^ Teach your student to look up a tag on MDN before asking anyone else.
**Developer tools.** Every major browser has built-in tools for looking at a page's code. You can usually open them by right-clicking part of a page and choosing "Inspect," or with Ctrl+Shift+I (or F12) on Windows and Cmd+Option+I on a Mac. Safari keeps them turned off until you enable them in its settings. The **Console** tab lists errors the browser meets while running JavaScript, which is where a silent button usually explains itself.^[50](#note-50)^
**Your computer or the web?** When your student double-clicks `index.html`, the browser reads a file from your own drive. Nothing travels anywhere. When you visit a site online, your browser asks a faraway computer, called a server, for files much like these, and they arrive in small pieces over the internet. MDN draws a useful line here: the internet is the network that connects computers, and the web is one service that runs on top of it.^[51](#note-51),[52](#note-52)^ Chapter 6 follows those pieces on their journey. For now, it's enough to know that the page your student builds is made of exactly the same stuff as the pages they visit.
**Publishing and privacy.** A page on your own computer is private. If your family ever decides to put a page online, that's your call, and it comes with the usual rules: first names only; no faces, school, or town; no photos of other people. Pictures on the page should be made by your student, or credited and used with permission. See Family safety basics in **The Computing Hour**.
### Wrong answers you should be able to hear
- **"I changed it, but nothing happened."** Usually the file wasn't saved, or the browser wasn't refreshed, or the wrong file is open. Reply: "Save, then refresh. Which file is the browser showing?"
- **"The page is broken."** Browsers try hard to show *something*, so a missing closing tag can make half the page bold instead of showing an error. Reply: "Which part looks wrong? Let's find the tag just before it."
- **"Alt text is optional."** Reply: "Close your eyes. I'll read you the page. What do you want me to say when we get to the picture?"
- **"It was online, so I can use it."** Reply: "Who made it? Did they say we could? Let's draw our own or credit it."
- **"The AI made the page, but I get it."** A generated page is made by a tool, not your student's work. Reply: "Great, then build one like it from a blank file and explain every line."
### Your five-minute warm-up
Type the small HTML page above into a plain text editor, save it as `index.html`, and open it in your browser. Change one word, save, refresh, and watch it change. Then practice this chapter's opening question once, aloud, and count to five in your head.
## How to teach it this week
Plan on two to three weeks: structure first, then style, then (for students who are ready) one button. Each Hour follows the usual steps:
- **Unplug and Plan.** A paper wireframe, labeled with tag names.
- **Predict.** "When you refresh, what will change, and where?"
- **Build and Test.** Type, save, refresh, look. Then test on a **first user**.
- **Debug and Log.** Expected/Actual for every surprise, written in the Debug Log.
- **Save and Explain.** "I predicted… It did… Next I'd change…" and "Help I used: …"
The tools: a plain text editor (the one that came with the computer is fine, but not a word processor, which adds hidden formatting) and a web browser. Make one folder for the project. Keep `index.html`, `style.css`, and any pictures together in it.
### In-home — WEB-01 Paper Wireframe
- **Time:** 15 minutes.
- **Materials:** paper, pencil, a ruler if you like.
- **Safety and privacy:** none needed.
- **The fun:** designing before building, like an architect.
- **The skill:** sketching a page layout and labeling the parts as tags.
- **The crumb:** the sketch.
The student draws boxes for each part of the page (title, introduction, list, picture, link) and labels each with its tag: `h1`, `p`, `ul`, `img`, `a`. Then you ask the opening question: "Who is this page for — and what will they see first?" The answer often reorders the sketch.
### In-home — WEB-02 My First Page
- **Time:** 30 minutes.
- **Materials:** a plain text editor, a browser, the wireframe.
- **Safety and privacy:** saved locally; no account; first names only on the page.
- **The fun:** your words, in a real browser.
- **The skill:** HTML headings, paragraphs, lists, and links.
- **The crumb:** `index.html`.
The student types the page from the wireframe, saving and refreshing after every few lines. That rhythm (small change, save, refresh, look) is the web version of Predict and Build and Test. Add one link: `Read how web pages are built on MDN`. Notice the link text says where it goes.
### How to fade your help
Use the rescue order: **ask → wait → hint → short demo on your own copy → hand it back.** For HTML, the best hints point to a pair: "Every opening tag in this part, can you find its closing tag?"
**11–12:** One page plus a CSS file. You might type the first `` skeleton together, then hand over the keyboard for everything inside ``.
**13–14:** Three pages linked to each other, sharing one stylesheet, plus a JavaScript button and a round of feedback from first users. The student leads; you're the **first user**, trying the page like a stranger and reporting what you see without fixing anything.
**Ready 12:** A twelve-year-old who finishes a styled page and asks "Can I make it *do* something?" is ready for WEB-06.
### A worked Hour (illustration)
Here is an illustration, not a real family. Picture a fourteen-year-old and her grandmother on a Thursday afternoon. The girl has three pages about the birds at the feeder. In Predict, she says the heading will turn dark blue when she adds an `h1` rule to `style.css`. She saves, refreshes. Nothing changes. Her grandmother asks the opening question, then, after a pause, "What did you expect, and what happened?" The girl writes Expected/Actual. She opens the HTML and reads the `` line out loud: `href="styles.css"`. She looks at the folder. The file is called `style.css`. One letter. She fixes it, refreshes, and the heading turns blue. Her log entry: "Bug: CSS didn't load. Clue: no styles at all, not just one. Fix: file name in link line. Learned: if *nothing* is styled, check the link line first." That last sentence is the kind of thing that turns into skill.
## Practice that actually builds learning
### In-home — WEB-03 Style It
- **Time:** 30 minutes.
- **Materials:** the page from WEB-02, a new file called `style.css`.
- **Safety and privacy:** local only.
- **The fun:** making it look like yours.
- **The skill:** CSS selectors, color, fonts, and spacing.
- **The crumb:** `style.css`.
Add the `` line in the ``. Write one rule at a time and predict each change before refreshing. The student should look up at least one property on MDN by themselves (`font-family`, `text-align`, `border`). **11–12:** Three rules. **13–14:** A shared stylesheet used by all three pages, so one change updates the whole site.
### In-home — WEB-04 Paper Box Model
- **Time:** 10 minutes.
- **Materials:** four sheets of colored paper, scissors.
- **Safety and privacy:** none needed.
- **The fun:** nesting rectangles like a picture frame.
- **The skill:** margin, border, padding, and content.
- **The crumb:** a labeled paper model.
Cut a small rectangle (content: write a word on it). Glue it on a slightly bigger one (padding). Then a thin frame (border). Then the biggest sheet (margin). Label each layer. Now write the CSS: `p { padding: 1em; border: 2px solid gray; margin: 1em; }`, refresh, and match the screen to the paper.
### In-home — WEB-05 Alt Text and Access Check
- **Time:** 15 minutes.
- **Materials:** the student's page and a printed checklist.
- **Safety and privacy:** none needed.
- **The fun:** seeing your page the way someone else does.
- **The skill:** alt text, heading order, contrast, and link text.
- **The crumb:** the checklist.
The checklist has four lines: every picture has alt text that says what it shows (or `alt=""` if it's decoration); headings go in order with no skipped levels; text is easy to read against its background; every link says where it goes. Then you read the page aloud with your eyes closed, the way a screen reader might, reading alt text when you reach a picture. Students hear the difference immediately. A picture might get: ``.
### In-home — WEB-06 A Button That Answers
*For 13–14; ready 12.*
- **Time:** 30 minutes.
- **Materials:** the page, a new file called `script.js`.
- **Safety and privacy:** local only.
- **The fun:** a page that responds.
- **The skill:** a JavaScript click event that changes text on the page.
- **The crumb:** `script.js`.
Add to the HTML, just before ``:
```html
```
Then, in `script.js`:
```javascript
const button = document.querySelector("#fact-button");
const answer = document.querySelector("#fact");
button.addEventListener("click", function () {
answer.textContent = "Sparrows: 41 visits in two weeks.";
});
```
Click the button and the empty paragraph fills in. In plain words: find the button, find the paragraph, and when the button is clicked, run a small function that sets the paragraph's text.^[53](#note-53)^ The script line goes at the end of the body so the button already exists when the script looks for it. Using a real `
`.
### In-home — WEB-06 A Button That Answers
*For 13–14; ready 12.*
- **Time:** 30 minutes.
- **Materials:** the page, a new file called `script.js`.
- **Safety and privacy:** local only.
- **The fun:** a page that responds.
- **The skill:** a JavaScript click event that changes text on the page.
- **The crumb:** `script.js`.
Add to the HTML, just before ``:
```html
```
Then, in `script.js`:
```javascript
const button = document.querySelector("#fact-button");
const answer = document.querySelector("#fact");
button.addEventListener("click", function () {
answer.textContent = "Sparrows: 41 visits in two weeks.";
});
```
Click the button and the empty paragraph fills in. In plain words: find the button, find the paragraph, and when the button is clicked, run a small function that sets the paragraph's text.^[53](#note-53)^ The script line goes at the end of the body so the button already exists when the script looks for it. Using a real `