How Do I Know My Child Is Actually Learning to Code?
Coding has no exam and no report card. What real progress looks like at month one, month three and month six, on both the blocks and the Python track.
In this article
Three months into her son's classes, a mother in Kochi asked us the question every parent gets around to. "He seems happy. But is he learning anything, or is he just playing?"
It is a fair question, and school has trained all of us to answer it with a number. Maths has a test. English has a composition with a mark on top. Coding has neither, so parents end up reading their child's face and guessing.
You do not have to guess. Progress here is very visible once you know which behaviours to watch. The catch is that the behaviours are different depending on whether your child is working in blocks or typing Python, and most advice online only describes one of them.
So here is both, month by month.
Coding does not come with a report card
In a maths class, progress announces itself. Your child either got the sum right or did not, and the exercise book keeps score on your behalf.
Coding hides its progress inside a finished thing. Your child shows you a game. It works. You cannot tell by looking whether they built it from nothing, followed a worksheet line by line, or opened a friend's project and changed the colours. All three produce a working game.
This is harder still to read in a blocks class, because a child dragging blocks around looks exactly like a child playing. No typing, no visible strain, no page of rough work. Many parents quietly file the Scratch months under warm-up and assume the real learning starts when the typing does.
It is not a warm-up. A child building a two-level game in Scratch is doing sequencing, conditionals, event handling and debugging, which are the same four ideas a Python student is wrestling with. The thinking is the same thinking. Only the notation differs, and the blocks student often runs ahead on the thinking precisely because they are not spending attention on spelling.
So the markers below come in two columns. Same six months, two different things to look for.
Month one: can they start without you?
The first milestone has nothing to do with code. It is about who opens the laptop.
A child who is learning will start the thing themselves. They find the project, remember roughly where they left off, and are moving before you have finished asking. A child who is not yet learning waits to be set up, every single time, and waits again at every small obstacle after that.
In a blocks class, the specific thing to watch for is your child using a block nobody showed them. The teacher demonstrated move and say. Your child goes rummaging in the sound category on their own and makes the cat meow. Nobody asked for the meow. That is curiosity turning into initiative, and at this stage it is the whole game.
On the Python track the equivalent is typing a line and running it without checking whether they are allowed to. The child who types a print statement, runs it, then immediately swaps the word for their own name and runs it again has understood something real about what a computer is for.
Neither of these is about ability. Both are about permission, and children work out very quickly whether a class is the kind where you are allowed to poke at things.
Month three: the day something breaks
Month three is where you find out whether it is real, and the test arrives on its own. Something breaks.
Every child hits a proper bug around this point. The sprite walks off the screen and never comes back. The score counts downwards. The program runs and prints nothing at all. What your child does in the ninety seconds after that is the most useful signal you will get all year.
A child who is learning reads. They look at what went wrong, then look at their own work for the part that matches. They may well not fix it. Reading it at all is the milestone.
A child who is not learning yet deletes the lot and starts again, or shouts for a grown-up before looking at anything. Both are completely normal in month one. Still happening in month three usually means the class is moving faster than they are.
In blocks, the same milestone looks different but means the same thing. Your child opens their script and traces it from the green flag downward with a finger, saying the steps out loud. Compare that with dragging blocks around at random hoping the problem goes away. One is debugging. The other is shaking the box.
If you want the longer version of why reading and fixing is the durable half of this skill, we made that case in why kids should still learn to code in the age of AI.
Here is a small broken program. The bug is exactly the kind a nine-year-old makes, rather than the kind a textbook invents. Run it and it cheerfully announces that you collected minus five stars.
Your child does not have to fix it to clear this milestone. They have to notice that minus five stars is not a thing anybody has ever collected, and go looking for the minus sign. Noticing is the skill. The fix is a keystroke.
A child who can read a broken program is learning. A child who deletes it and starts again is still guessing.
score = 0
for star in range(5):
score = score - 1
print("You collected " + str(score) + " stars")Month six: building what nobody asked for
By month six the signal changes character completely. It stops happening in class and starts happening at home.
The marker is an unassigned project. Your child builds something no teacher set, usually slightly silly, almost always about their own life. A quiz about their friends. A program that picks who gets the front seat. A Scratch animation of the family dog doing something the family dog would never do.
This matters more than anything on a syllabus, because it means code has stopped being homework and become a material, like clay or Lego.
The second month-six marker is explanation. Ask your child how their project works and listen for whether the answer has an order to it. "First it asks your name, then it checks if it matches, then it adds a point." That sentence is the sound of a child who understands their own program. "You just press this and it works" is the sound of a child who copied it.
If your child is in a blocks class and hitting these markers comfortably, a different question becomes worth asking, and we went through it properly in when a child is ready to move from Scratch to Python.
What you can do this week
None of this asks you to understand the code. It asks you to watch three specific things and ask about them out loud.
Pick one evening. Twenty minutes is plenty, and doing it once tells you more than a term of report cards would.
- Ask your child to open their most recent project and quietly time how long it takes them to find it. Under a minute means they own their work.
- Ask them to break their own program on purpose, then put it back. A child who can break something deliberately understands how it holds together.
- Ask them to teach you one thing from their last class, quickly and badly. Whatever they reach for first is what actually landed.
Final thought
That mother in Kochi got her answer in about four minutes, and not from us. She asked her son to break his own game on purpose. He changed one number, watched the sprite shoot off the top of the screen, laughed, and put it back without being told how.
That is the report card. It simply does not arrive in an envelope, and it never will.
If your child is learning in English but thinking in Malayalam, some of these markers show up later than they should for reasons that have nothing to do with coding. We wrote about that in learning to code in Malayalam.
And if none of the six-month markers are showing up at all, that is worth acting on rather than waiting out. Book a free trial class with a different teacher and see whether the room was the problem. One hour, no card needed.
