Years of Coding Classes but Can't Code Alone: 5 Reasons

Last updated: November 2026

If your child has done years of coding classes and still cannot sit down at a blank editor and build something on their own, you are not imagining it, and your child is probably not the problem. A child with years of coding classes who can't code alone has usually been taught in a way that never asked them to. The story I hear from parents is remarkably consistent: some mix of a block-coding app, a year of weekly lessons, an online course and a camp or two, and no visible progression from one to the next.

The five reasons below come from conversations with parents in exactly this position, and from the first lessons that follow, where a child solves something small on their own before anyone decides where to start. Each reason comes with what to do about it. After them there is a twenty-minute check you can run at home to tell a skills gap from a confidence block, and the questions I would put to any next program, ours included.

Key Takeaways

• Years of classes without independence is usually a format problem, not a talent problem. Many beginner programs never ask a child to produce code alone.
• Most new programs sensibly start at lesson one, so a child who switches programs can relearn the same beginner material three or four times.
• A finished class project is weak evidence. If the child typed it along with an instructor, the instructor made every decision in it.
• A short home check (blank file, small task, no help) tells you whether you are looking at missing skills or missing confidence. They need different fixes.
• Before paying for the next program, ask how they assess, what the milestones are, and how often your child solves something alone.

In this post: The restart loop · The project that was never theirs · Placed by birthday · Taught to the middle · The blank editor nobody asked for

1. The restart loop

Every coding program has to start somewhere, and since a new one does not know your child, it usually starts at the beginning. That is a reasonable decision for the program. Across three or four programs it becomes a trap: the child does variables, loops and if statements again, in a new tool, with a new instructor, and the course ends around the point where new material would have begun.

Here is the shape of it. This is an illustration of the pattern, not any one family's history:

Read down the middle column. The child meets the same three or four ideas in every row and rarely gets past them. Each restart also feels good at first, because the early lessons are familiar, which makes the loop hard to spot from the outside.

Camps are the extreme version. A one- or two-week camp packs a lot into a short burst and then stops. UCLA's Bjork Learning and Forgetting Lab, which studies exactly this, puts the problem plainly: "performance during training is not always representative of long-term learning." The same page notes that "Massed repetitions lead to greater short-term performance, but impair long-term performance." A camp can look like a breakthrough on Friday and be mostly gone by the next class. I covered how to get more out of one in how to pick an online summer coding camp worth the money.

The fix: Stop switching for the sake of it. Choose the next program on whether it will start from where your child actually is, and stay long enough for the material to move past the beginner unit.

2. The project that was never theirs

This is the one that surprises parents, because the evidence looks so good. Your child comes home with a working game. It runs. It has their name on it. Surely that means they can code?

Not necessarily. Here is a typical beginner project, the kind of thing a class builds together in a lesson or two (my own example, written for this post):

import random

secret = random.randint(1, 20)
guess = 0

while guess != secret:
    guess = int(input("Guess a number from 1 to 20: "))
    if guess < secret:
        print("Too low")
    elif guess > secret:
        print("Too high")

print("You got it!")

Count the decisions in those ten lines. Use the random module. Pick the range. Start guess at a value that can never be the secret, so the loop runs at least once. Use a while loop rather than a for loop, because nobody knows how many guesses it will take. Write the condition that ends it. Turn the typed answer into a number. Check "too low" before "too high".

In a typed-along lesson, the instructor makes every one of those decisions and the child types the result. The program works because the instructor's thinking was correct. The child goes home with a game and none of the decisions that made it. Teens teaching themselves from videos hit the same wall, which I described in tutorial hell.

Those decisions are exactly where children trip when they finally work alone. The slips that come up again and again in a child's solo challenges are small ones: a missing colon, a loop with a forgotten condition. The condition is precisely the part a typed-along lesson never asked them to decide.

Typing along has real value. It builds familiarity with an editor and with what code looks like. I wrote about where it helps and where it stops in the first time a student writes code from scratch. The trouble starts only when a whole program, or several programs in a row, never go beyond it.

The fix: Treat a finished class project as a starting point, not proof. Ask your child to change one rule in it without help (only five guesses allowed, say) and watch what happens.

3. Placed by birthday, not by skill

