My IGCSE Coding Scheme: What Works and What to Fix

Last Friday in Week 5, my Year 10s proudly showed me a Python “while True” menu they’d copied from a video. It ran, but it didn’t read like IGCSE. We rewrote it into REPEAT…UNTIL with clear sentinel values and suddenly their dry runs made sense. That’s the heart of it: British IGCSE coding isn’t “whatever works,” it’s algorithms expressed in spec-friendly structures, then translated to a classroom language.

I plan units around pseudocode keywords (IF…THEN…ELSE, CASE, WHILE, REPEAT, FOR), 1D arrays, input validation, modular decomposition with procedures/functions, and testing via trace tables. I cut or park content that eats time but won’t surface in exam questions: fancy libraries, full OOP, or UI work. When I do show Python, I mirror pseudocode: use integer division, be explicit with indices, and name subroutines to match decomposed steps from IPO diagrams. I’m not anti-flair, I’m just protective of weeks 20–28 when Paper 2 practice ramps up. For classroom-ready prompts that stay on this track, I dip into the coding category and filter hard for IGCSE fit in the community library. ClassPods lets me keep those prompts side-by-side with my exam-style worksheets.

Two weeks before mocks, I caught my Year 11s using zero-based array talk and “print” as a verb in answers—straight from a slick tutorial sheet. It looked fine until we tried a trace table with 1-based indexing and “OUTPUT” as the command. Since then, I run fast alignment checks before anything hits the photocopier.

My non-negotiables are simple:

• Vocabulary: OUTPUT/INPUT, INTEGER/REAL/STRING/BOOLEAN, MOD/DIV, and consistent array indexing in examples and model answers.
• Structures: All three loops used correctly, with sentinel or count-controlled examples that trace cleanly on paper.
• Decomposition: Named procedures/functions that match the IPO stages; parameters shown clearly.
• Testing: Every task includes a trace table or test plan with normal/boundary/erroneous data.
• Assessment style: One or two questions written exactly like Paper 2 stems (“Write an algorithm…”, “Complete the pseudocode…”, “State and justify…”).

If a worksheet nails Python but fudges exam language, I bin it or rework it. When I’m short on time, I’ll generate a draft task, then tweak terminology to our spec using an AI draft tool like this. A five-minute scrub here saves a week of unlearning.

Last Tuesday, my Year 10s kept mixing validation with verification in coding tasks. I built a lesson to lock both down using pseudocode first, then a short Python mirror. I drafted the slides in ClassPods, kept command words visible on every example, and it finally clicked.

Topic: Input validation and test planning with trace tables. Worked example: “Canteen Token Checker” (accepts 5-digit tokens starting with 3; rejects others; outputs reason).

• Objective (3 min): State what “validation” is and list two types we’ll implement (length, format).
• Starter (7 min): Unplugged: three sample tokens; students decide pass/fail on mini whiteboards; quick “why”.
• Main (25 min): Build pseudocode with INPUT, length check, first-character check, and a loop to re-prompt. Then show a Python mirror that matches each line.
• Formative check (10 min): Trace table two paths: valid first try; invalid twice then valid. Include boundary case (starts with 3 but 4 digits long).
• Plenary (5 min): 3-question mini quiz: define validation vs verification; name two checks; spot-the-bug in pseudocode.

I keep the worksheet and trace grid short so we can mark live. If you want a scaffolded pack of slides, worksheet, and answers in the same flow, you can spin up the skeleton from here and tweak the tokens context to your school.

On the first Monday after half-term, I realised my mixed-ability Year 10s needed clearer targets than “get better at algorithms.” I now hand out a one-page rubric/tracker for any coding task, written in IGCSE language, and we shade it each week.

IGCSE Coding Rubric (use for Paper 2 practice and class coding)

• Algorithm design: Clear IPO outline; uses correct control structures; decomposes into named subroutines. Secure / Developing / Not yet.
• Data handling: Appropriate types; consistent array indexing; uses MOD/DIV where needed. Secure / Developing / Not yet.
• Pseudocode accuracy: Correct keywords (INPUT/OUTPUT, IF/ELSEIF/ELSE, WHILE/REPEAT/FOR); indentation and end markers. Secure / Developing / Not yet.
• Code mirror: Classroom language mirrors pseudocode line-for-line; names and logic match. Secure / Developing / Not yet.
• Testing: Trace table with normal/boundary/erroneous cases; fixes evidenced. Secure / Developing / Not yet.
• Reflection: Two sentences: what failed first, what change fixed it.

Use: Students tick targets before starting; I highlight one box for feedback only. I keep a shareable copy in ClassPods so I can duplicate it per task, and you can generate your own version with your house style in a minute.

Last month my Year 11 bilingual set stalled on “concatenate” and “boundary.” Once we built a tiny bilingual glossary on the board (concatenate = join; boundary = edge value), their trace tables jumped. I now plan for language like I plan for loops.

For mixed-language groups, I build dual-column examples: pseudocode left in exact exam terms; right-hand notes in plain classroom English or the class’s second language. Pair-program with roles (Driver drafts pseudocode; Navigator checks spec words). For pacing, chunk by structure: one short task per loop type, then a “mix and match” problem. Keep Python mirrors tight and literal to avoid students copying library calls they can’t justify on paper.

Homework stays simple: 15–20 minute code-reading first (spot the output, find the bug), then one 6–8 line pseudocode write-up with a 4-row trace. Revision turns those homeworks into a weekly “Paper 2 mini”: two stems, one trace, one definition. I’ve templated bilingual slides in ClassPods so I can quick-switch terms and regenerate variants for homework when groups split.