Teaching computing that matters to your pupils

Many pupils struggle to see the relevance of computing in a way that doesn't apply as sharply to other subjects. Maths can lean on the obvious utility of being numerate; English on the universality of reading and writing; science can point at the world and say 'this is how it works'. Computing has to argue for itself in classrooms where some pupils already build apps in their spare time and others have not opened a laptop outside school. Getting the whole room to feel the subject matters is one of the hardest things the discipline asks of its teachers.

This guide is for heads of computing and KS3 leads who want to build a curriculum that earns the room. It draws on the National Centre for Computing Education's Teach Computing curriculum and the practical realities of teaching the subject inside a finite timetable with mixed prior experience.

Before designing any units, write down what computing is for in your school. Not a slogan, but a paragraph a Year 10 parent could read and understand. What kind of thinking does the subject develop? What does it mean to be good at computing in 2026?

In many schools this question quietly defaults to 'preparation for the GCSE Computer Science specification', which then becomes 'lots of Python from Year 9 onwards'. That is a defensible direction for the minority who will take the GCSE, but a thin offer for the majority who will not. A curriculum framed only around the specification tends to lose the room early.

A stronger framing weaves three threads together. First, computational thinking as a transferable habit of mind. Second, programming as the discipline where computational thinking gets tested against reality. Third, an understanding of how computers, networks and data actually shape the world the pupils live in. Pupils who get all three will be ready for the GCSE if they choose it, and equipped to think about technology critically if they do not.

If you are building or reviewing a computing curriculum, the National Centre for Computing Education's Teach Computing curriculum is the most useful resource in the English landscape. It covers KS1 to KS4, is free, and comes with lesson resources, assessments and progression frameworks. Most departments end up using some version of it.

The honest way to use it is not to lift it wholesale. The materials are designed to be generally applicable across a wide range of schools, which means they make compromises that your school may not need to make. They were also written before some of the recent shifts in the discipline (large language models, the maturing of physical computing kit) became central.

A pragmatic approach is to adopt the structure, use its progression framework as your skeleton, and supplement it with your own units where the materials do not fit your context. Schools with strong cohorts often find the KS3 sequence under-pitched; schools with weaker prior experience may need to slow specific sections down. What matters is that the choices are made deliberately and documented, rather than allowed to drift.

One of the most common confusions in computing curricula is between computational thinking and programming. They are connected but not the same. Programming is the activity of writing code that a computer executes. Computational thinking is the broader habit of breaking problems down, spotting patterns, abstracting away detail, and designing algorithms that solve them. You can do computational thinking with no computer in the room. You can write code without ever doing real computational thinking, and every GCSE Computer Science teacher has met pupils who memorise solutions without understanding the logic.

A curriculum that treats them as one thing tends to over-rotate on programming and under-rotate on the thinking. Pupils get good at Python syntax without getting good at the bit that actually transfers: The ability to look at an unfamiliar problem and find a structured way to solve it.

The table below shows how programming and computational thinking can be progressed in parallel across KS3.

The benefit of separating the two strands is that you can assess them separately. A pupil who programs fluently but cannot reason about an unfamiliar algorithm has a different gap to a pupil who can describe the algorithm clearly but stalls on syntax. Both gaps are real, and treating them as a single 'computing' weakness obscures what to actually do next.

The fastest way to make computing feel meaningful is to anchor units in things pupils recognise from outside the classroom. A Year 8 unit on networks framed around how their phones connect to TikTok will land in a way that a unit framed around abstract OSI layers will not. The technical content can be the same; the framing decides whether the room is with you.

This does not mean dumbing the content down. It means starting with a question pupils already half-care about, and using the unit to answer it properly. A few framings that tend to work: How does your phone know it is you (authentication, hashing, biometrics)? What actually happens when you press send on a message (packets, routing, encryption)? Why do recommendation algorithms show you what they do (data, models, feedback loops)?

