Your child doesn't need to become a software engineer just because they learn to code. And they certainly don't need to start Python at five. One of the biggest mistakes we make with children's technology education is assuming that getting to a "real" programming language sooner means a child is progressing faster. It often doesn't. For a five-year-old, making a cartoon character move across a screen because they arranged three instructions in the right order is programming. For an eight-year-old, creating a Scratch game with lives, scores and increasingly difficult levels is programming.

For a twelve-year-old, debugging a Python program that refuses to work is programming. And for a sixteen-year-old, cleaning a dataset, training a machine-learning model and discovering that their model performs terribly on new data is also programming. The tools change. The underlying thinking develops gradually. So instead of asking:

"What programming language should my child learn?"

A more useful question is:

"What should my child be able to create at this stage?"

That distinction changes the entire learning journey.

The coding journey we recommend

Think about children's coding education as a progression:

These ages are guidelines, not entrance requirements. A highly motivated nine-year-old may move much faster; a twelve-year-old who has never programmed should not feel embarrassed starting with Scratch.

That's actually one of the principles I would emphasize throughout the Undoschool blog:

Stage 1: Ages 5–7 — Don't start with syntax

At this age, the objective isn't Python. It's understanding that: I give a computer instructions → it follows those instructions → changing my instructions changes what happens. That's a surprisingly powerful idea.

Start with ScratchJr

ScratchJr is specifically designed for children aged 5–7. Children connect graphical blocks to create interactive stories and games, rather than typing commands. A child might create: When green flag pressed → move → jump → say "Hello!" → play sound. It looks like play. Underneath it are the beginnings of sequencing, events, cause and effect, decomposition, debugging and computational thinking. But here's where many coding programs go wrong. Don't turn ScratchJr into worksheets. Ask the child:

"Can you make a story about a dinosaur that gets lost?"

Or: "Can you make a cat chase a mouse?" Now programming becomes a creative medium rather than another subject.

What mastery looks like

Before moving on, the child should be comfortable creating something independently. Not completing 47 predetermined puzzles. Creating. That distinction will become important throughout this roadmap.

Stage 2: Ages 7–9 — Move from coding puzzles to creating games

This is where I would introduce full Scratch. Scratch is primarily designed for ages 8–16, although younger children also use it with parental help. Children can create games, animations and interactive stories and share them with the Scratch community. Another excellent option is Code.org. Its elementary offering currently includes pre-reader material for K–3 and CS Fundamentals Express for grades 3–8, alongside environments such as Sprite Lab. I see the two serving slightly different purposes. Code.org is excellent for learning concepts systematically.

Scratch is excellent for becoming a creator. Ideally, children experience both.

Don't stop at "move the sprite"

A good Scratch progression might be:

Now the child encounters programming concepts naturally. Why do we need a variable? Because we need to remember the player's score. Why do we need a conditional? Because: IF player touches enemy → lose one life. Why do we need a loop? Because the enemy needs to keep moving. This is very different from teaching:

"Today we're going to learn variables." The project creates the need for the concept. Then the concept solves the problem. That is how I'd want Undoschool's educational philosophy to come through.

Stage 3: Ages 9–11 — Become a game and app creator

This is where coding becomes much more exciting. Instead of simply completing coding exercises, children should start building things other people could actually use or play. There are several possible branches.

Stage 4: Ages 11–14 — Cross the bridge to text-based programming

This transition deserves an entire section because it is where many children quit. A child who is brilliant in Scratch suddenly types:

if score > 10
print("You win!")

…and gets an error because they forgot a colon. Their reaction is often: "I'm bad at Python." They're not. They've moved from a system where syntax errors are almost impossible to one where punctuation matters. So don't restart computer science from zero. Translate what they already know. Scratch: repeat 10 becomes Python:

for i in range(10):
    print(i)

Scratch: if score > 10 becomes:

if score > 10:
    print("You win!")

The child realizes:

"Oh. I already understand this. Python is just another way of expressing it."

That is the bridge.

I wouldn't declare one universally "better." Choose according to what the child wants to build.

And eventually strong students can learn both.

The Python Software Foundation itself maintains a dedicated education hub with open educational resources for teaching and learning Python.

Stage 5: Ages 12–15 — Stop doing tutorials. Build software.

This is another place where children's coding education frequently stalls. A student has "learned Python." They know variables, loops, functions, lists and classes. Then ask them: "Build something." And they freeze. That is the difference between knowing programming syntax and being able to create software. So now the curriculum changes.

Stage 6: Ages 13–16 — Learn how programmers actually work

Now I'd introduce concepts that many children's coding courses ignore:

And increasingly: reading someone else's code. This is where a student begins moving from: "I know Python." toward: "I can build software." That second statement is much more valuable.

Stage 7: Ages 14–18 — Data Science and Machine Learning

I would be especially careful here. There is currently enormous pressure to put "AI" into children's education. But a child doesn't become good at AI by memorizing prompt-engineering tricks. There are two useful AI journeys.

AI literacy can start early.

Children can explore what machine learning actually does without needing advanced mathematics or Python. For example, Google's Teachable Machine lets learners experiment with training simple models interactively without coding. That creates intuition:

But AI engineering comes later. For that, I'd build the following staircase:

At this point Kaggle Learn becomes extremely useful. Its current learning catalogue moves from Python into Pandas, visualization, SQL, introductory and intermediate machine learning, feature engineering, deep learning, computer vision and other specialist areas. Even its Python course provides a nice example of the transition: syntax, functions, Booleans, lists, loops, strings/dictionaries and external libraries, followed by paths into machine learning and Pandas.

The complete mastery pipeline

This is the diagram I ultimately want parents to remember:

There isn't one perfect coding path for every child. A Minecraft-obsessed ten-year-old, an artistic ten-year-old who wants to animate characters, and a mathematically curious ten-year-old may all enter computer science through completely different doors. What matters is that the door gets them creating. Once that happens, we can progressively introduce deeper concepts, more powerful tools and eventually professional programming languages.

Then Undoschool becomes the place that helps a child move through that journey.