The First Time a Student Writes Code From Scratch

Last updated: September 2026

The first time a child writes code from scratch is the moment their coding stops being an activity and starts being a skill. Up to that point they have been typing along with someone: a video, a worksheet, a tutor. The code on screen was never really theirs. When they open a blank file and produce something that runs, badly, on their own, that is the line being crossed.

In August I watched Cameron, 15, cross it. He had been coding along with me for weeks. Then I gave him a target and stopped helping. What he wrote had five bugs in it. That was the best thing about it.

What typing along actually teaches

Typing along is not worthless. It builds muscle memory for syntax, it gets a child comfortable in an editor, and it removes the fear of a blank screen. Every student of mine spends weeks doing it.

But it teaches recognition, not recall. A child who has typed a for loop forty times will recognise one instantly and still be unable to produce one unaided. Those are different abilities that look the same in a lesson.

The gap only shows when you take the example away. This is why I stop demonstrating at a certain point, even though the lesson gets visibly harder and less pleasant for a few minutes.

"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

That sequence, show then withdraw then re-explain, is the whole method. The withdrawal is the part that does the work.

The challenge, and what came back

Cameron had spent the session on nested loops: a loop inside a loop, and how the inner one runs completely for every single pass of the outer one. Python's for statement makes this easy to write and surprisingly hard to picture. He had predicted the output correctly a few times, which was new.

So I sent him a screenshot of a multiplication table and said: build that. I did not tell him how. I did not start the file for him.

What came back had five distinct faults in about fifteen lines. The separator dashes printed after every number instead of every row, which turned out to be an indentation level rather than a logic error. Two similarly named variables were being printed together, so the output was unreadable even though it was correct. He had written range(1*1, 9*9), doing arithmetic inside the range, which sent the numbers running up to 80. He stopped at 9 instead of 10, losing the last row. And his second loop reused the first loop's variable name, collapsing the output.

He fixed all five.

Why five bugs was the good outcome

Parents tend to read a broken first attempt as evidence that the lessons are not landing. It is the opposite.

Working code on a first from-scratch attempt usually means one of two things: the task was too easy, or the child reproduced something they had memorised. Neither tells you anything about capability. Broken code tells you a great deal, because the repair process is where you find out what they actually understand.

Three of Cameron's five bugs came from one root cause: Python's range() counts up to but not including the number you give it, which the official Python documentation describes as a half-open interval. He had met that rule twice before. He still tripped on it, and after fixing it by hand twice, he stopped tripping on it.

The moment that mattered most was the last bug. He hit the same off-by-one error on his inner loop, and before I could ask him anything, he said it himself and corrected it.

That self-catch is the actual milestone. Not the table. A child who can find their own mistake has a feedback loop that runs without me in the room, which is the entire point of teaching them.

How to tell the difference as a parent

You do not need to read the code. You need to watch what happens when the code breaks.

A child typing along starts with an example on screen; a child writing from scratch starts with a blank file. When it breaks, the first waits or asks what to type, while the second reads the output and guesses. Ask them to explain it and the first describes what they did, the second describes why it works. Errors are rare for the copier, because the example was correct, and frequent for the builder, because they are getting fixed. And between sessions, nothing runs for one of them while the other opens the file unprompted.

The most reliable test at home is to ask your child to explain what one line does, not what the program does. A child who has been copying can tell you the program makes a multiplication table. A child who wrote it can tell you why that particular line has a tab in front of it, because in Python indentation is part of the language rather than a matter of style.

If you want a fuller picture of what steady progress looks like over a longer run, I have written about what 30 sessions of 1-on-1 coding actually look like.

What I got wrong that day

I want to be straight about this, because it is the part I would want to know as a parent.

He did not finish it with me. We took a break partway through, it ran long, and I had a hard stop in my calendar. I left before the table was finished and working.

That was my scheduling error, not his. The completion and the moment of it finally running were the most valuable ninety seconds available in four weeks of lessons, and I gave them away by not protecting the end of the session. I now put a number on breaks and hold the room to it.

I did ask him to send the file over when it worked. I told him I wanted to put it in a museum. He is fifteen and pretended that was embarrassing, which it was, and he sent it anyway.

Python For Loops for Kids: 12 Examples That Actually Make Sense covers the loop mechanics behind this challenge, including range() and the off-by-one rule.
What 30 Sessions of 1-on-1 Coding Actually Look Like maps the longer arc this milestone sits inside.
Why a Longer Coding Lesson Taught My Student Less on why session length is not the same as session value.

Frequently Asked Questions

How long before my child can write code from scratch? Across 200+ students, most reach it between three and six months of consistent weekly lessons plus some work between them. The variation is wide and it is not driven by age. A motivated 10-year-old often gets there before a distracted 14-year-old.

Should I be worried if their first program is full of errors? No. Four or five errors on a first unaided attempt is the normal range. Zero errors usually means the task was too small or they reproduced something memorised, which teaches you nothing about what they can do.

What is an off-by-one error? It is when a loop runs one time too many or one time too few, almost always because Python's range() stops just before the number you give it. range(1, 10) produces 1 through 9, not 1 through 10. It is the single most common beginner mistake in Python and it takes most kids two or three encounters to internalise.

The Bottom Line

The first from-scratch program is the clearest progress marker in a child's coding, and it almost never looks impressive. It looks like a broken fifteen-line file with an off-by-one error in it. What matters is who did the fixing.

If your child has been following tutorials for months and you cannot tell whether any of it has stuck, that is a question worth answering properly rather than guessing at.

I teach kids ages 8 to 16 online, 1-on-1, and the first thing I do is find out where a child actually is rather than where their course progress bar says they are. Book a free Discovery Call.