Three Ways Kids Look Like They're Learning to Code

Last updated: August 2026

A child can be learning to code, fully engaged, and enjoying every session while you have no reliable evidence they are retaining any of it. Across 14 one-on-one sessions in July 2026 I tracked three teenage students and found three completely different versions of this problem. All three were motivated. All three showed up ready. None of the three could be confirmed to have learned what the session covered, and each needed a different fix.

This is the thing I would most want a parent to understand about tutoring. A disengaged child is easy to spot. These three were not disengaged, which is exactly why the gaps ran for weeks before I caught them.

Key Takeaways

• Engagement is not evidence of learning. All three students were genuinely enthusiastic and two of the three had significant unverified gaps.
• Pattern one is the watching student: concepts keep advancing while the hands never move, and nothing gets built.
• Pattern two is the agreeable student: they say yes to everything, so agreement carries no information at all.
• Pattern three is the articulation gap: the code works, the understanding is real, and they cannot put it into words.
• Each pattern needs a different check. One needs the keyboard, one needs a demonstration, one needs an explanation.

Table of Contents

• Why Motivation Hides This
• Pattern One: The Student Who Watches
• Pattern Two: The Student Who Agrees
• Pattern Three: The Student Who Cannot Explain It
• The Three Checks Side by Side
• What Parents Can Watch For at Home
• Frequently Asked Questions
• The Bottom Line

Why Motivation Hides This

In 20 years and more than 200 students, the failure mode I was trained to look for was boredom. A bored child fidgets, goes quiet, stops turning up. That is a visible problem and it has visible fixes.

What I tracked in July was the opposite situation, and it is far harder. Three students who wanted to be there, who talked enthusiastically about what they were building, and whose parents were pleased with the progress. Two of them had gaps I could not see for several sessions, because everything on the surface looked like success.

The uncomfortable conclusion is that enthusiasm is not a proxy for understanding, and a tutor who takes enthusiasm as evidence is not doing the job. Neither is a parent who takes "she loves the lessons" as confirmation that the lessons are landing. They are different questions.

Pattern One: The Student Who Watches

One of my students spent three consecutive sessions on an advanced topic she had chosen herself and genuinely cared about. Over those three sessions we read the source material together, worked through the architecture, and covered concepts well beyond her level.

At the end of three sessions she had created nothing. No folder, no files, no notes. Not because she was lazy, but because the sessions had drifted into a shape where I was building on my screen while she watched and asked questions.

The concepts kept getting richer. The practice stayed at exactly zero.

The moment that made it undeniable was when she told me plainly that roughly one word in every five sentences was one she did not know. She was following the shape of what we were doing and losing the detail, and she had been polite enough not to interrupt.

The fix is the keyboard. For this student the rule is now that she builds on her machine while I watch, not the reverse, and every session has to end with something that exists: a folder created, a file in place, one real piece of output. Concepts are not the deliverable. An artifact is.

A parent put the working version of this better than I have:

"Best part is showing something, then letting you try it before explaining again. Unlike group lessons where you just copy, this method makes things click and helps you understand deeply." Anthony, parent of a 12-year-old learning Python

Show, then hand it over, then explain again. The middle step is the one my sessions had quietly dropped.

This is also the pattern most likely to look good to a parent. The vocabulary a watching student picks up is genuinely impressive. They can talk about the material fluently. They just cannot do it.

Pattern Two: The Student Who Agrees

My second student is 16 and one of the most capable I teach. He is also the most agreeable person I have taught. Yes, okay, sounds good, all session, every session.

That politeness destroys the main tool a tutor uses. When I ask "does that make sense?" and get a yes, I have learned nothing, because the yes arrives whether or not it makes sense. He is not being dishonest. He is being courteous, and he will not volunteer confusion.

What eventually proved the learning was real had nothing to do with anything he said. It was two things he did. First, he arrived at a session having independently added three features to his project that nobody asked for: difficulty levels, a two player mode, and a moving background. Second, at the end of another session, instead of a general yes, he volunteered a specific thing he had not previously known, that you could save your work to a repository directly from the command line.

Both of those are evidence. Neither is agreement.

The fix is to stop asking and start requiring. I no longer ask this student whether he understands. I ask him to do the step while I watch, or to tell me back what we just did in his own words. Where I want a read on a session, I ask a concrete question rather than an open one, because "what did you learn today" gets a real answer and "make sense?" never will.

Pattern Three: The Student Who Cannot Explain It

Cameron, 15, has been with me for over 40 hours. He is one of my strongest students and he is building a 2D fighting game with hand drawn characters, attack animations, and a combo system.

In July we moved from conditional logic into loops. He could make every piece of code work. He could predict what a program would print before running it, correctly, repeatedly. He understood it. What he could not do was say it out loud. His own description of the problem was blunt: he is bad at explaining things.

