How I Plan and Mark IB · MYP Coding Without Losing Weeks

Week 3, Term 1, my Year 9 group proudly demoed guessing games that “worked” — until I asked for the client, the success criteria, and how they tested input errors. Silence. That’s the gap I see when materials teach syntax but skip MYP Design. Coding here isn’t a worksheet of for-loops; it’s a problem framed by a Global Context, a user, and evidence across Criteria A–D. Criterion A pushes inquiry and analysis, B demands feasible designs, C is about creating with quality, and D requires evaluation against the brief.

Plenty of on-topic packs miss this fit. They’ll say “learn functions,” but there’s no design specification or test table. I don’t bin those outright; I wrap them with an authentic brief and a reflection scaffold so students can hit strands i–iv. I also park my inquiry questions and success criteria where I can reuse them in ClassPods, then browse for ideas that feel like they could wear an MYP jacket with minimal tailoring. If you’re hunting for community-built prompts that can be reframed around a client and context, start in the coding category here.

Last Monday in moderation, our Design team compared two Python lessons: both covered conditionals, but only one felt MYP-fit. The winning one named a user, attached a Global Context (Scientific and technical innovation), and mapped tasks to Criteria A–D. That’s what I look for before I bring anything to my class.

My simple checks: does the resource use MYP language (criteria letters, 0–8 bands, command terms like “justify”, “evaluate”)? Is there a tangible client or audience and a design specification students can quote? Can I see a plan for testing (input sets, expected/actual results, edge cases) and a place for iteration notes? Are reflection prompts tied to strands, not generic “what went well”?

If I can tick three of those before I pour coffee, I’ll adapt it. If not, I’ll build a skinny version myself: brief on one slide, success criteria on another, and a tiny rubric that mirrors the descriptors. When I’m short on time, I spin a draft pack in ClassPods so I can fiddle with prompts, assessment notes, and reflection stems in one place — you can try a quick prototype here.

Tuesday, Week 5, my Year 8s built a Caesar cipher encoder. It’s just complex enough to spark discussion about users, design specs, and testing, and it lines up neatly with the Design cycle. Here’s how I run it when I need a clean, MYP-shaped hour.

Objective: Students will implement a Caesar cipher in Python and evaluate it against a stated design specification.

• Starter (8 min): Mini-brief: “A class librarian needs to hide quiz answers using a simple shift cipher.” Elicit success criteria (letters only? keep spaces? handle uppercase?).
• Main task (32 min): Worked example live-code: encode one word with a shift of 3, then generalize. Students adapt to handle spaces and punctuation gracefully.
• Formative check (10 min): Partner test table with edge cases: empty string, ‘Zoo’, negative shift, shift>26. Record expected/actual.
• Plenary (10 min): Quick reflection linked to Criteria B and D: “Which design choice improved usability most? What would you refine next?”

I keep the brief, success criteria, and a tiny rubric in ClassPods so I can reuse them and track reflections across groups. If you want to generate a lesson pack scaffolded like this, you can start one in about two minutes here.

Two Fridays ago I marked 28 projects in a row and didn’t wilt because I used the same one-page rubric I’ve been tuning. It mirrors MYP Design but speaks coding plainly, so students can self-assess before I ever pick up a pen. Feel free to lift it and tweak the phrasing to match your school’s handbook.

Criterion A — Inquiring and Analysing: Identifies a real user and need; cites 2–3 comparable solutions; states a focused problem. Top band evidence: concise user profile + specific pain points; limitations acknowledged.

Criterion B — Developing Ideas: Clear design specification (inputs, outputs, constraints); annotated algorithm (flowchart or pseudocode); plan with milestones. Top band evidence: measurable criteria (e.g., “handles uppercase/lowercase”), rationale for choices.

Criterion C — Creating the Solution: Structured, readable code; version history notes; testing during development. Top band evidence: functions with meaningful names, comments, and incremental commits; adjustments logged.

Criterion D — Evaluating: Test table with edge cases; comparison to specification; next steps justified. Top band evidence: mismatch analysis tied to user needs; prioritized improvements.

If you’re budgeting for departmental roll-out and want to see what’s included beyond my DIY approach, the breakdown is on the pricing page. I still keep this rubric parked in ClassPods so it travels with the unit.

My Year 7 bilingual group (Spanish/Arabic home languages) surprised me last term: their code ran fine, but reflections were thin. The fix wasn’t lower expectations; it was language scaffolds and time splits that respected both strands and syntax. I now pre-teach a micro-glossary (input, output, validation, iterate) with sentence stems. When students write design specs or evaluations, they can respond in their strongest language first, then translate key sentences with a partner so the thinking doesn’t evaporate.

For pacing, I build two tracks: a core worked example with must-have tests, and an “extend” lane (e.g., handle non-letters in the cipher, or add a decode function). Homework mirrors the day: one short coding prompt plus a reflection question tied to a criterion strand. I also assign tiny revision cards: command-term definitions, typical edge cases, and a screenshot of a good test table. If you want a pool of prompts to adapt for homework and revision, the community coding category is a decent browse starting point here.