A six-year-old drags four "move forward" blocks into a row, presses play, and watches the character stop one square short of the flag. He adds four more. Now it walks past the flag and off the edge of the path. He deletes everything and starts again from one block. What he is wrestling with is not coding in any sense a curriculum would recognise. It is the discovery that the number of blocks on screen matches the number of steps exactly, and that the computer will not round in his favour.
That is a real conceptual step, and it takes months. Everything afterwards is built on it. The order below is stable across children and across tools, and skipping ahead in it produces a child who can copy a tutorial and change nothing in it. A year either side of these ages is ordinary.
Sequencing comes first and lasts longer than adults expect
Roughly four to seven. Adults underrate this stage because to them it is invisible. The skill has three parts: order changes the outcome, each instruction is separate and discrete, and the machine does what is written rather than what was meant.
The unplugged version beats any app. Ask your child how to make toast, then follow the instructions with deliberate literalness. The bread stays in the bag because nobody said to open it. Five-year-olds find this very funny, and the joke is the lesson.
Working capacity is the real constraint. At five, most children plan and hold three to five steps ahead; by seven, ten or fifteen. Beyond a handful they need to see the sequence rather than hold it in their head, which is exactly what a row of blocks provides.
You know it has landed when the child predicts before pressing play. "It'll stop just there", said correctly, means sequencing has been internalised. Endless guess-and-check with no prediction means it has not, and at five that is normal. The common confusion is reading the program as a description of the goal — "it goes to the flag" — rather than a list of actions.
Loops arrive when repetition becomes annoying
Roughly six to nine. The mistake is teaching loops as a topic. Teach them as relief. Let the child place twelve identical blocks by hand, let it be tedious, and only then show the repeat block. A loop feels like a gift after the tedium and like an arbitrary rule before it.
Off-by-one errors are universal and last for months. Repeat three versus repeat four will be wrong about half the time, and it is not carelessness — counting boundaries is genuinely difficult, and adults get it wrong too. The fix is physical: count aloud, finger on the screen, one square per number.
Nested loops, usually eight to ten, are a bigger jump than they look: they require holding an inner count while tracking an outer one. Plenty of capable eight-year-olds hit that wall, drop it, and clear it a year later with no extra teaching. Pushing rarely helps.
Conditionals need the idea that a program asks questions
Roughly seven to ten. Until now every program the child wrote did the same thing on every run. A conditional breaks that: the program asks a question at a specific moment and the answer can differ each time. That is a new mental model, not just new syntax.
Two confusions come up constantly. The first is reading "if" as "when". Children expect the check to run continuously, like a smoke alarm listening all night. In most block environments it happens once, at the moment that line runs — which is why "if touching the wall, turn" placed outside the loop never fires. That misunderstanding alone accounts for an enormous share of stuck projects. The second is treating the else branch as the wrong answer rather than the other true case.
Combining conditions with and, or and not comes later, usually nine to eleven, and is harder than it looks. Much of the difficulty is language: everyday English "or" means one or the other but not both, while in code it includes both. Children are not being illogical; they are applying the English meaning correctly.
Decomposition is last and worth the most
Roughly nine to thirteen. This is taking "a game where a fish eats smaller fish and grows" and turning it into a list: move the fish with the arrow keys, make small fish appear, detect overlap, grow, keep score, end the game. Then building those one at a time, testing each before connecting it.
Before this stage children build linearly. One script grows until something breaks, and then nothing can be debugged because no part was ever isolated. You see the transition when a child names their own block, uses it in two places, and tests a piece alone before wiring it in.
You can nudge it earlier with one repeated question: "what is the smallest piece we could get working first?" That question is essentially the whole skill, and unlike loops or conditionals it transfers visibly outside coding — to essays, to a science project due Friday.
| Concept | Typically lands | Looks like when it clicks | Usual sticking point |
|---|---|---|---|
| Sequencing | 4–7 | Predicts the result before pressing play | Reads the program as the goal, not the steps |
| Loops | 6–9 | Notices repetition without being told | Off-by-one counts |
| Conditionals | 7–10 | Can predict both branches in advance | Expects the check to run continuously |
| Nested loops | 8–11 | Plans inner and outer counts separately | Losing the inner count |
| Decomposition | 9–13 | Names and reuses their own blocks | One long script that cannot be taken apart |
| Text syntax | 11–14 | Reads an error message and fixes it alone | Tolerating red text without giving up |
Block-based is not baby coding
Blocks remove typing, spelling, semicolons, case sensitivity and the wall of syntax errors that stops beginners before they reach a single idea. They do not remove order, state, scope, event handling, conditions or debugging — nearly all of the actual difficulty of programming. Calling that a simplified version confuses notation with content.
Visual and node-based programming is also not confined to children. Unreal Engine's Blueprints build commercial games; Blender's geometry nodes, Node-RED and much audio and visual-effects tooling work the same way. Nobody calls those beginner toys. Connecting boxes instead of typing lines is a decision about representation, not difficulty.
Moving to text usually goes smoothly between eleven and thirteen for a child with a solid block foundation, because they already own the concepts and only need the notation. The hard part of text is not the keyboard — it is looking at a screen full of red error output and not concluding you are bad at this. That tolerance is easier to build when the concepts underneath are secure.
The signals are behavioural, not chronological: the block project has grown unwieldy, they ask for something the blocks do not offer, or they want to make something that runs outside the editor. A rushed eight-year-old pushed into Python usually spends a year fighting punctuation and learns less than they would have staying put.
Why typing speed is irrelevant
Work the numbers. A ten-year-old hunting and pecking manages twelve to twenty words a minute. A beginner's program worth writing is thirty to sixty lines, roughly twelve hundred to two thousand characters. At fifteen words a minute that is ten to fifteen minutes of typing, spread across a session where most of the time goes to deciding what to write and working out why it did something else. Typing is a rounding error. Debugging is the session.
Touch typing is worth learning in its own right — nine to eleven is a sensible window, and it pays off across all schoolwork — but it is a separate project. Treating it as a prerequisite delays every concept above by years and buys nothing.
What is worth optimising is the gap between a change and seeing the result. Short feedback loops keep children inside the change-and-check cycle, and that cycle is where nearly all the learning happens. A setup that takes forty seconds to run quietly teaches a child to stop experimenting.
Progress here is slower and stranger than any curriculum makes it sound. A child can spend three weeks apparently repeating the same maze puzzles and then jump two concepts in a weekend. Finished projects are a poor measure of it. Better signs, none of which produce anything to show relatives:
- Predicting the output before running it.
- Reading their own program aloud, line by line, to find the bug.
- Changing one thing at a time instead of changing everything.
- Saying "it should have turned there" — which is a hypothesis, and hypotheses are the job.
- Being bored by repetition, which is the loop instinct arriving early.
A ten-year-old who can look at a broken program, guess which line is wrong, change one thing and check the result has the skill. Whether it is dragged blocks or typed words is a detail of presentation.