将程序装进脑海
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 阅读了本文的草稿。