Teacher Guides

Three hours of Sunday marking. One student who read the comments. This guide is about why that happens and what to do instead. The evidence on written marking is unusually clear: detailed comments on programming work are not an evidence-based practice, and the alternatives are better for students as well as less work for teachers.

• Why most programming feedback fails: timing, volume, and direction, with a real code example
• Live marking: how to give feedback while the code is still alive, with no marking afterwards
• Whole-class feedback: read everything, write nothing, teach the patterns
• Structured peer review: the three-question card that makes students do the reading
• The focused mark: one lens, one comment, thirty minutes instead of ninety
• Three ready-to-use tools: feedback checklist, peer review card, focused mark scheme

Most programming homework programmes fail for the same four reasons: tasks are too vague to start, students get stuck alone with no support, checking is inconsistent, and feedback arrives too late. This guide is a redesign from those failure modes outward. The same programme that failed in the early years, rebuilt into one that runs itself.

• Why most programming homework fails and the four design properties that fix it
• Honest answers to the two questions teachers always ask: access at home and AI
• The five-element brief, with a complete ready-to-use example
• Three checking methods that take under five minutes each and work at scale
• A term-by-term sequence for building the programme from scratch

Three teachers marking the same piece of code against the same mark scheme can give marks six points apart, and all three can justify their mark. This guide starts with that problem and works through to a practical framework: what fair assessment in programming actually means, how to fix calibration without writing a longer mark scheme, and how to design tasks that cannot be completed without understanding.

• What consistency, validity and transparency each mean, and why they are different problems
• The moderation experiment to run with your department in twenty minutes
• How to build anchor examples: worked example with three annotated student programs
• Task design that closes the gap AI tools have opened: three adjustments, five minutes each
• A four-step marking framework that makes the process faster as well as fairer

Nobody tells you how hard it is to teach Computer Science until you are already doing it. This guide covers what a first-year CS teacher most needs to know: not everything, but the things that actually matter, including the survival skills that do not appear in any training and a realistic term-by-term map of what the year looks like.

• The four things that matter most in year one (and the dozens that can wait)
• The most common mistakes and how to avoid them before they cost you
• The five topics most likely to catch you out and why, including low-level architecture and encryption
• Classroom management specific to computer rooms: the things nobody tells you
• A term-by-term map from September through to the end-of-year letter you should write to yourself
• Where to find genuine help: CAS, NCCE, Isaac CS, and examiner reports