This one is different from the first two, because the learning is genuinely there. But it still matters, and here is why I do not let it slide. Asking someone to narrate their reasoning is such a reliable way of exposing what is really going on that usability researchers built an entire method around it, described by Nielsen Norman Group as thinking aloud. If a student cannot put a process into words, I cannot tell the difference between real understanding and pattern matching that happens to be producing right answers. And more importantly, neither can he. Being able to compress a complex idea into simple language is the test that tells you whether you actually own it.

Cameron is a strongly visual and artistic thinker who naturally expresses ideas by drawing them, so I was careful to frame this as a skill worth training rather than a deficiency. The homework I set was not more code. It was to explain one specific piece of filtering logic in his own words, either written down or as a voice note.

The fix is to make the explanation the assignment. Cognitive scientists call the general principle behind this retrieval practice, and the researchers at The Learning Scientists maintain an accessible summary of why pulling information out of your head beats putting more in. Their companion write-up on elaboration, explaining ideas in your own words and connecting them to what you already know, describes almost exactly the homework I set Cameron.

The Three Checks Side by Side

Pattern	What you see	What it looks like to a parent	The check that works
Watching	Concepts advance, nothing gets built	Impressive vocabulary, fluent conversation	Hands on the keyboard, one real artifact per session
Agreeing	Constant yes, no questions asked	Smooth, cooperative, no complaints	Have them perform the step or explain it back
Cannot articulate	Code works, words do not come	Quiet, sometimes reads as not knowing	Make the explanation itself the homework

The pattern I find most instructive is that the agreeing student and the articulate-but-silent student can look identical in a session and are opposite problems. One says yes and may not know. The other says "I don't know" and does.

What Parents Can Watch For at Home

You do not need to understand the code to spot these. Three questions do most of the work.

1. Ask to be shown, not told. "Show me what you made this week" separates the watching student from the building student in about thirty seconds. If the answer is a description rather than a screen, that is your signal.
2. Ask them to explain one small thing. Not the whole project. One piece. "What does that line do?" A child who understands it will simplify. A child who does not will either recite or change the subject.
3. Notice whether anything happens between sessions. This is the single best indicator I have found. A student who touches the project without being told is learning. A student whose project is identical from one week to the next may still be enjoying the lessons, and that is worth something, but it is not the same thing.

None of that requires technical knowledge. It requires asking for the artifact rather than the account.

Frequently Asked Questions

How do I know if my child is really learning to code? Ask them to show you something they built and to explain one small part of it in their own words. Building plus explaining is strong evidence. Enthusiasm and vocabulary on their own are not, because both can be present when very little has been retained.

My child says the lessons are great but nothing seems to change. Is that normal? It is common and it is worth raising. In my July tracking, one student went three sessions on a topic she cared about and produced nothing, purely because the sessions had drifted into watching rather than doing. A good tutor will restructure once this is named.

Should my child be doing work between coding lessons? Something, even small. Between-session activity is the most reliable single signal I have found of genuine engagement with the material rather than with the lesson. If nothing is happening, the sessions need to end with a concrete commitment instead of a general plan.

My child understands the code but cannot explain it. Is that a problem? It is a real gap but a promising one, because the understanding is already there. I treat it as a skill to train rather than a failure, often by making the explanation itself the homework. A voice note works as well as anything written.

Is a quiet child who says "I don't know" doing worse than a confident one? Often the opposite. A child who admits confusion gives you something to work with. A child who agrees with everything gives you nothing, and their gaps can run for weeks unnoticed. I would rather teach the first one.

Can group classes catch these patterns? Much less reliably. All three of these were caught by watching one student closely over several sessions. In a group the watching student and the agreeing student are close to invisible, because the class keeps moving whether or not any individual is following it. This is one of the clearest arguments for one-to-one tutoring over a class format.

Related Articles

• Is 1-on-1 Coding Tutoring Worth It?, the wider case for close attention over scale.
• What 30 Sessions of 1-on-1 Coding Actually Look Like for a Kid, how progress accumulates when the checks are in place.
• When Coding Makes Kids Upset: A Parent's Playbook, what to do when the difficulty becomes visible rather than hidden.

The Bottom Line

Across 14 sessions with three motivated teenagers I found three separate ways a student can look like they are learning without any confirmation that they are. The watching student collects vocabulary. The agreeing student collects nods. The articulate gap hides real understanding behind silence. None of them are motivation problems, which is precisely why they survive so long. The answer in every case is to ask for a demonstration rather than an assurance.

Not sure whether your child is building or just watching? Book a free Discovery Call and I will tell you which of these patterns I would expect to see and how the first few sessions would test for it.