Computational thinking in primary school: what it is and how it develops

Evidence grade: PROMISING. The construct is well-articulated and programming instruction demonstrably teaches programming; the bolder claim — that computational thinking transfers broadly to general problem-solving — has weaker, mixed support and should be made cautiously. We teach it for what it reliably delivers, not for the transfer halo.

"Computational thinking" entered common currency with Jeannette Wing's 2006 essay: the thought processes involved in formulating problems so their solutions can be carried out by an information-processing agent. Its roots are older — Seymour Papert used the phrase in Mindstorms (1980), and his LOGO classrooms are the tradition every turtle and block language descends from. For primary purposes, the useful decomposition of the idea (echoed in England's curriculum, CSTA's standards and Australia's Digital Technologies) is four practices: decomposition (break the problem down), pattern recognition (spot the repeating structure), abstraction (name the pattern, hide the details), and algorithms (express precise, ordered instructions).

What the evidence supports

Children can learn real constructs young. The block-programming literature (Scratch and successors — Resnick et al., 2009; reviews in Grover & Pea, 2013 and Shute, Sun & Asbell-Clarke, 2017) documents primary-aged children successfully using sequences, loops, conditionals, and events, with age-appropriate scaffolding.
Blocks are a genuinely good on-ramp. Comparative studies (e.g., Weintrop & Wilensky's high-school comparisons) find block-based introductions produce better early outcomes and attitudes than text-first, with the known trade-off that transition to text must be deliberately taught rather than assumed.
The constructs ladder has a natural order: sequencing → repetition (fixed counts) → conditionals (sense and decide) → condition-controlled repetition (while) → decomposition into named procedures (functions). Each rung is learnable when the previous is stable — a prerequisite structure that maps cleanly onto mastery learning.
Debugging is pedagogy, not remediation. Papert's deepest insight, borne out by classroom research since: treating bugs as information ("the program did exactly what you said, not what you meant") teaches the precision that is the whole point. Prediction-before-running and fix-the-broken-program tasks have good support as instructional moves.

The transfer question, honestly

Does learning to program make children better general thinkers? This is the field's oldest overclaim — studied since the LOGO era, where early enthusiasm met sobering evaluations (transfer appeared only with instruction explicitly designed for it). Modern reviews (Shute et al., 2017; meta-analytic work since) find some near-transfer to closely related reasoning, with far-transfer claims remaining thin and design-dependent. Our reading: teach programming because algorithmic literacy is valuable in itself — a fourth literacy for a computational world — and treat any general-thinking benefits as a possible bonus, never the selling point.

What the evidence doesn't say

It doesn't say syntax should come early. The hard part for novices is the semantics of control flow, not semicolons; blocks exist to spend working memory on the former (cognitive load).
It doesn't say "one construct exposure" equals learning — a conditional met once in one puzzle is performance; the construct needs varied, spaced, forced use (tasks solvable without the construct teach the construct to nobody).
It doesn't support unplugged-only programs as equivalent: unplugged activities are excellent introductions, but the feedback loop of a running program — the machine as an unforgiving, infinitely patient critic — is where precision gets learned.

In the classroom

Climb the ladder in order, and verify each rung by tasks that require it — if a loop task is solvable by copy-paste of moves, it's a moves task wearing a loop costume.
Make prediction routine: "what will this program do?" before every run; explanation after. The gap between prediction and behavior is where mental models grow.
Celebrate bug hunts explicitly — the emotional reframe (bugs are clues, not failures) is half the discipline.
Teach the same construct in two costumes — a loop that moves a robot and a loop that draws a spiral force the abstraction loop out of either costume.
Say "precise and unambiguous" until it's a catchphrase — the machine's literalism is the concept the whole subject rests on.

How Wiz Kids applies this

Two parallel realms climb the ladder in different costumes — a maze golem (movement blocks) and a drawing turtle (strokes, growing steps as first variables) — through sequences, counting loops, sense-and-decide conditionals, while-walks, and named procedures met twice (named runes, then named charms). Our task validators mathematically prove each construct is required by its task (a conditionals world with a path that avoids all walls in every variant would be rejected at authoring time), prediction is rewarded by efficiency scoring, and runs are unlimited and unpunished because experimentation is the method.

References

Papert, S. (1980). Mindstorms: Children, Computers, and Powerful Ideas. Basic Books.
Wing, J. M. (2006). Computational thinking. Communications of the ACM, 49(3).
Resnick, M., et al. (2009). Scratch: Programming for all. Communications of the ACM, 52(11).
Grover, S., & Pea, R. (2013). Computational thinking in K–12: A review of the state of the field. Educational Researcher, 42(1).
Shute, V. J., Sun, C., & Asbell-Clarke, J. (2017). Demystifying computational thinking. Educational Research Review, 22.
Weintrop, D., & Wilensky, U. (2017). Comparing block-based and text-based programming in high school computer science classrooms. ACM Transactions on Computing Education, 18(1).

© 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.