在脑中记住一个程序
Original2007 年 8 月
一个优秀的程序员在专心致志地编写自己的代码时，可以像数学家一样在脑子里记住他正在研究的问题。数学家不会像小学生那样在纸上解决问题。他们更多地在脑子里做事：他们试图充分理解问题空间，以便能够绕着它走，就像你绕着你长大的房子的记忆走一样。最好的编程也是如此。你将整个程序记在脑子里，你可以随意操纵它。
这在项目开始时尤其有价值，因为最初最重要的是能够改变你正在做的事情。不仅仅是用不同的方式解决问题，而是改变你正在解决的问题。
你的代码是你对所探索问题的理解。因此，只有当你在脑子里有代码时，你才真正理解了这个问题。
把程序记在脑子里并不容易。如果你离开一个项目几个月，当你回来时，可能需要几天的时间才能真正理解它。即使你正在积极地开发一个程序，每天开始工作时也需要半个小时才能把程序记在脑子里。这还是在最好的情况下。在典型的办公室条件下工作的普通程序员永远不会进入这种模式。或者更夸张地说，在典型的办公室条件下工作的普通程序员永远不会真正理解他们正在解决的问题。
即使是最好的程序员也不一定能记住他们正在编写的整个程序。但你可以采取一些措施来帮助自己：
**避免分心。**分心对许多类型的工作都是不利的，但对编程尤其不利，因为程序员往往会在他们能够处理的细节范围内操作。
分心的危险性不在于它持续的时间有多长，而在于它对大脑的干扰有多大。程序员可以离开办公室去吃三明治，而不会忘记脑海中的代码。但错误的干扰可能会在 30 秒内让你的大脑一片空白。
奇怪的是，计划内的干扰可能比计划外的干扰更糟糕。如果你知道一小时后要开会，你甚至不会开始做困难的事情。
**长时间工作。**由于每次开始开发程序时都有固定成本，因此分几次长时间工作比多次短时间工作效率更高。当然，你会因为疲惫而变得愚蠢。这因人而异。我听说过有人连续工作 36 小时，但我最多能坚持 18 小时，而且我最好以不超过 12 小时的时间段工作。
最佳状态并不是你身体所能承受的极限。中断一个项目既有好处也有代价。有时当你休息过后再回头看一个问题时，你会发现你的潜意识已经为你留下了答案。
**使用简洁的语言。**更强大的编程语言可以使程序更短。程序员似乎至少部分地用他们编写程序的语言来思考程序。语言越简洁，程序越短，加载和记住它就越容易。
您可以使用一种称为自下而上的编程风格来放大强大语言的效果，即在多层中编写程序，底层程序充当上层程序的编程语言。如果您做得对，您只需记住最顶层即可。
**继续重写你的程序。**重写程序通常可以产生更简洁的设计。但即使没有，它也有优势：你必须完全理解一个程序才能重写它，所以没有比把程序装进你的脑子里更好的方法了。
**编写可重读的代码。**所有程序员都知道编写可读的代码是件好事。但你自己才是最重要的读者。尤其是在开始的时候；原型是与自己的对话。当你为自己写作时，你有不同的优先事项。如果你是为别人写作，你可能不想让代码太密集。如果你把程序的某些部分分散开来，就像一本入门教科书一样，它可能最容易阅读。而如果你写代码是为了让它更容易被重新加载到你的脑子里，那么最好简洁一些。
**小组合作。**当你在头脑中操纵程序时，你的视野往往停留在你拥有的代码的边缘。其他部分你也不太了解，更重要的是，你不能随意改动。因此，程序员的数量越少，项目的变化就越彻底。如果只有一名程序员（一开始通常都是这样），你可以进行全面的重新设计。
**不要让多个人编辑同一段代码。**你永远不会像理解自己的代码那样理解别人的代码。无论你读得多么透彻，你都只是读了它，而不是写它。所以如果一段代码是由多个作者编写的，那么没有人比单个作者更能理解它。
当然，你不能安全地重新设计其他人正在开发的东西。这不仅仅是你必须征得许可。你甚至不允许自己考虑这样的事情。重新设计有多个作者的代码就像改变法律；重新设计你一个人控制的代码就像看到模糊图像的另一种解释。
如果你想让几个人参与一个项目，那么就把它分成几个部分，每个部分分配给一个人。
**从小处着手。**随着你对程序的熟悉，你会更容易记住它。一旦你确信你已经完全探索了它们，你就可以开始将各个部分视为黑匣子。但是当你第一次开始一个项目时，你被迫看到一切。如果你从太大的问题开始，你可能永远无法完全涵盖它。因此，如果你需要编写一个庞大而复杂的程序，最好的开始方式可能不是为它编写规范，而是编写一个解决问题子集的原型。无论规划有什么好处，它们往往被能够在头脑中记住程序的好处所抵消。
令人惊讶的是，程序员经常会偶然达到所有八点。有人有一个新项目的想法，但因为没有得到官方批准，他不得不在业余时间做这件事——结果发现这样做效率更高，因为没有干扰。在对新项目的热情驱使下，他连续工作了好几个小时。因为这最初只是一个实验，所以他没有使用“生产”语言，而是使用了一种简单的“脚本”语言——事实上，这种语言要强大得多。他多次完全重写了程序；这对于一个正式项目来说是不合理的，但这是一份热爱的工作，他希望它完美无缺。而且，由于除了他之外没有人会看到它，所以他除了自我提醒之外没有其他评论。他不得不在一个小组里工作，因为他要么还没有告诉任何人这个想法，要么它看起来没有前途，所以不允许其他人使用它。即使有一个团队，他们也不能让多个人编辑相同的代码，因为代码变化太快，这是不可能的。而且项目从小处开始，因为最初的想法很小；他只是想尝试一些很酷的技巧。
更令人吃惊的是，很多官方批准的项目都把这八件事都做错了。事实上，如果你看一下大多数组织编写软件的方式，你就会发现他们几乎是在故意做错事。从某种意义上说，他们确实是这么做的。自从有了组织以来，组织的一大特征就是将个人视为可互换的部件。这对于更可并行化的任务很有效，比如打仗。在历史的大部分时间里，一支训练有素的职业士兵队伍可以打败一支由个体战士组成的军队，无论他们有多么英勇。但是有想法并不是很容易并行化的。而程序就是：想法。
组织不喜欢依赖个人天赋，这不仅是事实，而且是同义反复。组织的定义中就包含这样的内容。至少，我们目前的组织概念是这样的。
也许我们可以定义一种新的组织，将个人的努力结合起来，而不要求他们相互替换。可以说，市场就是这样一种组织形式，尽管将市场描述为退化的情况可能更准确——当组织不可能时，你默认得到的就是市场。
我们能做的最好的事情可能就是某种黑客攻击，比如让一个组织的编程部分的工作方式与其他部分不同。也许最佳解决方案是大公司甚至不要尝试在内部开发创意，而是直接购买它们。但无论解决方案是什么，第一步都是要意识到存在问题。“软件公司”这个词本身就存在矛盾。这两个词的方向截然相反。大型组织中的任何优秀程序员都会与之发生冲突，因为组织的设计就是为了阻止程序员所追求的东西。
优秀的程序员无论如何都能完成很多工作。但这通常需要对雇用他们的组织采取一种几乎是反抗的行为。如果更多的人明白程序员的行为方式是由他们所做工作的要求所驱动的，也许会有所帮助。他们长时间工作，抛开所有其他义务，直接投入编程而不是先写规范，并重写已经可以运行的代码，这并不是因为他们不负责任。他们喜欢独自工作，或者对那些探出头来打招呼的人咆哮，这并不是因为他们不友好。这些看似随机的恼人习惯只有一个解释：将程序记在脑子里的力量。
不管理解这一点是否能帮助大型组织，它肯定能帮助它们的竞争对手。大公司最薄弱的一点就是它们不让个别程序员做出伟大的工作。所以如果你是一家小型初创公司，这就是向它们发起攻击的地方。解决那些必须用一个大脑来解决的问题。
感谢Sam Altman、David Greenspan、Aaron Iba、Jessica Livingston、Robert Morris、Peter Norvig、Lisa Randall、Emmett Shear、Sergei Tsarev 和 Stephen Wolfram 阅读本文草稿。