What teaching kids to code fixed in my own code

I taught coding to kids part time for close to two years. Unity and Scratch and LEGO robotics for the younger ones, JavaScript and React for students old enough to want a real editor.

I took the job for the schedule. I kept it because it kept catching things I did not know.

The jargon test

Adults let you get away with jargon. If I say "we'll store that in state and re-render on change" in a standup, everyone nods, and I never find out whether I understood the sentence I just said.

A twelve year old does not nod. They ask what state is. Then they ask where it lives. Then they ask what happens to it when you close the game, and you realize the honest answer is longer than you expected and you are still talking two minutes later.

Every concept I could not explain without leaning on a technical word was a concept I half knew. Variables were fine. Scope was fine. The ones that fell apart were the ones I had learned as rules rather than as mechanisms: why a loop needs a counter that changes, why two objects can point at the same thing, why the order of two lines matters when both of them "work".

Analogies break, and that is useful

The standard move is to reach for an analogy. A variable is a box. A function is a recipe. A loop is doing laps.

Every one of these works until a student pushes on it, and where it breaks tells you something real about the model underneath. A variable stops being a box the moment two names point at one object, because boxes do not do that. A function stops being a recipe once it returns something you use somewhere else.

I started treating a broken analogy as the interesting part of the lesson rather than something to patch over. When a kid says "but you said it was a box", the honest reply is that the box was a starting picture and here is where the real thing stops matching it. That lands better than a second analogy, and it is closer to how the machine actually behaves.

Debugging with someone who has no fear

Kids debug differently. They have no ego about the code because they wrote it ten minutes ago and are not attached to it. They will delete a whole block to see what happens. They will change a number to a wildly wrong number just to watch it break.

Watching that made me notice how cautious I had become with my own bugs. I would form a theory and defend it, changing one careful line at a time, protecting an idea I had about what was wrong. The kids skip the theory and go straight to evidence, and they are frequently faster than me.

Now when I am stuck I will deliberately break something to confirm it matters. If commenting out the code I suspect changes nothing, my theory was wrong and I saved myself twenty minutes of defending it.

Project-based means it has to actually run

The classes are built around projects, which means at the end of a session something has to work well enough to show someone. Nobody wants to hear that the architecture is sound but the game does not open.

That is roughly the same constraint as a demo at work, and it is a good one to be reminded of every week. A student's game with one working level beats a half-finished engine every time, and the same is true of most of the code I write for money.

What it costs

The tradeoff is real: it is time on a weekend, the pay is what you would expect, and explaining recursion for the fourth time in one afternoon is genuinely tiring.

What I get back is a weekly test of whether I understand my own tools well enough to describe them to someone with no context and no patience for hand waving. Most weeks I pass. The weeks I do not are the ones worth paying attention to.