The Best Way to Learn to Code Is to Write About It

If you want to know whether you understand something, try to explain it. If you want to know whether you really understand it, try to write it down.

This is the principle behind everything I publish under Coding, Explained Plainly — short and long-form articles that turn programming concepts into something a careful reader can follow without prior background. The series exists because writing is the most honest test of understanding I have found.

Why writing exposes gaps that coding does not

Code can pass tests while you only half-understand it. Prose cannot. The moment you try to describe what a recursive function actually does — not in syntax, but in plain language — you discover whether you have a real model in your head or just a memorised pattern.

Most learners hit a ceiling not because they cannot read syntax, but because their mental model is too thin to carry weight. Writing thickens it.

How I use writing when I am learning

• Write the explanation before reading the documentation. Compare the two. The differences are where the learning lives.

• Explain it to someone two years behind you. Concrete audience, concrete prose.

• Write the bug before fixing it. Half the time the writing fixes it.

• Keep a private glossary of terms in your own words. Update it when your understanding deepens.

How I use writing when I am teaching

Every coding student I work with is asked to write — not code, prose. A paragraph explaining what their function does. A note describing what they tried before asking for help. A short post explaining a concept to a hypothetical beginner.

It feels slow. It is not.

The students who write about their code learn faster than the students who only write code. I have watched this happen often enough that I no longer treat it as a coincidence.

If you only take one thing

Open a blank document. Write down what you think you just learned, in your own words, without looking. The friction you feel is the learning happening.