Many programs place children by age, or by which course they have completed. Both are guesses. Age bands are a sensible first guess, and we publish them for our own courses too, but age tells you nothing about what a particular child can do. "Completed Level 2" tells you what your child sat through, not what they can produce. Children the same age reach the same coding milestones at very different times, even within one family.

A child with several programs behind them is the hardest case to place this way, because their history pulls in two directions. They know the vocabulary. They can tell you what a loop is and name the parts of an if statement. On a form or in a chat, they sound like an intermediate. Put them in front of an empty file and they may be much closer to a beginner. Placed by what they can say, they land too high and struggle. Placed by age, they often land back in the beginner unit and the restart loop begins again.

What works is a skills check: a short, unfamiliar task done alone, early, before anyone decides where lessons begin. That is how our lessons start. A small challenge in the first lesson shows in a few minutes what three past programs cannot: which ideas your child can use without help, which ones they only recognize, and where the real gap is. Wherever it turns out to be, that is where the teaching starts, and the parts that are already solid get skipped.

The fix: Before the next program starts, ask for a skills check that involves your child writing code, not describing it. Placement by age, by a form, or by a certificate from the last program is still a guess.

Most of these five disappear when one person reads your child's code every week and keeps asking them to work alone. That is most of what our 1-on-1 sessions are.

4. Taught to the middle

A class has to move at one speed, and that speed is set for the middle of the room. That is not a criticism of teachers. It is arithmetic. A sixty-minute lesson shared by eight children works out, at best, to seven or eight minutes of individual attention each, and in practice less, because the instructor also has to teach the group.

The pace lands differently depending on where your child sits:

A child who has been through several beginner programs can sit in the top and bottom rows at the same time. The content is familiar, so they are bored. The moment the class asks for something new and unguided, they are behind, because familiarity was never the same as being able to produce it. From the outside, that child looks like they are coasting. From the inside, they are quietly copying the parts they cannot do.

To be fair to the format, group classes suit some children well. Some are more motivated working alongside friends, and the cost per hour is lower. I set out when a class is the right call in is 1-on-1 coding tutoring worth it. But if your child has already done the group route more than once without becoming independent, another class at the same pace is unlikely to change the result.

The fix: If you stay with a group, choose a small one and ask the instructor what your child does when they finish early and when they get stuck. If neither answer involves your child working alone on something new, the class will repeat the pattern.

5. The blank editor nobody asked for

This is the reason underneath the other four. In a lot of programs, nobody ever asks a child to open an empty file and build something small on their own. Not as an exam, just as a normal part of a lesson. Without that moment, nobody, including the child, actually knows what they can do.

The usual substitute is the question "Did you understand?" It always gets a yes. That is not because children are dishonest. A beginner does not know what they do not know, so yes is the honest answer from where they are sitting. I wrote about the most polite version of this, the student who agrees with everything, in three ways kids look like they're learning to code.

Research on how people learn points the same way. In a 2013 review of ten common learning techniques, published by the Association for Psychological Science, John Dunlosky and colleagues rated practice tests and spreading study out over time as high utility, and found rereading to be "of surprisingly low utility." I think of typing along with an instructor as the coding version of rereading. A blank-editor challenge is the coding version of a practice test.

In our lessons it is simply called the challenge. Before moving on from any new idea, the child solves a small problem with it alone while the tutor watches. Getting it wrong is fine. The point is to see the gaps while they are still small. From the functions section onward, the challenges become pieces of a larger project the child builds across the section, and at the end of each section there are short puzzles to do alone between sessions, with the tutor reachable for questions. Tahir, a parent whose son learned Python with us, wrote in a review that the lessons come with "great challenges that help tremendously."

That is what years of classes often miss. Not more content. More moments where the child has to produce something with nobody's code to follow.

The fix: Make solo work a weekly habit, not an annual test. Five or ten minutes on a small, unfamiliar task, alone, in every session, does more than another unit of new material.

The home check: skills gap or confidence block?

Before you pay for anything else, find out which problem you have. A child who is missing skills and a child who has the skills but freezes look identical from across the room, and they need different fixes.

You do not need to read code to run this. It takes about twenty minutes.

