The constructs ladder: sequencing loops, conditionals and functions

Evidence grade: the misconception research is solid; the sequencing is strong consensus practice. What makes each construct hard is well-documented (novice-programming research has catalogued misconceptions for decades). The ladder's exact ordering has less trial evidence than its ubiquity suggests — it's convergent craft across curricula, organized here with the difficulty research attached.

Every programming curriculum climbs roughly the same ladder — sequence, repetition, selection, abstraction — because each rung genuinely presupposes the ones below. What curricula differ on, and what the research actually speaks to, is what makes each rung hard and what counts as having climbed it. The second question has a sharp answer this page keeps returning to: a construct is learned when the child uses it because the problem demands it — not because this week's worksheet is about loops.

The rungs, with their real difficulties

Sequence — the machine does exactly what's written, in order, nothing more. The difficulty is not intellectual but dispositional: children arrive expecting the computer to infer intent (the literalism lesson), and one week of a truly literal executor teaches what a term of explanation doesn't.

Repetition — first counted loops (do this 4 times), then conditional loops (walk until blocked). The documented misconceptions: children write the repeated block out longhand (not seeing the pattern — which is why par rewarding the loop matters), and conflate the two loop types. The deep version of this rung is recognizing repetition in the problem before expressing it in code.

Selection — if/then, the rung where programs stop being scripts and start sensing. The classic misconceptions: believing the condition is checked continuously (rather than at its moment), and if-blocks as decoration a program reads politely. The teaching implication is the design rule below: selection taught on problems solvable without it teaches selection to nobody.

Input and state — programs that ask, remember, and vary: the rung where the same program does different things on different runs, which is most children's first real encounter with generality. Variables carry their own catalogued misconceptions (the box metaphor's limits; assignment vs equality later, in text).

Abstraction — naming a chunk of behavior and invoking it: functions, the ladder's summit and computational thinking's payoff. Define-once-use-everywhere is the same idea children meet as styles in documents — worth saying out loud, because transfer needs the connection named.

The design rule: constructs must be forced

The ladder's biggest implementation failure is optional constructs: a worksheet "about loops" whose task a child can brute-force stepwise. The child completes it, the tick is recorded, the concept was never exercised — usage recorded as learning, the recurring bug. The fix is structural: tasks where the target construct is the only path — worlds too long to hand-walk (loops), goal-varying runs the same code must handle (selection and input: if the world changes between runs, hard-coding cannot work), par budgets no longhand solution fits. Verification can be mechanical — prove the shortest loop-free solution exceeds the block budget; prove the multi-world goals diverge — and should be, because "the task forces it" is a checkable property, not a hope.

What the evidence doesn't say

It doesn't fix ages to rungs — the ladder is a dependency order, climbed at mastery pace; a year-3 child on selection and a year-6 child on repetition are both in the right place.
It doesn't require code for rung one — unplugged sequencing (recipe cards, robot-teacher games) is real work on the literalism disposition.
It doesn't end at functions — events, data, decomposition-at-scale follow; the ladder here is the primary-years span.

In the classroom

Audit tasks for forcedness: could a determined child brute-force this without the week's construct? If yes, the task teaches completion, not the construct.
Let longhand happen, then let par name it — the child who writes twelve move-blocks and then discovers the loop has learned repetition better than one told upfront.
Say the cross-domain names: loops are the spreadsheet's fill-down, functions are the document's styles — the abstraction rung is everywhere in computing, and naming it recruits transfer.

How Wiz Kids applies this

The Charm Forge and Rune Scribe climb exactly this ladder, with forcedness as a validator guarantee: gem worlds are proven to require their loops, ask-blocks are forced by goal-varying multi-worlds where hard-coding provably fails, and pars are BFS-verified where stepwise and simulation-verified where structural — the "task forces the construct" rule implemented as build-time mathematics rather than authorial intention.

References

Sorva, J. (2013). Notional machines and introductory programming education. ACM TOCE, 13(2) — the misconception literature organized.
du Boulay, B. (1986). Some difficulties of learning to program. Journal of Educational Computing Research, 2(1) — the classic difficulty catalogue.
Grover, S., & Pea, R. (2013). Computational thinking in K–12. Educational Researcher, 42(1) — the constructs-in-context case.

© Glu IO Pty. Ltd. — Wiz Kids (wiz.kids). Link freely; republication requires permission — see terms. Found an error in our reading of the research? We correct fast: tell any teacher piloting Wiz Kids.