Haskell for all: Type out the codeHaskell for all<br>Tuesday, May 19, 2026<br>Type out the code

Back in the day I read one of Zed Shaw's "Learn X the hard way" courses (I think it was his C++ course) and he began the course with a disclaimer that said something like "do not copy and paste the examples; type them out" because he believed strongly that doing so improved your comprehension of the material.

These days he recommends something even stronger:

The best way to do this is when you complete an exercise delete what you did and do it again, but try to use your memory. If you get stuck then look at the exercise for clues, but try your best to recreate what you just did from memory. At first you'll be constantly referring to the exercise and the code, but eventually you'll get to where you can do it on your own. This will also improve your ability to remember more code, your ability to summarize how something works, and generally improve your skills faster than if you did it once and moved on.

This is known as the generation effect in cognitive psychology: the active generation of new content improves comprehension compared to passive consumption of the same material. Or as Richard Feynman put it: "What I cannot create, I do not understand".

I'm not a researcher, but I would still like to add my own spin as a lay programmer on why I believe this phenomenon matters for improving programming ability, even in the age of agentic coding. In fact, I think it's even more important now than ever for people to reacquaint themselves with this "ancient wisdom" because otherwise we'll end up with an entire generation of programmers wondering how anyone ever programmed without the help of a coding agent.

In this post I will lay out the case for why you should occasionally type out the code, character-by-character, as best as possible from memory. That doesn't mean that you should never use developer tools of any sort to streamline the coding process, but you also should occasionally stretch your ability to code without those affordances, too.

Freecoding

I believe in the importance of occasionally spelling out details when programming, and I don't just mean things like performance characteristics or UI design decisions. I mean basic stuff like:

syntax and structure

… meaning fluency with keywords, punctuation, and language constructs

types and schemas

… including familiarity and comfort with the type system and data model

names of things

… such as accurate recall of functions, methods, classes, imports, and files

These are the things that need to live in your brain so that you can "freecode" from memory and in my experience programmers who do this significantly outperform other programmers even on tasks which seem unrelated to freecoding proficiency. I also don't think this is simple correlation but rather causation: freecoding cultivates broader programming excellence .

Why? Because, if you're unable to type out what you have in mind to a certain degree of precision1 that means you didn't really have it in mind. You were hallucinating understanding, the same as an LLM.

"But Gabby," you might retort, "I'm pretty sure I can proficiently understand and manipulate the code at a high level without getting bogged down in details like syntax or names."

No, I'm not convinced that this works as well as some people think and I'll spell out why.

Syntax and structure

Let's start with syntax, which is probably the most controversial thing for me to advocate grinding on. After all, it's 2026 and our IDE or coding agent can get the syntax right for us, so why should we bother to think about the syntax at all?

Well, for starters, if you struggle with syntax then I'll wager there are many other things (even non-programming things) that you struggle with. For example, if you have difficulty balancing parentheses I'd begin to wonder how fluently you can connect someone else's logical premise with their conclusion.

I would go even further and connect disregard for the details with the epidemic of people who are "functionally inarticulate": unable to logically follow or chain together sentences. I'm talking about the sort of people who communicate based on vibes rather than reasoning in a clear-headed way about the meaning of words.

To illustrate what I mean, I recently audited an LLM prompt and stumbled across this:

Never suggest external tools or alternatives that aren't part of the skills listed above. If a task requires capabilities beyond the available skills, say so.

This is the sort of prompt that I would read as functionally inarticulate: it sounds sensible if you don't read closely but when you do you might notice the prompt is actually giving the model two diametrically opposed instructions.

I find that functionally inarticulate people, almost to a person, also struggle to spell or form grammatically correct sentences on their own because you can't separate the small stuff from the big stuff: when you skimp...