Scratch Programming in Primary School: Is It Worth the Class Time?

Every school year, I speak to primary school teachers who have been asked to "teach Scratch" without much guidance on what success actually looks like. I also speak to parents who've seen their children spend a term making a cat walk across the screen and wonder whether anything useful was learned.

The honest answer is: Scratch is an excellent tool that is frequently used in ways that waste its potential. Let me break down what's actually going on.

What Scratch is designed to do

Scratch (developed by MIT's Media Lab) is a visual, block-based programming environment. Instead of typing code, students drag and snap together instruction blocks. The visual metaphor removes the barrier of syntax — a misspelled variable name won't crash the programme — and lets students focus on the logic.

This design choice is deliberate and smart. For children who have never programmed before, the cognitive load of learning syntax simultaneously with learning logic is overwhelming. Scratch separates those challenges. First learn to think algorithmically. Then, later, learn to write that thinking in formal code.

What Scratch develops when used well: sequencing (steps happen in order), loops (repeat this while that is true), conditionals (if this happens, do that), event handling (when the user clicks, start this), variables (store and change a value), and basic input/output. These are foundational computing concepts that appear in every programming language students will ever use.

Where Hong Kong schools often go wrong

The most common problem I see is Scratch being used as a colouring book rather than a problem-solving environment. Students are given a template, told to change some values and add a sprite, and the result is declared "a Scratch project."

This produces children who can navigate the Scratch interface and know roughly where the Motion and Sound blocks live. It does not produce children who can solve problems using code. The distinction matters enormously.

A well-designed Scratch activity starts with a problem: "Create a quiz that asks three questions and tells the user their score." The child has to figure out how to store the score (variables), how to check answers (conditionals), how to repeat questions (loops). The actual block-dragging is the smallest part of the activity.

A poorly designed Scratch activity starts with a finished project and asks children to modify it. The child learns almost nothing about decomposing a problem because the problem was already decomposed for them.

I've observed this distinction in HK primary classrooms, and in my experience the problem-first approach is still the minority. It requires more confident teachers and more comfortable students. It's messier and takes longer. But it's where the learning actually lives.

The evidence on what Scratch transfers to

There's reasonable research evidence that Scratch, when taught with a problem-solving emphasis, improves mathematical reasoning and logical thinking in primary-age children. The specific skills that transfer include sequencing (relevant to maths procedures and science methods), conditional reasoning (if-then logic relevant to maths proofs and comprehension inference), and debugging — which is really just a systematic approach to finding and fixing errors, applicable to everything from essay editing to experiment analysis.

The evidence is weaker for creative projects (make anything you want) and template modification activities. Learning to be creative in a medium you don't understand is difficult. The creative work that matters comes after some competence has been built.

What to look for in your child's school

Ask the class teacher these questions. You're not interrogating — you're trying to understand the approach.

"What kinds of problems do students have to solve in Scratch?" If the answer focuses on projects ("they make games," "they make animations"), push further. "Do they decide how to build the game, or are they given most of the structure?" The latter is template work.

"How much time do students spend planning before they start coding?" Good Scratch teaching involves time away from the keyboard. Flowcharts, sketches, lists of steps. If coding starts immediately, planning isn't happening.

"What happens when something doesn't work?" The answer should involve debugging — trying to find the problem rather than starting over. If "starting over" is the common response to failure, the debugging habit isn't being built.

What you can do at home

If your child's school is using Scratch in a limited way, a few sessions at home can make a real difference. Scratch is free at scratch.mit.edu and requires only a browser.

The approach I'd recommend: give your child a clear, specific goal rather than a blank canvas. "Build a programme that asks you two maths questions and tells you whether you got them right." "Create a story with at least three scenes where the user can click to move forward." The constraint is the point — it forces them to think about what the programme needs to do before they start.

Resist the urge to help when they're stuck. The frustration of not knowing how to do something, and then working it out, is exactly where the learning happens. Your role is to ask questions ("What needs to happen next? What block might do that?") rather than show solutions.

The verdict

Scratch is genuinely worth the class time — but only if it's used to teach problem-solving rather than produce polished output. A term of debugging a difficult project is more valuable than a term of making a beautiful one. The mess, the iteration, the frustration and eventual satisfaction of something that finally works — that's the whole point.

If your child says "I'm stuck and I can't figure it out," that's Scratch working exactly as intended.