🐞 Lesson 3.3: Debugging & Remixing
Bugs aren't the enemy — they're the job. This lesson gives you a calm, repeatable way to find and fix problems (and coach your child through the frustration), plus how to learn from the world's biggest library of kid-made code.
📚 What You'll Learn
By the end of this lesson, you will be able to:
- Apply a simple 4-step debugging method
- Recognize the most common Scratch bugs and their fixes
- Use See Inside to learn from any shared project
- Understand what remixing is (and its good etiquette)
- Coach your child through frustrating bugs without taking over
Estimated Time: 35 minutes • Builds on: All of Modules 1–3 • Project: debug your catch game and remix a shared project
In This Lesson
🎓 Learn It: The debugging mindset
Professional programmers spend more time fixing than writing. "Bug" is just the word for "not doing what I expected yet." The single most valuable thing you can model for your child is calm curiosity in the face of a bug.
The computer isn't wrong and it isn't being mean. It's doing exactly what the blocks say. Debugging is the detective game of finding the gap between what you said and what you meant.
✅ Reframe the language
Swap "It's broken / I failed" for "Interesting — let's find out why." Bugs become puzzles instead of defeats. This one habit protects a child's confidence for years.
🌱 Growth mindset: every bug is feedback, not a verdict
A bug is the computer giving you precise, honest feedback: "here is exactly what your blocks told me to do." It isn't a judgment about whether you're a "computer person." Each one you track down teaches you something you'll never have to learn again — which is why experienced coders are mostly people who have made a lot of mistakes and paid attention to them. Let your child hear you say, "Ooh, a bug — what is it telling us?" When grown-ups treat mistakes as clues instead of failures, kids learn it's safe to try hard things.
🎓 Learn It: The 4-step method
When something's wrong, resist random flailing. Walk this loop instead:
what actually happens"] --> B["2 · Predict
which block causes it"] B --> C["3 · Change
ONE thing"] C --> D["4 · Test
run it again"] D -->|still wrong| A D -->|fixed!| E([🎉]) style A fill:#4C97FF,color:#fff,stroke:#333 style B fill:#5CB1D6,color:#fff,stroke:#333 style C fill:#FFAB19,color:#5c3d00,stroke:#333 style D fill:#59C059,color:#fff,stroke:#333
The golden rule is step 3: change only one thing at a time, then test. Change five things and you'll never know which one mattered.
🔍 Scratch's built-in debugging helpers
- Click a block or stack to run just that piece and watch what it does.
- Tick a variable's checkbox to watch its value change live on the stage.
- Add a temporary "say" block to print a value: say (score) tells you what the computer "thinks."
- Slow it down with wait blocks so you can see each step.
🎓 Learn It: The usual suspects
90% of Scratch bugs are one of these. Keep this table handy:
| Symptom | Usual cause | Fix |
|---|---|---|
| Nothing happens | Code is on the wrong sprite | Select the right sprite in the sprite list |
| Runs once, never reacts again | An if with no loop around it | Wrap the check in a forever loop |
| Blocks after a loop never run | Trapped below a forever | Move them inside, or use repeat until |
| Sprite zooms off / upside-down | Position not reset / rotation style | Add go to x/y at start; set rotation to left-right |
| Score jumps by many at once | Condition stays true for many frames | Move the sprite away, or add a short wait after scoring |
| Two sprites out of sync | Relying on wait timing | Coordinate with broadcast / when I receive |
🎓 Learn It: See Inside & remixing
One of Scratch's superpowers: you can look at the code of almost any shared project. On a project's page, click “See Inside” to open its full code and explore how it was made — a bottomless, free learning resource.
Remixing means making your own copy of someone's project to change and build on. Click See Inside, then Remix (when signed in), and it becomes yours to modify. Scratch is built around this — it's encouraged, not frowned upon.
✅ Remixing done right
- Change something meaningful and make it your own.
- Scratch auto-credits the original — leave that intact.
- Thank the original creator in your notes.
⚠️ Talk with your child about
- Remixing to learn, not to claim someone's work as fully theirs.
- It's normal (and great) to learn by studying others' code.
Reading other people's code is how every programmer improves. "See Inside" turns the whole Scratch community into your child's textbook.
💬 Teach It: Coaching through frustration
A bug plus a tired kid equals tears. Your calm is the most important debugging tool in the room.
The "rubber duck" trick
Have your child explain their code out loud, block by block, to you (or a stuffed animal). Astonishingly often, they find the bug themselves mid-sentence — just from saying it aloud.
"Walk me through it like I know nothing. What should this block do? …and what did it actually do?"
Ask, don't fix
- "What did you expect to happen?"
- "What happened instead?"
- "Which block do you think is responsible?"
- "What's one thing we could change to test that?"
Know when to take a break
If frustration boils over, stop. "Let's let our brains rest — coders do this all the time." Walking away and coming back fresh is a real, professional debugging strategy, not giving up.
👧 Ages 5–7
Keep bugs tiny and fixes fast. Celebrate the fix dramatically: "You SQUASHED the bug!" 🐞
🧒 Ages 8–11
Teach the 4-step method explicitly. Let them lead; you ask the questions. Introduce "See Inside" on a project they love.
🧑 Ages 12+
Encourage remixing an ambitious project to learn a new technique, then bringing that idea back to their own work.
⚠️ The biggest parent mistake
Grabbing the mouse and fixing it yourself. It ends the frustration and the learning. Sit on your hands; ask one more question. The pride of their fix is the whole point.
🎯 Quick Check
Question 1: The golden rule of debugging is…
Question 2: What does "See Inside" do on a shared project?
Question 3: Your child is melting down over a stubborn bug. Best move?
📓 Learning Journal
Take five minutes to write it down
Grab the same notebook or notes app you've been using. A few honest lines now will make the next lesson easier — and give you a record of how far you've come.
- Key concepts: Write the 4-step method (Watch → Predict → Change one thing → Test) from memory. Why does changing only one thing matter so much?
- What clicked: Which "usual suspect" have you already run into in your own projects? Did the table explain a bug you'd fixed by luck?
- Questions & confusion: Anything unclear about remixing etiquette, or how See Inside and Remix differ?
- Ideas to try: Find one shared project your child loves, click See Inside, and note one technique you'd like to borrow.
- Progress & feelings: How do you react when code breaks — and has that changed since Module 1? How did your child handle their last bug?
💡 Teach It tip: Start a "Bug Hall of Fame" page in your child's notebook: for each bug, write what it did, what caused it, and how they squashed it. Kids love watching the list grow — and it quietly teaches that bugs are trophies, not failures.
Summary & Module 3 Complete 🎉
🎓 Key Takeaways
- Bugs are normal. Model calm curiosity, not frustration.
- Debug with a loop: Watch → Predict → Change one thing → Test.
- Most bugs are a handful of usual suspects — keep the table handy.
- See Inside and remixing turn the whole community into a learning resource.
🏆 Module 3 done!
You've built a story and a game, and you can fix things when they wobble. That's a genuinely capable coding buddy.
🏅 What You've Accomplished
- Learned a calm, repeatable 4-step debugging method
- Can spot the most common Scratch bugs and fix them
- Used See Inside to learn from the Scratch community
- Finished Module 3: a story, a game, and the skills to fix them
📋 Before the Next Lesson
- Deliberately break your catch game (move one block) and let your child debug it
- Explore one shared project with See Inside together
- Save your apple game — its ideas return in the Module 4 capstone
- Write your journal entry
❓ Common Questions at This Stage
My child gets upset and says "I'm bad at this" when a bug appears. What do I say?
Separate the bug from the person: "The code has a bug; you're a coder who's finding it." Point to bugs they've already fixed — a Bug Hall of Fame helps here. And if emotions are high, take a short break; that's a real debugging strategy, not quitting.
Is remixing the same as copying? I don't want to teach my child to cheat.
Remixing is openly encouraged on Scratch: everything shared there is under a license that allows it, and Scratch automatically credits the original creator. The line to teach is honesty — change something meaningful, keep the credit, and don't pretend the whole thing is yours.
I can't find the bug even after trying the 4 steps. Now what?
Shrink the problem. Pull blocks off the script until the smallest piece that still misbehaves is left, or click individual blocks to run them one at a time. Explaining it aloud to a "rubber duck" works for adults too. And sometimes the best move is simply to come back tomorrow with fresh eyes.
🔭 Looking Ahead
Module 4: Leveling Up — Bigger Projects begins with Lesson 4.1: Clones — One Sprite, Many Copies, the neat way to make lots of falling objects without duplicating sprites. Then you'll learn to make your own custom blocks with My Blocks, and bring it all together in a capstone you plan and build as a team: Star Catcher, a complete game with falling stars, a score, lives, and a game-over screen. Your new debugging skills will get plenty of use.
💛 Encouragement for the Journey
You now know how to build things and how to fix them when they go wrong — that second skill is the one that makes a real coder. Three modules down. Take a moment to notice how much of this would have looked like gibberish when you started.