Teaching Programming Should Never Mean Teaching Recipes

I’ve been teaching for years and the pattern repeats every single semester: the student who follows the recipe to the letter scores a solid B and has no idea what to do when the exercise changes one variable.

That’s not the student’s fault. It’s the fault of how we taught them.

The recipe works until the kitchen changes

A recipe is a sequence of steps that produces a known result in a known context. “Create the project with this command, paste this file, run this.” It works perfectly in the classroom, where I’m the one controlling the context.

At work the context is never the same: a different Node version, a different operating system, a different error, a requirement nobody wrote down. Whoever learned the steps stands there waiting for the next step. Whoever learned the mental model improvises one.

The test is brutal and always the same: change one detail of the assignment — the input arrives unsorted, the API responds 429, the array might come back empty — and watch who keeps moving.

We teach the result and hide the process

When the instructor codes live, they write the correct solution on the first try. The student reasonably concludes that this is how programming works: people who know write the good code immediately.

That’s a lie, and a damaging one. I also get variable names wrong, misread the stack trace and try two things before landing on the right one. What changed over the years isn’t the number of mistakes, it’s the speed at which I rule them out.

So now I teach with deliberate errors, and I don’t fix them right away. I read the full message out loud — yes, the message nobody reads — form a hypothesis, test it, discard it. That’s the class. The final code is barely a byproduct.

Debugging is the content, not the paperwork

No curriculum says “unit 3: debugging”. It’s assumed you pick it up on your own, like riding a bike or filling out the vacation form.

Debugging is teachable, and it has a method: reproduce reliably, reduce the case to a minimum, form a falsifiable hypothesis, change one thing at a time, verify. That’s the scientific method with console.log. A student who masters that survives any framework; one who memorized React 18’s syntax has an expiration date printed on them.

And now, on top of that, there’s an infinite recipe generator

With a model that spits out the complete solution in three seconds, teaching recipes stopped making sense even as a business. Nobody is going to pay you to produce what a free tool produces better and faster.

What does get paid: knowing whether that solution holds up. Reading someone else’s code with productive distrust, spotting the edge case the model didn’t consider, noticing that the query it generated does an N+1 against the database. That’s evaluation, and evaluation requires a mental model. Same thing again.

Generated code is allowed in my assessments. What gets graded is the defense: why this solution and not another, what happens if the input grows tenfold, where’s the case you didn’t cover. It’s surprising how many people hand in working code and can’t explain a single line of it.

The goal

I’m not training people who know how to make an omelette. I’m training people who understand what heat does to an egg, so they can cook when they’re missing an ingredient.

Everything else is in the documentation, and documentation doesn’t need a teacher.