When Is a Child Ready to Move From Scratch to Python?
Not an age. Four readiness signals, what Scratch has already taught your child, and the three things that genuinely change on the day they type real code.
In this article
Parents ask me a version of this every week, and it usually arrives as a slightly apologetic aside at the end of a call. "He's enjoying Scratch. But when does he start real coding?"
I want to take the question seriously rather than swat it away, because there is a genuine one hiding inside it. The apologetic bit I will deal with first, though, because it is wrong and it changes the answer.
Your child is already doing real coding. A ten-year-old building a two-level platform game in Scratch is running loops inside conditionals, handling events, holding four variables in their head and debugging their own logic. Rename that in Python and any developer would call it a program.
The real question is not when the coding starts. It is when typing becomes worth its cost, and that has an answer you can actually check.
What your child has already built
Sit down with your child's Scratch project sometime and look at what is actually in it.
There will be a sequence, things happening in a fixed order. There will be a repeat block, which is a loop. There will be an if block, which is a conditional. There will be a when-flag-clicked hat, which is event handling, a thing many computer science undergraduates meet for the first time at eighteen.
Those four ideas are the load-bearing walls of every program ever written, in any language. They do not get relearned in Python. They get re-spelled.
That is the part parents underestimate. Moving to Python is not starting over at the bottom. Your child arrives already knowing what they are trying to say and has to learn a new way of saying it, which is a far smaller job and a much less discouraging one.
What blocks are not trying to teach
There are things a blocks environment deliberately does not put your child through, and it is worth being precise about what they are, because they are not concepts.
In Scratch, you cannot misspell a command. The block already says what it says. You cannot put a block in a place it does not belong, because it will not snap there. The environment removes an entire category of failure so that a child's attention stays on the logic.
That is a design decision, not a limitation. The removed failures are costs, not skills. Nobody becomes a better thinker by mistyping a word.
But those costs buy something. Once you are typing, you can say things blocks cannot easily say, reach libraries somebody else wrote, work with files, and build programs longer than a screen. The trade is real in both directions, which is exactly why the timing matters.
Blocks remove the spelling so a child can spend everything on the thinking. That is a feature, and it expires on its own.
The three things that change on day one
When a child types their first real program, three things change at once. Knowing them in advance is most of what stops the first week going badly.
First, spelling counts and so does space. Python cares about indentation, which means the gap at the start of a line is part of the instruction. This is genuinely strange and every child trips on it. It is also the single most common reason a first lesson ends in tears, and it has nothing to do with intelligence.
Second, the computer starts talking back. In Scratch a wrong program does something wrong. In Python a wrong program often refuses to run at all and prints a short, blunt line of English explaining why. Children find this alarming for about a fortnight and then find it useful forever, because it is the machine telling them where to look.
Third, the work becomes a file. It gets a name, it gets saved somewhere, it can be opened tomorrow and sent to somebody. Projects stop being a thing inside a website and start being objects your child owns.
Here is the same script your child has probably already built in blocks, typed out:
score = 0
for turn in range(3):
guess = input("Pick a number 1 to 5: ")
if guess == "4":
score = score + 1
print("You got " + str(score) + " right!")Four signals, none of them a birthday
Most children are ready somewhere around nine or ten, but the age is a description of the average, not a rule about your child. These are the things I actually look at.
The first is the ceiling. Your child starts asking Scratch for things it does not do gracefully, and gets visibly irritated when the answer is a workaround. Wanting more than the tool gives is the strongest signal there is, because it supplies the motivation to get through the awkward fortnight.
The second is reading. Python is read far more than it is written, and error messages are English sentences. A child who is still working hard at reading itself will spend all their attention there and none on the logic. This is the signal that matters most and the one most often skipped in favour of age.
The third is that they can already trace a script. Ask your child to explain their Scratch project from the green flag downward. If they can walk it in order and point to where it goes wrong, they are debugging, and that is the skill that makes typed code survivable. The markers for this are laid out in how do I know my child is actually learning to code.
The fourth is frustration tolerance. Can your child sit with something broken for five minutes without shutting the laptop? Typing brings a lot more small failures per hour. A child who is not ready for that does not learn Python slower. They learn to avoid it.
What you can do this week
There is no rush here, and moving early costs more than moving late. A child who stays in blocks another six months arrives at Python stronger, not behind.
These three will tell you where your child actually is, without asking them to do anything they would not do anyway.
- Ask your child to add one feature to an old Scratch project. If they hit a wall and get annoyed at the tool rather than themselves, the ceiling is showing.
- Type one line of Python together and get it deliberately wrong, so the error message arrives while you are sitting next to them rather than alone.
- Ask them to read that error message out loud. Not fix it, just read it. That is the whole test.
Final thought
The honest answer to when a child should move is: when they are pulling rather than being pushed, and the four signals above are how you tell those apart.
What I would avoid is treating the move as a promotion. It is not a graduation from a children's version to the adult one. It is picking up a tool with sharper edges because you have finally got something to build that needs it.
If your child is in a Kerala classroom and the sticking point looks like vocabulary rather than logic, the thing to read first is learning to code in Malayalam. And if you are wondering whether any of this holds up now that AI writes code, we answered that separately in why kids should still learn to code in the age of AI.
If you would rather just see where your child sits, book a free trial class and tell us they are coming from blocks. We will pitch it to what they already know. One hour, no card needed.
