The ideas behind these tutorials. Some are well supported by research; some are our best guess, and we'd like to hear whether they hold up in your classroom.
Programming is about as cumulative as maths. Variables make loops useful, loops and decisions make functions worth having, and objects only make sense once data and functions feel familiar. Yet coding is usually taught with far less structure than maths, often in short units and often by teachers who aren't programmers. Researchers have suggested this is why programming classes so often split into students who "get it" and students who are lost: early success makes the next idea easier, and an early gap makes it harder (Robins, 2010).
Our answer is a clear sequence. Each lesson teaches one new idea and says which earlier ideas it relies on, and we aim to check this automatically, so a lesson never quietly uses something nobody has taught. Nothing here is locked and students can start anywhere, but the lessons are written to be done in order.
Maths and science build on earlier ideas too, in a different shape. Science runs as several strands side by side, each with strong links inside it (particles before atoms before reactions), so moving between strands is safer than skipping ahead within one. Coding is closer to a single chain, where almost any skipped step matters. So the checks differ by subject. In maths, each lesson is meant to check the skills it relies on with a quick question rather than take them for granted. In science, the risk is often a picture students already hold in a different form, such as thinking seasons come from the Earth's distance from the Sun, so each lesson is designed to start with a prediction that tests the picture it relies on. We're also working towards checking these links against the curriculum's own map of which ideas depend on which.
A computer doesn't show its working. To program well, students need a picture of what happens at each step of a program, which researchers call a notional machine (Sorva, 2013; Fincher et al., 2020). The apps students use every day hide those steps completely, so we try to bring them into view: students predict before they run, trace how a value changes each time round a loop, and click the line where a program goes wrong.
Every lesson has the same parts (a prediction to commit to, something to try, checks with feedback, teacher notes), but each subject puts them in the order that suits it.
Coding: reading before writing. Coding lessons follow PRIMM (Sentance, Waite & Kallia, 2019): Predict, Run, Investigate, Modify, Make. Reading and predicting code comes first, and writing it comes last. We think this matters more now that AI tools can write code, because knowing whether a program is right, and why, is the skill that's left. But it's hard to judge code you could never have written yourself, so the Make step still matters: it's where students build their own picture of how a program works.
Maths: a worked example at the centre. Maths lessons run Predict, Try, Worked example, Vary, Practise, Make, drawing on several well-tested ideas: from objects and pictures to symbols, worked examples that fade into independent work (Sweller & Cooper, 1985), small steps with frequent checks (Rosenshine, 2012), changing one thing at a time so the structure shows, and short mixed practice that brings back earlier ideas. Students try the idea on a model first; new knowledge appears only in the worked example.
Science: the 5E model. Science lessons follow Engage, Explore, Explain, Elaborate, Evaluate (Bybee et al., 2006). They start by drawing out what students already think, let them test it in a model, and only then explain. Each lesson is a short concept tutorial to sit beside practical work, never instead of it.
Each idea comes as a live example to try, a short clip with captions (the sound is optional, since headphones aren't always available in class), a picture of what the code makes, and an explanation in plain words. Cheat sheets and worksheets print for work away from the screen, and every lesson has teacher notes, slides and answers.
Students build a button from a rectangle and a click check before they meet an app framework that does it for them. Later courses do the same with game characters, built from turtles before students meet a real game engine. Seeing what sits underneath a finished tool makes the tool less like magic, and easier to learn.
There are no accounts, no class tracking and no locked lessons. Progress is saved only in each student's own browser. We'd rather the tutorials be easy to pick up than another system to manage.
These ideas are a starting point. If something works in your class, or doesn't, or you'd like a lesson that isn't here yet, please let us know.
For how lessons are made, checked and kept private, see Behind the scenes.