Type out the code / 敲出代码

Haskell for all | Tuesday, May 19, 2026 Haskell for all | 2026年5月19日，星期二

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. 过去，我读过 Zed Shaw 的“笨办法学 X”（Learn X the hard way）系列课程之一（我想应该是他的 C++ 课程）。他在课程开头写了一则免责声明，大意是：“不要复制粘贴示例代码；请亲手敲出来。”因为他坚信这样做能显著提升对知识的理解。

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”. 这在认知心理学中被称为“生成效应”（generation effect）：与被动消费相同的内容相比，主动生成新内容能显著提高理解力。正如理查德·费曼所言：“我无法创造的东西，我就无法理解。”

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. 我不是研究人员，但作为一名普通程序员，我仍想从自己的角度谈谈为什么我认为这种现象对于提升编程能力至关重要，即使是在智能体编程（agentic coding）时代。事实上，我认为现在比以往任何时候都更需要人们重新认识这种“古老的智慧”，否则我们最终会培养出一代程序员，他们会困惑于在没有编程智能体辅助的情况下，人们究竟是如何写代码的。

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: 我相信在编程时偶尔详细地写出代码细节非常重要，我指的不仅仅是性能特征或 UI 设计决策，而是指一些基础内容，例如：

• 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 precision, that means you didn’t really have it in mind. You were hallucinating understanding, the same as an LLM. 为什么？因为如果你无法将脑海中的想法以一定的精确度敲出来，那就意味着你并没有真正理解它。你只是像大语言模型（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. “但是 Gabby，”你可能会反驳，“我很确定我可以在不纠结于语法或命名等细节的情况下，熟练地理解和操作高层代码。”不，我不认为这种方法像某些人想的那样有效，我将详细说明原因。

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? 让我们从语法开始，这可能是我所倡导的练习中最具争议的一点。毕竟，现在已经是 2026 年了，我们的 IDE 或编程智能体可以帮我们搞定语法，为什么我们还要费心去思考语法呢？

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: 为了说明我的意思，我最近审计了一个 LLM 提示词，偶然发现了这样一段：

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 on getting details correct that bleeds into everything you do and you begin to get the big picture wrong, too. 我发现，功能性表达障碍者几乎无一例外地在拼写或构建语法正确的句子上也存在困难，因为你无法将小事与大事割裂开来：当你对细节敷衍了事时，这种习惯会渗透到你所做的每一件事中，最终导致你对大局的把握也出现偏差。

Similarly, people who struggle with syntax often struggle with abstract thought. They probably think of syntax as a detail that gets in the way of big picture thinking but nothing could be further from the truth! Syntax is a mental tool that compresses and powers higher-level thinking, affording us a precise, clear, and compact internal language for reasoning. 同样，在语法上挣扎的人往往在抽象思维上也存在困难。他们可能认为语法是阻碍宏观思考的细节，但事实恰恰相反！语法是一种思维工具，它压缩并驱动了更高层次的思考，为我们提供了一种精确、清晰且紧凑的内部语言来进行推理。

Or to put it another way, syntax is the difference between this: 换句话说，语法决定了以下两者的区别：

x is a an array of objects, each of which has a required domain property storing a string and an optional port property storing a number … x 是一个对象数组，其中每个对象都有一个必需的 domain 属性（存储字符串）和一个可选的 port 属性（存储数字）……

and this: 以及：

x : { domain: string, port?: number }[] x : { domain: string, port?: number }[]

which brings me to the next thing you should grind on: 这引出了你应该练习的下一项内容：

Types and schemas / 类型与模式

I cannot overstate how important it is to know your type system and data model like the back of your own hand. As Fred Brooks said in The Mythical Man Month: “Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables…” 我怎么强调都不为过：像了解自己的手背一样了解你的类型系统和数据模型是多么重要。正如 Fred Brooks 在《人月神话》中所说：“给我看你的流程图，却把表格藏起来，我依然会感到困惑。给我看你的表格……”