1 - Start ~4 mins
You have built Scratch programs, planned with pseudo-code and flow charts, made arcade games, evaluated each other's work, and looked at what is inside a computer and what computing means in the world. Today you put Strand 1 together in one free-choice build: plan it, make it, test it, then show it and improve it from feedback.
Keep this to three minutes. Name the arc in one breath: sequence, variables, loops, decisions, testing, planning, arcade games, evaluation, and the computers-and-the-world lessons. The point of today is synthesis, not a new technique. Students choose Scratch or MakeCode Arcade; both are valid. If anyone has no saved work from earlier, they start a fresh small project rather than rebuilding an old one from memory.
2 - The Challenge ~4 mins
Your challenge is a small build you can finish in this lesson. Follow this order:
- Choose something small: a short quiz, a sprite that reacts in two different ways, a mini collector with a score, or one new feature on a game you already have.
- Plan first with either pseudo-code or a flow chart. Write the goal, the main steps, and any decision (if / else) you will need.
- Build it in Scratch or MakeCode Arcade, matching your plan.
- Test and debug as you go. When something breaks, use the routine: read the symptom, find the block or line, form a hypothesis, test it, revert if wrong.
- Show your build to a partner (or a group of three if needed), take one piece of feedback, and make that one change.
Done looks like: a short plan, a program with at least one working path that matches the plan (even if rough), one bug you found and fixed (or one test that passed cleanly), and one change made from feedback.
Scope example (mini collector):
- Goal: player picks up coins; score goes up; win at 5
- Step 1: set score to 0 when the program starts
- Step 2: move the player with arrow keys
- Step 3: when player touches coin, change score by 1 and hide coin
- Decision: if score = 5 then show You win, else continue
Bug I fixed: score stayed at 0 because change-score was outside the forever loop; I moved it inside so it runs on every touch.
Display the order, the done-looks-like list, and the mini-collector exemplar on the board and leave them up. The exemplar is for scope only: students may copy its shape, not its topic. Steer ambitious students toward a small scope: one screen, one score, one decision is enough. A half-finished epic fails the lesson; a finished mini build succeeds.
Students may reopen a saved Scratch or Arcade project and add one feature, or start fresh. If a saved project is missing, the recovery line is: start a new small project from today's plan rather than trying to rebuild the old one.
Look-fors while you circulate later: plan written before blocks; variables named clearly; at least one loop or decision where it earns its place; testing happening before the share round, not only after.
3 - Hands-on: Plan and Build ~20 mins
Work through the challenge up to a working first version. Aim for plan plus one working path that matches it, even if the rest is still rough.
- Write your plan as pseudo-code or draw it as a flow chart. Keep it short. Use this frame if it helps:
- Goal: what the build should do
- Step 1
- Step 2
- Step 3
- Decision: if … else …
- Open Scratch or MakeCode Arcade. Start a new project, or open a saved game if you are adding one feature. If your earlier work is missing, start fresh from your plan.
- Build the program so it matches the plan. Use variables, loops, decisions or events where they help, not for show.
- Before you run it the first time, pause and say what you expect to happen. Then run it. When something is wrong, use the debugging routine: read the symptom, find the block, form a hypothesis, test it, revert if wrong.
- Checkpoint: about halfway through this block you should already have run the program once. If you have not, cut the scope now to one goal and one decision so a first run is working before you save.
- Save your project the class way before the share round.
By the end of this step you should have a short plan and a program that runs at least one clear path and roughly matches the plan.
Board milestones (leave visible): plan done by minute 5 · first run by minute 15 (or cut scope now) · save by minute 29. Call a hard one-minute freeze at minute 5: anyone still without a written plan pauses building and finishes the plan first. At minute 15, call the mid-block checkpoint aloud: anyone without a first run freezes new features and cuts to one goal plus one decision until something runs.
Suggested timing: five minutes on the plan, then the rest on the build, first run, debug, and save. Success bar for share: plan plus one working path (even if rough). That keeps LO 1.9 reachable for students starting fresh.
Predict beat (PRIMM): when a student is about to run for the first time, stop them briefly and ask: What do you expect to see when this starts / when this key is pressed? Then let them run and compare. Use the same beat again after a debug change. Keep it spoken and short; do not turn it into a written task.
Circulate with coaching questions, not solutions: Which step of your plan are you on? What should happen when this key is pressed? What did you expect, and what did you see? Name the four computational-thinking steps when you spot them in use (decomposition when they break the idea into parts, pattern recognition when they reuse a loop or event shape, abstraction when they leave out detail that does not matter, algorithms when the plan becomes ordered steps).
Common traps: scope creep (cut features, keep one goal; point at the mini-collector exemplar); building with no plan (send them back to paper for two minutes); silent stuckness (prompt the debugging routine out loud). Support students who freeze on a blank page: point them at the on-screen plan frame, the four starter ideas, and the exemplar. If needed, offer a one-page starter scaffold (pre-labelled sprite and a score variable) so they spend the block on their one decision or feature. Save reminder before you move to the share step.
4 - Hands-on: Show, Feedback, Improve ~6 mins
Work in a pair when you can (groups of three only if numbers need it):
- Each person runs their build once while the other watches (about one minute each).
- For each build, name one strength and one improvement.
- Choose one piece of the feedback you received and make that single change in your program.
- Test the change, then save your project the class way again.
You are done when your program includes one clear change that came from the feedback.
Default to pairs whenever class size allows; use threes only for leftovers. Keep the rotation tight: cap each run-through at about 60 seconds, then one strength and one improvement spoken aloud (not written essays). Protect a fixed 3 to 4 minute improve-and-re-save window on the board clock after everyone has had a turn (for pairs that is roughly 2 minutes of sharing then 4 minutes of improve; for a three it is tighter, so hold the 60-second cap firmly).
Model the feedback sentence stems on the board if needed: One thing that worked well was… and One thing I would try next is… Steer feedback toward behaviour of the program (controls, scoring, clarity of goal), not decoration. A rough but runnable path is enough to share; feedback can name the next small fix.
If a pair finishes early, they can make a second small improvement or tidy names and comments, but the assessed move is one acted-on piece of feedback.
5 - Make Sense ~3 mins
Pull the threads together. A solid Strand 1 build starts with a plan (pseudo-code or a flow chart), becomes code that follows that plan, is tested and debugged on purpose, and gets sharper when someone else tries it. The four computational-thinking steps are what made the plan usable: breaking the idea down, spotting repeated patterns, leaving out detail that did not matter, and writing clear steps the computer (and a classmate) could follow.
Two minutes, whole class. Ask two or three students to name the change they made from feedback and whether the plan or the live test revealed the issue. If time allows, invite one student to point to where decomposition or algorithms did the heavy lifting in their plan. Keep it brisk; the reflection step is next.
Unlock the full learning experience
You're previewing this lesson. Get full access to this lesson and hundreds more — each one ready to teach, with interactive activities, printable resources and pupil progress tracking built in.
This lesson is copyright of Coding Ireland 2017 - 2025. Unauthorised use, copying or distribution is not allowed.