The risk with real-world framings is that they go shallow. A unit that gestures vaguely at 'how the internet works' for six weeks without getting to specifics is worse than a tight technical unit on the same content. The framing exists to motivate the work, not to replace it. The test is whether, by the end of the unit, pupils can answer the framing question with more precision than they could at the start.

Computing classes are usually wider than any other subject in terms of prior experience. A typical Year 7 group will include pupils who have been making games in Roblox Studio for two years and pupils whose primary school had a single broken laptop trolley. Pretending the cohort is homogeneous, then teaching to the middle, tends to lose both ends.

A few design choices help. Build the early KS3 units around problems that have a low floor and a high ceiling: Tasks that everyone can start, but where the more experienced pupils can go further without being held back. Pair programming with thoughtful pairing (strong with mid-confident, rather than strongest with weakest) tends to lift the room.

Be explicit about the prior knowledge each unit assumes, and use a short diagnostic at the start to surface who has it. And treat the highly experienced minority as a resource rather than a problem: They will often produce excellent worked examples, debugging walkthroughs, and extension challenges that work better with their classmates than anything the teacher writes.

Computing has a particular memory problem. Many of its key ideas (binary, logic gates, network protocols, sorting algorithms) are abstract, taught in concentrated bursts, and then not revisited until they reappear at GCSE eighteen months later. By that point, the prior teaching has decayed and the GCSE unit has to rebuild the foundations.

The fix is to build spaced revisits into the curriculum rather than leaving them to individual teachers. The Education Endowment Foundation's guidance on cognitive science highlights spaced and retrieval practice as two of the most robust strategies, and both work better at curriculum scale than at lesson scale.

In practice this often looks like a weekly low-stakes retrieval starter drawing from a rolling pool of past topics, and a deliberate decision in unit design to revisit prior ideas in new contexts. The Year 9 unit on networks should reuse the binary work from Year 8 (in IP addressing) so the binary work is retrieved and refined, not parked. These connections do not happen by accident; they have to be designed in.

Any computing curriculum written in 2026 has to make a deliberate choice about large language models, and the choice cannot be 'ignore them'. Pupils will use ChatGPT or Claude to generate code for homework whether the department engages with it or not. The interesting question is what the curriculum does with that fact.

A few pragmatic positions tend to hold up. The tools are useful and pupils should learn to use them well, including the skill of judging when the output is wrong (which it often is on programming tasks the model has not seen enough of). They do not replace the underlying understanding, and assessment design needs to reflect that, which usually means more in-class supervised work and less take-home code. The discussion of how the tools work, what their limits are, and what their broader implications might be is itself worth a unit.

None of this is fully settled, and the right answer in 2027 may look different from the right answer in 2026. The point is to make the choice deliberately and document it, rather than letting it drift.

Computing has acute staffing realities most other departments do not. The subject is famously hard to recruit for, and many schools rely on a mix of specialists, IT teachers transitioning into computing, and occasional cover. A curriculum that only works in the hands of a confident specialist is not a curriculum; it is a personal scheme of work.

In practice this means investing in shared resources: Worked example decks, code-along solutions, misconception documents, debugging guides, and assessment mark schemes with model answers. Some units will lean heavily on teacher subject knowledge (anything involving abstract reasoning about algorithms), and CPD calendars should be aligned so the subject knowledge is in place before the units are taught.

The NCCE's CPD offer is genuinely strong in this area, particularly the subject knowledge courses for non-specialists. Building those into the department's CPD plan is one of the highest-leverage things a HoD can do for a stretched team.

A computing curriculum is a particularly living document because the discipline moves faster than most. Tools change, languages change, the technical landscape pupils live in changes. Annual review is not optional in computing the way it sometimes is in older disciplines.

A workable cadence is to lock the curriculum for the year, run it as designed, and review formally at the end with the assessment data and the team's experience in hand. The temptation to keep tinkering mid-year is strong in computing, especially when something new and exciting appears in the wider world. The discipline of finishing the year as planned, then changing things deliberately, tends to produce better curricula than constant in-flight adjustment.