What actually works for Coding in Years 7–9 on the Cambridge path

Monday of Week 3, my Year 7 computing class could animate sprites in Scratch, but half the room froze when I asked them to trace an algorithm with test data. That’s the Cambridge signal. In Stages 7–9, the pathway expects students to plan with decomposition and abstraction, express logic clearly in pseudocode or flowcharts, and then implement and evaluate their code. On-topic tasks (e.g., “make a game”) are fine, but they’re often light on trace tables, test plans, and the evaluation write‑up Cambridge wants.

Where I’ve seen resources miss: vocabulary (algorithm vs program), assessment style (no justification prompts), and progression (jumping to complex Python before students can model the logic). I aim for algorithm‑first, code‑second. A typical fit check for me: do students produce pseudocode, a trace table, and an evaluation paragraph? If not, I adapt. When I’m hunting for ideas that already lean this way, I start by skimming community packs for British · Cambridge Lower Secondary coding; you can nose around the category in the library and then tighten the prompts yourself. I jot what works into ClassPods so my sequence stays honest to the pathway.

In October, my Year 9s nailed the Python for a selection task but stumbled on the two-mark “explain your algorithm” item—classic Cambridge mis‑match. Now, when a colleague shares a resource, I run a few quick tests. First, learning objectives: do I see verbs like design, implement, test, and evaluate, instead of only “code” or “make”? Second, vocabulary: is pseudocode used with IF/ELIF/ELSE and WHILE as structures, not as “notes”? Third, assessment: are there trace tables and specified test data (normal, boundary, erroneous)?

I also check for a short evaluation prompt (What worked? What would you refine and why?) and evidence of decomposition (subtasks or functions). If those are present, it usually aligns with Cambridge Lower Secondary expectations. When I want a fast sanity check, I generate a draft lesson pack and skim the objectives and checks in one place—you can spin one up in a couple of minutes here. I still tweak phrasing for our department’s scheme of work, but the vocabulary and assessment cues keep my class practising the exact moves they’ll be asked to show.

Last Thursday, my Year 8s worked through selection using a “Café Discount Calculator” example. The focus was algorithm clarity first, then code, then test and evaluate—straight from our Cambridge Lower Secondary aims. Here’s my lesson structure you can lift:

• Objective (2 min): Use selection to apply a discount based on age and loyalty status; design, implement, test, and evaluate.
• Starter (8 min): Unplugged: on mini-whiteboards, students write pseudocode for: “Under 12 or over 65: 20% off; loyalty card: extra 5%.” Quick pair check.
• Main (25 min): Model pseudocode → Python. Worked example: calculate final price with nested IF/ELSE. Students adapt for a new rule: staff get 30% off, no stacking. Emphasise clear variable names.
• Formative check (10 min): Trace table for three test cases: (Child, £10), (Adult + loyalty, £12), (Staff, £15). Circulate and question.
• Plenary (5 min): Two sentences of evaluation: one success, one refinement with reason.

I keep the slides, pseudocode scaffold, and trace table printable together so I’m not juggling tabs. If you want a pre‑baked pack that you can edit to your scheme, you can generate the shell and drop in your school examples via this link. I still narrate the modelling live; ClassPods just holds the pieces in order.

Two Fridays ago I was drowning in mixed attempts on a Stage 7 algorithm worksheet, so I wrote a rubric that mirrors how Cambridge wants evidence to look. I mark fast and give actionable comments, and students learn what “fit” means.

Algorithm design: Emerging: steps unclear or missing logic; Developing: mostly clear with minor gaps; Secure: clear, ordered, uses selection/iteration correctly; Mastery: efficient, decomposed into sensible sub‑tasks.

Implementation (code): Emerging: runs only with heavy support; Developing: runs with minor errors; Secure: runs correctly with readable variables; Mastery: robust structure, functions/procedures used appropriately.

Testing and trace table: Emerging: no or minimal testing; Developing: some normal data; Secure: normal, boundary, and erroneous data with expected/actual; Mastery: thorough table plus commentary on edge cases.

Evaluation: Emerging: vague success statement; Developing: identifies one fix; Secure: explains strengths/limitations; Mastery: justifies refinements linked to requirements.

Documentation: Emerging: missing or weak pseudocode/flowchart; Developing: mostly matches code; Secure: clear and consistent; Mastery: exemplary clarity that another student could follow.

I print this on half a page and clip it to books; if you’re planning department budgets for tools to host these templates and packs, skim the numbers on the pricing page before you pitch at the meeting.

On Thursday week, my multilingual Year 7 (Arabic, Polish, Spanish) got tangled on “selection” vs “condition,” not the code. I now front‑load a tiny bilingual glossary (algorithm, input, process, output, selection, iteration) and stick it beside the starter. Sentence frames help: “If X then Y because…”. I also label the trace table columns with icons—eye for expected, tick for actual—so lower‑proficiency students can track the flow while we talk.

For pacing, I cap modelling to 10–12 minutes, then run short cycles: try → check with me → annotate pseudocode. Early finishers extend the “Café Discount Calculator” to combine percentage + fixed discounts and write a two‑sentence evaluation. For homework, I like an unplugged brief: “Write pseudocode for a locker system with three access levels,” plus a mini trace table. For revision, I interleave one past‑style prompt weekly: justify an algorithm in three sentences. If you want starting points that already nod to British · Cambridge Lower Secondary coding, I’ve found useful seeds in the community area for Coding, then I localise the wording and examples.