What I use for coding in Cambridge Primary (and what I skip)

Week 2 of Spring B, my Year 4 Computing lot tried to leap from sequencing a dance to adding variables because they’d seen an older sibling’s project. That’s the trap: lots of “coding” tasks are exciting yet skip the Cambridge Primary build-up. In this pathway, I’m tracking progression from unplugged algorithms and precise instructions, into sequence, then simple selection, then repetition, and only later variables with careful reasoning about inputs/outputs.

The misfits I watch for: US-style worksheets that use secondary terms too early (“for loop” before we’ve nailed “repeat until”), robotics tasks that are brilliant but don’t assess anything beyond “it moved,” and vague success criteria like “be creative.” Cambridge Primary asks for concrete computational thinking, accurate vocabulary, and evidence of debugging and reasoning. I keep my mapping of “what this activity actually checks” in ClassPods and only add tasks that tick those boxes.

When I need extra practice, I skim community-made sequences and pick ones I can evidence against our statements; you can browse a focused set of coding ideas in this community library.

Last Friday with Stage 3, I almost ran a worksheet that jumped to variables and nested conditionals. My quick checks saved me. I keep it simple: if I can’t point to the specific construct or habit the task builds, it goes back in the drawer. Cambridge Primary rewards clarity and progression, not gimmicks.

My checks now: vocabulary match (sequence/selection/repetition, debug, predict), one new idea at a time, and a visible algorithm first (flowchart or ordered steps) before code. I prefer tasks that force pupils to explain why a choice works, not just make something flashy. Assessment language matters, too. I look for “I can…” statements that I can mark with quick evidence: a screenshot with comments, a short reflection, or a tick-list tied to the construct.

When I’m short on time, I spin up a draft pack and preview how the prompts and checks read for my group—no printing until I’m sure the verbs and constructs land the way Cambridge phrases them. You can test-drive that draft-and-preview flow in this demo builder, which is usually faster than reformatting a PDF.

Two Tuesdays ago, my Year 5s built a “Random Story Generator” to nail selection, repetition, and variables without the wheels coming off. We used a worked example called “Haunted Castle” with variables for character, setting, and event, then added random picks and a replay option. This showed what selection actually controls and why repetition needs a stopping condition.

• Objective (5m): I can explain how selection changes program behaviour and use repetition to replay my generator.
• Starter (8m): Unplugged: three cups labelled character/setting/event; pupils draw cards and form silly sentences. Quick talk: where’s selection? where’s repetition?
• Main (32m): Build variables; add lists; use pick random to choose items; if…then to handle punctuation; repeat until user says stop. “Haunted Castle” on the board as the model.
• Formative check (10m): Pair swap: predict output before clicking; circle the block that makes the choice; one-minute voice note explaining their selection.
• Plenary (5m): Exit ticket: screenshot + one sentence: “Selection matters here because…”

If you like this structure but want it laid out with prompts and exit tickets ready to go, you can generate a fresh lesson pack from this planner. I built my slides and checks in ClassPods, then tweaked timings after period one.

Last half term, my Year 4s made a “Treasure Bot” that follows instructions to reveal coordinates. Marking went from messy to manageable once I switched to this rubric. It matches the Cambridge Primary feel: clear constructs, computational thinking, and visible debugging.

Use verbatim tomorrow:

• Algorithm clarity: Steps are precise and ordered; decision points are shown (words or flowchart). Evidence: photo or screenshot.
• Program constructs: Uses correct blocks for sequence; includes selection where a choice is needed; uses repetition to avoid duplicated steps.
• Debugging: Shows at least one bug found and fixed, with a note: “I expected…, I saw…, so I changed…”
• Testing: Two test cases recorded (normal and edge). Pupil prediction + actual result captured.
• Vocabulary: Uses terms from the word bank accurately in reflection.
• Reflection: “Because/So that” sentence explaining why selection was needed.

Grading guide: Emerging (2), Developing (3), Secure (4), Deep (5) per row; total /30. I keep a blank digital copy so I can duplicate it for each class; if you want a ready-made space for it inside a pack, spin up a blank lesson pack and paste these rows.

Thursday after school, I had my Year 3 EAL group test a Bee‑Bot maze while we whispered through the word bank in both languages. Two small shifts helped: labels on the floor in English and home language, and code comments written bilingually by the talk partner with stronger English. For Year 5, we keep variable names in English (to match most block labels) and add a bilingual glossary on page one.

Pacing: I cap the main build at two constructs per lesson. Fast finishers add a meaningful branch or sound effect with a short justification. For support, I keep an unplugged fallback—sequencing cards that mirror the program—so everyone hits the same concept.

Homework that sticks: a “predict–run–reflect” sheet where pupils read a small code snippet, predict the output, then run and describe what changed using target vocabulary. I close the loop with a quick review in ClassPods the next morning so I can group by who confused selection with repetition.

If budget checks affect whether you’ll try this whole setup, the current options are on the pricing page; I shared that with our coordinator before rolling it out.