If you can explain recursion to a 10-year-old

I've been tutoring coding to 8-to-17-year-olds since 2019. It started as side money in high school. It turned into the thing I draw on most when I'm writing code for actual adults.

Kids are the most honest API reviewers on the planet. An adult engineer will push through a confusing abstraction because somebody's paying them to. A 10-year-old will look at your function name and tell you, with their entire face, that it makes no sense. They're usually right.

The mirror moment

I was trying to explain recursion to a kid named Marcus. He was 10. I did the textbook thing. Wrote factorial(n) = n * factorial(n-1) on the whiteboard and walked through the call stack. Marcus listened, nodded, got to the end, and asked: "why would you do that when you could just multiply?"

I laughed, then I stopped laughing. He was right. Factorial is a terrible reason to use recursion. It's in every textbook because it fits on one slide, not because it's a good argument for the pattern. I'd been teaching the how without teaching the why.

"Why would you do that when you could just multiply?" — Marcus, age 10, 2022

I scrapped the rest of the lesson. We started over. Instead of factorial, I asked him how he'd find a file on his computer if he didn't know which folder it was in. He thought for a second. "I'd open each folder, and if I saw another folder inside, I'd open that one too." Yep. That's recursion. Now let's write it.

The pattern across every student

Marcus wasn't special. Every confused student I've had has taught me the same thing, phrased slightly differently:

• Names that don't match shape. "Why is it called handleSubmit if it doesn't submit anything?"
• Magic that doesn't explain itself. "Where did self come from?"
• Hidden state. "But I didn't tell it to remember that."
• Too many layers. "Which one is actually doing the thing?"

Each of those complaints maps to something adult engineers have fancier words for: weak abstraction, implicit coupling, side effect, over-engineering. A kid is just less willing to nod along and pretend the code makes sense when it doesn't.

What I do now when I design APIs

// Rule 1 — the name has to match the shape

Before I write the function body, I ask: if this showed up in a student's code and they didn't know what it did, would the name tell them? If not, rename.

// Rule 2 — no magic without a trail

If something happens "automatically," the reason has to be somewhere a reader can find it. A middleware, a decorator, a subscription, a config file. If behavior has no trail, you get the "but I didn't tell it to do that" reaction, and that's on you.

// Rule 3 — one good example beats three generic ones

I used to default to whatever example was in the docs. Now I use the example that matches the problem in front of me. Recursion is filesystems or family trees, not factorials. Async/await is "fetch a user's playlist," not Promise.resolve(1). The why has to come before the what, or the student doesn't have a reason to care.

The meta-lesson

Tutor a kid at some point. The money's bad and the hours are weird, but you'll build an instinct for when your code would make a ten-year-old blink at you. Once you can feel that instinct firing, you start fixing it before you ship.

Marcus went home that day and added a recursive file search on his mom's laptop to find a missing assignment. He didn't cite Wikipedia. He just used it, because now it made sense.

That's the bar.