What Does a First Coding Class Actually Look Like?

Minutes 0 to 6: nobody writes anything

The first six minutes have no code in them at all, and parents watching sometimes wonder when we are going to start.

We are starting. Py the turtle turns up, there is a small problem that needs solving, and the child is asked what should happen first. That is it. No syntax, no vocabulary, no screen sharing.

The reason is simple. A child who has spent five minutes wanting a robot to walk in a square has a reason to type, and the reason is what makes the line stick.

In the blocks room this looks nearly identical. Cody wants a patch of seabed marked out, and the six-year-olds argue about what she should do first. Same five minutes, same argument, no keyboard involved.

Here is the whole hour before we go further. Note the size of the fifth step. That is where this is heading, and everything before it exists so your child gets there with somebody sitting beside them.

A child who types before they want something is copying. A child who wants something first is programming.

Minutes 6 to 18: one line that does something

Now the child types. Not a program. One line, and it does something immediately.

It runs, a word appears, and the child has made a computer say something they chose. That gap between typing and result has to be under ten seconds in a first lesson, which is most of why we do not open with theory.

Then a second line goes in with the child's own name in it, because a program with your name in it belongs to you in a way a worksheet exercise never does.

In the blocks room the equivalent is dragging a say block onto the cat and clicking the green flag. The cat says something the child wrote. Identical feeling, no typing, and honestly a slightly better version of the moment because it arrives faster.

By minute eighteen there is a working two-line program on screen and nobody has said the word string yet. They meet it later, once there is something for it to attach to.

This is where it starts, and the child picks what goes inside the brackets:

print("Hello!")

Minutes 18 to 34: it breaks

This is the centre of the lesson, and the part I would defend hardest to a parent watching through a doorway.

We break the program. On purpose, while I am sitting right there.

Usually I do not even have to engineer it. A child types a capital P, because every other piece of software they have ever touched does not care, and Python answers with this:

NameError: name 'Print' is not defined

The first time a child sees a red message, they look at me rather than at the screen. That look is the entire reason we do this in minute twenty rather than letting it happen alone at home on a wet evening.

So we read it together. Not fix it. Read it. What does it say the problem is? Which word is it complaining about? Where is that word on your screen? The child finds the capital P themselves roughly nine times in ten, fixes it, and the thing runs.

What they have actually learned is not about capital letters. It is that a red message is a sentence addressed to them with the answer inside it. Children who learn that in lesson one are much harder to discourage later, which is the whole of my child says I'm bad at coding.

There is a longer argument for why reading and repairing code is the half of this job that keeps its value, and we made it in what is left for your child to learn.

The blocks room breaks too, and it needs teaching just as deliberately. A six-year-old uses forever where they meant repeat ten, and the sprite sails off the edge and never comes back. Nothing turns red and nothing explains itself, so we trace the script from the green flag with a finger until we find the block that lied. Same skill, harder to spot, which is exactly why blocks teachers do not skip it either.

Minutes 34 to 55: make your own

The last third is not more teaching. It is the child turning the program into something nobody asked for.

They change the number. They change the words. Somebody makes it print a hundred times and the class laughs. Somebody makes it mildly rude, which I allow within reason, because a child testing the edges of a system has understood that there is a system.

Nobody leaves with the same thing as the child next to them. That is the measure of whether the hour worked, more than anything they can recite afterwards.

Here is roughly where an hour lands, though no two of them come back identical:

name = input("What is your name? ")

for i in range(3):
    print("Hello " + name + "!")

What you can do this week

If your child has a first class coming up, none of this needs preparation from you.

The third one matters more than it looks, because the answer tells you whether the hour did its job.

• ✓Tell your child beforehand that the program is meant to break, and that breaking it is the good part.
• ✓Do not sit behind them for the whole hour. Come in for the last ten minutes, when there is something of theirs to show.
• ✓Afterwards ask what went wrong, not what they made. A child who can answer that had a good lesson.