Why We Teach Children to Code With Blocks Before Writing Code

What is Scratch?

Scratch is a coding platform built by MIT that has been quietly teaching children the fundamentals of computer science for nearly two decades, through coloured blocks that snap together like logic made to be physical.

Most people outside of education may not have heard of it. Most people inside the education industry know exactly what it is. And I want to explain why we use it, because the reason matters more than the tool itself.

The problem with starting with syntax

If you are in IT or programming, you would know that text-based coding languages are unforgiving in a very specific way. A missing semicolon breaks everything. A single character out of place and nothing runs. The error message tells you something went wrong but rarely tells you what you were actually trying to think.

For an adult learning to code, that friction is manageable. You have enough experience with rule-based systems to debug your way through it. You know the difference between a language error and a logic error.

For a child encountering programming for the first time, they spend their mental energy on the complicated syntax. The tool gets in the way of the thinking.

But building in Scratch allows a child to work with the same fundamental concepts as any programmer. Conditions. Loops. Variables. Event triggers. The difference is that these concepts are represented as physical blocks that can only connect in ways that make logical sense. You cannot build a broken structure by accident. If your logic is wrong, the code still runs. It just does the wrong thing.

And doing the wrong thing, it turns out, is a much more useful starting point than not running at all.

What building a game actually teaches

In our AI Vision Arcade Lab workshop, our junior inventors built a space navigator game controlled by their body movements. Move left and the spaceship moves left. Jump and it fires. Dodge and it rolls.

It may sound simple. But it is not!

To make a game respond to real-world movement, a child has to think through a series of logical problems. What happens if the player holds the position? The game needs a loop. What if two things happen at the same time? The code needs to handle multiple conditions simultaneously. What if the spaceship goes off the edge of the screen? That is a boundary condition and it needs its own rule.

None of these problems are explained in advance. They emerge from the process of building. The game tells the child what is missing by not working the way they expected. The child fixes it. The game tells them something else is missing. They figure out how to fix that too.

By the end of the session, they have not just built a game. They have built the rules behind the game. They understand, from direct experience, that every interaction in every piece of software they have ever used was a decision someone made. A condition someone wrote. A loop someone designed.

That understanding changes the way they see technology permanently.

Why this matters beyond the workshop

We live in a world that is increasingly shaped by code. The recommendation algorithm that decides what a child watches next. The game that decides when to give them a reward. The filter that changes how they look in a photo.

A child who has built a simple version of these systems understands something that most adults do not: that the behaviour is not inevitable. It was designed. Someone chose to make it work that way. And someone could choose to make it work differently.