1. Pick a task your child has definitely done before. Something from a past class, in the language they used most: ask for a name and print a greeting, print a times table, or make a number-guessing game with three tries. If they mostly used blocks, use Scratch: make a sprite move with the arrow keys and say something when it touches the edge.
2. Set up a blank file. No video, no old project open, no AI, no notes. Tell them mistakes are fine and you are only curious how far they get.
3. Watch the first five minutes and say nothing about the code. Notice whether they start typing, and what they do when something breaks.
4. If they are stuck after five minutes, give one small hint. Not the answer. "What do you need to store?" or "How did the guessing game in class start?"
5. Ask them to explain one line they wrote. Just one.

Then read what you saw.

• Mostly a skills gap: they cannot write the first line, even after the hint, or they write something that looks like code but cannot explain any of it. The ideas have not landed, however many times they were taught.
• Mostly a confidence block: they know more than they show. They hesitate, ask "is this right?" before every line, delete and retype. But after one hint, or after you say "just try it", most of it comes out, and they can explain it.
• Some of each: solid on some ideas, shaky on others, and the shaky ones trigger the freezing.

A skills gap needs teaching from the actual gap, not from lesson one. A confidence block needs many small, low-stakes chances to work alone and get it wrong safely, with someone who treats a broken first attempt as useful information rather than failure. Either way, the next program should start with a check like this one, run by someone who knows what to look for.

What to ask the next program or tutor

These questions work for any program, including ours. The answers tell you whether next year will look like the last few.

How will you find out what my child can already do? A good answer involves your child writing code early, on a task they have not seen. A weak answer is an age band, a form, or "we'll start with the basics to be safe."

What are the milestones, and what does my child have to do to pass one? Look for skills your child demonstrates, such as writing a loop with a working stop condition from a blank file, not chapters completed. Teaching for mastery means not moving on until the current idea works without help.

How often will my child solve something alone, without the instructor or AI? The answer you want is every session. Once a term is not enough.

Who reads my child's code, and what do I hear afterwards? Someone should be reading what your child writes, not only what the class produces. I explain what parents receive from us in what parents get after every coding session.

What happens when my child is ahead, or stuck? In a good setup, both change the plan. In a weak one, neither does.

If a provider promises a finished app by a set date, be careful. I explained why in what to do when a coding school promises your 9-year-old an app. Real progress after years of false starts is quieter than that. It is the first time your child opens an empty file and gets something working without anyone's code to follow.

Frequently Asked Questions

Why can't my child code on their own after years of classes? Usually because the programs never required it. Many beginner programs restart at lesson one, place children by age, teach at the pace of the middle of the group, and build projects along with the instructor. A child can do all of that for years without once producing code alone. That points to the format, not to your child's ability.

How do I know if it is a skills gap or a confidence problem? Run a blank-file check at home: a small task they have done before, with no video, no notes and no AI. If they cannot start even after a hint, it is mostly skills. If they hesitate but most of it comes out after one hint, and they can explain what they wrote, it is mostly confidence.

Should my child start again from the beginning? Not by default. Start from the actual gap, which a short skills check will find. Repeating the whole beginner unit is the restart loop again. Repeating only the ideas that did not land is targeted teaching.

Will 1-on-1 tutoring work if group classes did not? Not automatically. A tutor who types along with your child, or never asks them to work alone, will repeat the same pattern at a higher price. What changes the result is an assessment first, milestones your child demonstrates, and regular checks done without help. Ask any tutor, including us, how they do each one.

How long until my child can code without help? It depends on the child, and anyone who gives you a fixed date is guessing. Some children finish our core Python course in about 20 hours of lessons. Others need much more. Earlier classes are not wasted either: familiarity with the words and the editor can help the early part move faster once teaching starts from the real gap.

Should my child use AI tools to get past this? Not yet. If your child cannot write a short program alone, they cannot judge what an AI writes for them either. Fundamentals first, AI later, once they can read and check the code it produces.

Start here

If you act on one thing this week, make it the home check. It costs nothing, and it tells you which of the five reasons you are actually dealing with before you spend money on the next program.

1. Run the twenty-minute blank-file check above, and write down where your child got to and where they froze.
2. Ask your child to explain one line of something they built in a past class. If they cannot, treat that project as the instructor's work, not theirs.
3. Put the five questions above to the next program or tutor before you pay, and choose the one whose answers involve your child working alone.

If you would like someone to run that check properly and tell you what it shows, book a free Discovery Call.

From the session logs of Kids Coding Tutor: 1-on-1 Scratch, Python and AI tutoring for children ages 8 to 16. The patterns above come from conversations with parents and from first lessons with their children, with every family kept anonymous.