How I Build GCSE Coding Lessons That Match AQA and OCR

On Monday period 3, my Year 10 set mixed up OCR’s pseudocode with Python syntax while solving a simple input/selection task. That’s the gap: lots of resources teach coding, fewer teach it the GCSE way. In the British · GCSE pathway, coding lives inside “Algorithms” and “Programming techniques,” but it also leans on logic (Boolean operators), data types and structures (strings, integers, arrays/lists), and program constructs (sequence, selection, iteration). Ethics and computational thinking show up too, but they’re assessed differently from write/run code.

The fit issues I see most: US-style AP CS lessons (great, but not our command words), project-first tutorials that never touch trace tables, and worksheets that skip dry-run thinking. I need materials that show GCSE-style pseudocode, use plain-English variable names, and include small, mark-scheme-friendly explain/justify items. I keep a shortlist of spec-fit tasks and, when I’m stuck, I scan the community area to see how others frame the same construct in exam terms—sorting the noise helps me hold a clean line on alignment. If you want to browse what other teachers share, the community area is here: community coding resources.

Last Thursday after school, I trialled a new worksheet for my Year 11 AQA group and ran three quick checks. First, vocabulary: does it say selection/iteration and use GCSE-style pseudocode with clear INPUT, OUTPUT, IF...ELSE, WHILE, and indentation? Second, assessment feel: can I add a two-mark “Explain why…” and a three-mark “Justify your choice…” without changing the task? Third, traceability: is there room for a dry run with a table of variables/outputs?

Two extras help me catch near-misses: (1) constants vs variables must be explicit, and (2) boolean logic should use the operators my board prefers (AND/OR/NOT, not just Python’s truthiness). If a resource passes these, I’ll adapt it—swap American spellings, align data types to the spec list, and add a mini-plenary that mirrors exam wording. When I’m short on time, I draft a quick alignment stub and build from that; if you want a head start, you can spin up a draft lesson pack aligned to your board here. ClassPods gets the skeleton right; I still fine-tune examples and command words.

On Tuesday Week 5, my mixed-ability Year 10s were wrestling with nested IFs. I built the hour around one worked example: “Ticket Price Calculator” (student age and student card decide discount). The aim was to keep syntax secondary and reasoning primary.

Objective: Use selection to solve a two-condition problem and justify chosen logic in GCSE terms.

• Starter (8 min): Three mini true/false prompts on AND/OR/NOT. Quick pair talk, then cold-call.
• Main input (10 min): I model pseudocode for Ticket Price Calculator, narrating indentation and branch tests.
• Guided practice (15 min): Students complete a trace table for two test cases; we compare paths.
• Independent (15 min): Convert the pseudocode to Python. Higher group adds an ELSE IF for senior discount.
• Formative check (7 min): Two-mark “Explain why you used AND not OR.” One volunteer shares, we annotate.
• Plenary (5 min): Exit ticket: identify one boundary value we didn’t test and why it matters.

I drop the model, trace table template, and exit ticket into ClassPods so I can reuse next term. If you want to generate the same skeleton and swap in your own context, you can start a pack in a couple of minutes here.

Two weeks before mocks, my Year 11s kept asking, “What gets full marks?” I wrote a plain rubric that mirrors GCSE expectations without sounding like a robot. I paste this at the end of worksheets so students can self-mark before I do.

Rubric: Selection/Iteration Coding Task (10 marks)

• Algorithm clarity (0–3): 0 = no coherent steps; 1 = partial steps, missing branches/loops; 2 = complete steps with minor gaps; 3 = complete, ordered steps using GCSE-style pseudocode and indentation.
• Correctness (0–3): 0 = fails key tests; 1 = works on trivial case; 2 = works on provided tests; 3 = handles boundary values and typical errors.
• Justification/explain (0–2): 0 = no/irrelevant reasoning; 1 = attempts to explain choice of AND/OR or loop; 2 = clear, spec-style justification using correct vocabulary.
• Traceability (0–2): 0 = no dry run; 1 = partial table; 2 = full trace with variables and outputs aligned to tests.

Student prompts: “Explain why you chose AND or OR.” “Identify a boundary value and its expected output.” “Show a dry run for one failing test.” If you’d like a ready-to-edit version bundled with a lesson draft, you can generate one and tweak the wording using this pack creator.

On Wednesday, my bilingual Year 10 (Polish–English) group stalled on “greater than or equal to.” It wasn’t the logic; it was the language layer. I now teach with a dual-column slide: left shows the GCSE keyword and sentence stem (“Explain why you used AND”), right shows a student-friendly translation. Code comments stay in English to match the exam, but I allow planning notes in first language during ideation.

For pacing, I use staggered scaffolds: some students only fill the trace table; others must add a second test and justify logic. Homework extends the same objective—convert a short pseudocode snippet to Python and add one boundary test, then self-mark with the rubric. I keep all of this tidy in ClassPods so I can review comments and nudge groups without reprinting half the department’s paper. If you’re coordinating for a department and juggling budgets, the overview of plans and costs lives here: pricing and plans. It’s straightforward to start small with one class and scale after mock season.