Holding a Program in One's Head
August 2007 A good programmer working intensively on his own code can hold it in his mind the way a mathematician holds a problem he's working on.
2007 年 8 月 一个优秀的程序员在集中精力编写自己的代码时，可以将其牢记在心，就像数学家思考他正在解决的问题一样。
Mathematicians don't answer questions by working them out on paper the way schoolchildren are taught to.
数学家不会像小学生那样通过在纸上算出问题来回答问题。
They do more in their heads: they try to understand a problem space well enough that they can walk around it the way you can walk around the memory of the
他们在头脑中做更多的事情：他们试图充分理解问题空间，以便他们可以像围绕问题的记忆一样围绕它行走。
house you grew up in.
你长大的房子。
At its best programming is the same.
最好的情况下，编程是相同的。
You hold the whole program in your head, and you can manipulate it at will.
你把整个程序记在脑子里，你可以随意操纵它。
That's particularly valuable at the start of a project, because initially the most important thing is to be able to change what you're doing.
这在项目开始时特别有价值，因为最初最重要的是能够改变你正在做的事情。
Not just to solve the problem in a different way, but to change the problem you're solving.
不仅仅是以不同的方式解决问题，而是改变你正在解决的问题。
Your code is your understanding of the problem you're exploring.
您的代码是您对正在探索的问题的理解。
So it's only when you have your code in your head that you really understand the problem.
因此，只有当你脑子里有代码时，你才能真正理解问题。
It's not easy to get a program into your head.
将程序放入您的脑海中并不容易。
If you leave a project for a few months, it can take days to really understand it again when you return to it.
如果你离开一个项目几个月，当你返回它时可能需要几天的时间才能真正理解它。
Even when you're actively working on a program it can take half an hour to load into your head when you start work each day.
即使您正在积极地执行一个计划，每天开始工作时也可能需要半个小时的时间才能进入您的大脑。
And that's in the best case.
这是最好的情况。
Ordinary
普通
programmers working in typical office conditions never enter this mode.
在典型办公室条件下工作的程序员永远不会进入这种模式。
Or to put it more dramatically, ordinary programmers working in typical office conditions never really understand the problems they're solving.
或者更戏剧性地说，在典型办公室条件下工作的普通程序员永远不会真正理解他们正在解决的问题。
Even the best programmers don't always have the whole program they're working on loaded into their heads.
即使是最好的程序员也并不总是将他们正在编写的整个程序加载到他们的头脑中。
But there are things you can do to help: Avoid distractions.
但您可以采取一些措施来提供帮助： 避免分心。
Distractions are bad for many types of work,
分心对许多类型的工作都是有害的
but especially bad for programming, because programmers tend to operate at the limit of the detail they can handle.
但对于编程来说尤其不利，因为程序员往往会在他们可以处理的细节极限上进行操作。
The danger of a distraction depends not on how long it is, but on how much it scrambles your brain.
分心的危险不在于分心的时间有多长，而在于它对你大脑的干扰程度。
A programmer can leave the office and go and get a sandwich without losing the code in his head.
程序员可以离开办公室去买三明治，而不会丢失头脑中的代码。
But the wrong kind of interruption can wipe your brain in 30 seconds.
但错误的打扰可能会在 30 秒内让你的大脑崩溃。
Oddly enough, scheduled distractions may be worse than unscheduled
奇怪的是，计划内的干扰可能比计划外的干扰更糟糕
ones.
那些。
If you know you have a meeting in an hour, you don't even start working on something hard.
如果你知道一个小时后就要开会，你甚至不会开始做一些困难的事情。
Work in long stretches.
长时间工作。
Since there's a fixed cost each time you start working on a program, it's more efficient to work in a few long sessions than many short ones.
由于每次开始编写程序时都有固定的成本，因此在几个长会话中工作比在许多短会话中工作更有效率。
There will of course come a point where you get stupid because you're tired.
当然，有一天你会因为累而变得愚蠢。
This varies from person to person.
这因人而异。
I've heard of people hacking for
我听说有人黑客攻击
36 hours straight, but the most I've ever been able to manage is about 18, and I work best in chunks of no more than 12.
连续 36 小时，但我最多能管理大约 18 小时，而且我在不超过 12 小时的时间内工作效果最好。
The optimum is not the limit you can physically endure.
最佳状态并不是您身体上可以承受的极限。
There's an advantage as well as a cost of breaking up a project.
分解项目既有好处，也有成本。
Sometimes when you return to a problem after a rest, you find your unconscious mind has left an answer waiting for you.
有时，当你休息后回到某个问题时，你会发现你的潜意识已经留下了一个答案在等着你。
Use succinct languages.
使用简洁的语言。
More powerful programming languages
更强大的编程语言
make programs shorter.
使程序更短。
And programmers seem to think of programs at least partially in the language they're using to write them.
程序员似乎至少部分地用他们用来编写程序的语言来思考程序。
The more succinct the language, the shorter the program, and the easier it is to load and keep in your head.
语言越简洁，程序越短，并且更容易加载并保留在您的头脑中。
You can magnify the effect of a powerful language by using a style called bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages
您可以通过使用一种称为自下而上编程的风格来放大强大语言的效果，在这种风格中，您可以在多层中编写程序，较低的层充当编程语言
for those above.
对于上述人员。
If you do this right, you only have to keep the topmost layer in your head.
如果你做得正确，你只需要记住最顶层的内容即可。
Keep rewriting your program.
继续重写你的程序。
Rewriting a program often yields a cleaner design.
重写程序通常会产生更简洁的设计。
But it would have advantages even if it didn't: you have to understand a program completely to rewrite it, so there is no better way to get one loaded into your head.
但即使没有，它也会有优点：你必须完全理解一个程序才能重写它，所以没有更好的方法来让一个程序加载到你的头脑中。
Write rereadable code.
编写可读的代码。
All programmers know it's good to write
所有程序员都知道写得好
readable code.
可读的代码。
But you yourself are the most important reader.
但你自己才是最重要的读者。
Especially in the beginning; a prototype is a conversation with yourself.
尤其是在开始的时候；原型是与自己的对话。
And when writing for yourself you have different priorities.
当你为自己写作时，你有不同的优先事项。
If you're writing for other people, you may not want to make code too dense.
如果您是为其他人编写，您可能不想让代码太密集。
Some parts of a program may be easiest to read if you spread things out, like an introductory textbook.
如果将内容分散开，程序的某些部分可能最容易阅读，例如介绍性教科书。
Whereas if you're writing code to make it easy to reload
而如果您正在编写代码以使其易于重新加载
into your head, it may be best to go for brevity.
在你的头脑中，最好保持简洁。
Work in small groups.
以小组形式工作。
When you manipulate a program in your head, your vision tends to stop at the edge of the code you own.
当你在头脑中操作一个程序时，你的视野往往会停留在你拥有的代码的边缘。
Other parts you don't understand as well, and more importantly, can't take liberties with.
其他部分你也看不懂，更重要的是不能随意改动。
So the smaller the number of programmers, the more completely a project can mutate.
因此，程序员的数量越少，项目的变异就越彻底。
If there's just one programmer, as there often is at first, you can do
如果只有一个程序员（一开始经常如此），你可以这样做
all-encompassing redesigns.
全方位的重新设计。
Don't have multiple people editing the same piece of code.
不要让多人编辑同一段代码。
You never understand other people's code as well as your own.
你永远无法理解别人的代码以及你自己的代码。
No matter how thoroughly you've read it, you've only read it, not written it.
无论你读得多么透彻，你都只是读过，而不是写过。
So if a piece of code is written by multiple authors, none of them understand it as well as a single author would.
因此，如果一段代码是由多个作者编写的，那么他们中没有一个人能像单个作者那样理解它。
And of course you can't safely redesign something other people
当然，你不能安全地重新设计其他人的东西
are working on.
正在努力。
It's not just that you'd have to ask permission.
这不仅仅是您必须征求许可。
You don't even let yourself think of such things.
你甚至不让自己去想这些事情。
Redesigning code with several authors is like changing laws; redesigning code you alone control is like seeing the other interpretation of an ambiguous image.
与多个作者一起重新设计代码就像改变法律一样；重新设计您单独控制的代码就像看到模糊图像的其他解释一样。
If you want to put several people to work on a project, divide it into components and give each to one person.
如果您想让多个人参与一个项目，请将其划分为多个组件，并将每个组件分配给一个人。
Start small.
从小处开始。
A program gets easier to hold in your head as you
当你
become familiar with it.
熟悉它。
You can start to treat parts as black boxes once you feel confident you've fully explored them.
一旦您确信自己已经充分探索了零件，您就可以开始将其视为黑匣子。
But when you first start working on a project, you're forced to see everything.
但当你第一次开始从事一个项目时，你被迫看到一切。
If you start with too big a problem, you may never quite be able to encompass it.
如果你从太大的问题开始，你可能永远无法完全解决它。
So if you need to write a big, complex program, the best way to begin may not be to write a spec for it, but to write a prototype that solves a subset of
因此，如果您需要编写一个大型、复杂的程序，最好的开始方法可能不是为其编写规范，而是编写一个原型来解决以下问题的子集：
the problem.
问题。
Whatever the advantages of planning, they're often outweighed by the advantages of being able to keep a program in your head.
无论计划有什么好处，它们往往都被能够在头脑中保留计划的好处所抵消。
It's striking how often programmers manage to hit all eight points by accident.
令人惊讶的是，程序员意外地达到全部八点的频率非常高。
Someone has an idea for a new project, but because it's not officially sanctioned, he has to do it in off hours—which turn out to be more productive because there are no distractions.
有人有一个新项目的想法，但由于它没有得到正式批准，他必须在下班时间完成——事实证明，这样效率更高，因为没有干扰。
Driven by his enthusiasm for the new project he works on it for many hours at a stretch.
在对新项目的热情驱使下，他连续工作了好几个小时。
Because it's initially just an experiment, instead of a "production" language he uses a mere "scripting" language—which is in fact far more powerful.
因为它最初只是一个实验，所以他使用的不是“生产”语言，而是一种纯粹的“脚本”语言——事实上，这种语言要强大得多。
He completely rewrites the program several times; that wouldn't be justifiable for an official project, but this is a labor of love and he wants it to be perfect.
他把程序彻底重写了好几次；这对于官方项目来说是不合理的，但这是一种爱的劳动，他希望它是完美的。
And since no one is going to see
既然没有人会看到
it except him, he omits any comments except the note-to-self variety.
除了他之外，他省略了除了自言自语之外的任何评论。
He works in a small group perforce, because he either hasn't told anyone else about the idea yet, or it seems so unpromising that no one else is allowed to work on it.
他被迫在一个小团队中工作，因为他要么还没有告诉其他任何人这个想法，要么它看起来毫无希望，以至于没有人被允许进行研究。
Even if there is a group, they couldn't have multiple people editing the same code, because it changes too fast for that to be possible.
即使有一个小组，他们也不能让多个人编辑相同的代码，因为代码变化太快，这是不可能的。
And the project starts small because the idea is small at first; he just has some cool
项目开始时规模很小，因为最初的想法很小；他只是有一些很酷
hack he wants to try out.
他想尝试一下。
Even more striking are the number of officially sanctioned projects that manage to do all eight things wrong .
更引人注目的是，官方批准的项目数量却在所有八件事上都做错了。
In fact, if you look at the way software gets written in most organizations, it's almost as if they were deliberately trying to do things wrong.
事实上，如果你看看大多数组织中软件的编写方式，就会发现他们几乎是故意做错事。
In a sense, they are.
从某种意义上说，他们是。
One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable
自出现以来，组织的定义品质之一就是将个人视为可互换的
parts.
零件。
This works well for more parallelizable tasks, like fighting wars.
这对于可并行化的任务非常有效，例如打仗。
For most of history a well-drilled army of professional soldiers could be counted on to beat an army of individual warriors, no matter how valorous.
在历史的大部分时间里，一支训练有素的职业士兵军队可以击败一支由个人战士组成的军队，无论他们多么英勇。
But having ideas is not very parallelizable.
但拥有想法并不是很容易并行。
And that's what programs are: ideas.
这就是程序的本质：想法。
It's not merely true that organizations dislike the idea of depending on individual genius, it's a tautology.
组织不喜欢依赖个人天才，这不仅是事实，而且是同义反复。
It's part of the definition
这是定义的一部分
of an organization not to.
一个组织不这样做。
Of our current concept of an organization, at least.
至少在我们当前的组织概念中是这样。
Maybe we could define a new kind of organization that combined the efforts of individuals without requiring them to be interchangeable.
也许我们可以定义一种新的组织，将个人的努力结合起来，而不要求他们可以互换。
Arguably a market is such a form of organization, though it may be more accurate to describe a market as a degenerate case—as what you get by default when organization isn't possible.
可以说，市场就是这样一种组织形式，尽管将市场描述为一种退化的情况可能更准确——就像当组织不可能时你默认得到的那样。
Probably the best we'll do is some kind of hack, like making the
也许我们能做的最好的事情就是某种破解，比如制作
programming parts of an organization work differently from the rest.
组织的编程部分与其他部分的工作方式不同。
Perhaps the optimal solution is for big companies not even to try to develop ideas in house, but simply to buy them.
也许对于大公司来说，最佳的解决方案是甚至不尝试在内部开发想法，而只是购买它们。
But regardless of what the solution turns out to be, the first step is to realize there's a problem.
但无论解决方案是什么，第一步都是要意识到问题的存在。
There is a contradiction in the very phrase "software company." The two words are pulling in opposite directions.
“软件公司”这个词本身就存在矛盾。这两个词正在向相反的方向拉力。
Any good programmer in a large organization is going to be at odds with it, because organizations are designed to prevent what programmers strive for.
大型组织中的任何优秀程序员都会对此表示反对，因为组织的设计就是为了阻止程序员所追求的目标。
Good programmers manage to get a lot done anyway.
无论如何，优秀的程序员都能完成很多工作。
But often it requires practically an act of rebellion against the organizations that employ them.
但通常它实际上需要对雇用他们的组织采取反叛行为。
Perhaps it will help if more people understand that the way programmers behave is driven by the demands of the work they do.
如果更多人了解程序员的行为方式是由他们所做工作的需求驱动的，也许会有所帮助。
It's not because they're irresponsible that they work in long binges during which they blow off all other obligations, plunge straight into programming instead of writing specs first, and rewrite code that already works.
这并不是因为他们不负责任，而是因为他们长时间狂欢工作，在此期间他们抛开了所有其他义务，直接投入编程而不是先编写规范，并重写已经可以工作的代码。
It's not because they're unfriendly that they prefer to work alone, or growl at people who pop their head in the door to say hello.
这并不是因为他们不友好，而是因为他们更喜欢独自工作，或者对那些探出头来打招呼的人咆哮。
This apparently random collection of annoying habits
这显然是随机收集的恼人习惯
has a single explanation: the power of holding a program in one's head.
只有一个解释：将程序牢记于心的力量。
Whether or not understanding this can help large organizations, it can certainly help their competitors.
无论理解这一点是否可以帮助大型组织，它肯定也可以帮助他们的竞争对手。
The weakest point in big companies is that they don't let individual programmers do great work.
大公司的弱点是他们不让个体程序员做出出色的工作。
So if you're a little startup, this is the place to attack them.
因此，如果您是一家小型初创公司，那么这里就是攻击他们的地方。
Take on the kind of problems that have to be solved in one big brain.
解决那些必须用一个大大脑来解决的问题。
Thanks to Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev, and Stephen Wolfram for reading drafts of this.
感谢 Sam Altman、David Greenspan、Aaron Iba、Jessica Livingston、Robert Morris、Peter Norvig、Lisa Randall、Emmett Shear、Sergei Tsarev 和 Stephen Wolfram 阅读本文的草稿。