将程序放在脑子里
一个好的程序员专攻其代码的方式，就像一个数学家解决问题的方式一样。数学家解决问题的方式并非像小学生那样在纸上解出答案。他们在脑子里做更多的事情：他们尝试足够多的去理解问题的空间，并徜徉其间，就像你能在你的回忆中走遍你小时候住过的房子一样。这和编程一样。你将整个程序放在你的脑子里，并根据你的意愿操控它。
在一个项目的初始，这是非常珍贵的。因为最初最重要的事情是可以改变你正在做的事。并不仅仅是用不同的方式解决问题，而是改变你正在解决的问题。
你的代码是你对你正在探索的问题的理解。因此仅仅在你脑子里有代码的时候你才真正了理解了那个问题。
把一个程序放到脑子里并不简单。如果你离开一个项目数月，当你重新接手时，可能需要几天时间来重新理解它。即使你天天持续与它保持亲密接触，每天开工前你还是需要半小时来将它载入到你脑中。并且那是最好的情况。工作在特定办公环境下的普通程序员从不会进入他自己的模式。或者戏剧性的来讲，工作在特定办公环境下的普通程序员从不会真正理解它们正在解决的问题。
即使最棒的程序员也不能总是将整个程序装到他们脑中。但以下几条会对你有所帮助：
1. 避免注意力分散。注意力分散对很多种类的工作都不好，对编程来说尤其不好，因为程序员倾向于操控他们能控制的细节的极限。分散注意力的危险不取决于它持续多长，而取决于它有多扰乱你的大脑。一个程序员可以离开办公室，走去拿三明治而不会丢失其脑中的代码。但糟糕的打扰类型却能在30秒内擦除这一切。足够古怪的是，有计划的注意力分散可能会比无计划的注意力分散更糟。如果你知道一小时后会有一个会议的话，你甚至直接不会开始做某些困难的事情。
2. 长周期工作。因为每次开始做一个程序时都有一个固定成本，以长周期的形式工作，会比以n个短周期工作要高效。当然这同时会引入一点，当你疲惫时你会变蠢。在这一点上，人与人不同。我见过有人连续工作36个小时，但我最多能够持续18个小时，而对于我来说，最好的状态是低于12小时。
3. 使用简明的语言。越强大的编程语言使得代码越短。程序员往往会至少将一部分程序以他们正在使用的语言来进行思考。使用的语言越简明，程序便越短，也更容易被载入和保存在你脑中。你可以通过应用自底向上（从细节到整体）编程法来放大一个语言的效果。即用多层级来写程序，底层的部分作为上层的编程语言。如果你正确做到这点，你仅需要将最上层的记在脑中即可。
4. 持续重写你的程序。重写程序常屈服于一个更干净的设计。但他的好处是：你必须完全理解一个程序从而才能重写之，因此没有比这更好的方式来将它装在你的脑子里。
5. 写可以被重读的代码。所有程序员都知道写可以读懂的代码的好处。但你自己是最重要的读者。尤其在开始时，原型是你与自己的对话。为你自己写作，你会有不同的优先级。如果为别人写，你会不想要把代码弄得太密。某些部分如果被拆分开或铺开也许就会更好读，就像入门教材。相反，如果你要写易于你被载入你脑中的代码，写的简明是最好的。
6. 小团队作业。当你在脑中操纵一个程序时，你的想象倾向于停在你拥有的代码边缘。其他部分你也不会理解，更重要的是，没有自由。因此，程序员数量越少，一个项目能变得越完整。如果仅有一个程序员，就像往往一开始的时候那样，你能做全包围的重新设计。
7. 不要让多人编辑代码的相同片段。你不可能像理解你自己的代码一样理解别人的代码。无论你如何彻底的阅读它，你做的也仅是阅读它，而不是写它。因此如果一个代码片段被多人来写，他们中任何一位的理解都不会像一个单独的作者理解那么到位。
当然，你不能安全的重新设计其他人正在做的东西。这不仅仅是你需要获得允许的问题。你甚至不该这么去想。若干个作者重新设计代码就像修改法律；而你自己重新设计代码则像是看别人对一副充满歧义的图画的阐述。
如果你要让多人共同进行一个项目，把它分成多份并将每一份给到不同的人。
8. 从小的开始。一个程序会随着你对其的了解加深而被更容易的记住。你可以先对待那些你感到有信心已完全掌握的部分。但当你开始一个项目的时候，你将被强迫关照一切。如果你从一个很大的问题着手，你可能会不那么容易解决它。因此如果你需要写一个又大又复杂的程序，开始最好不要写它的细则，而是写一个解决问题子集的原型。无论计划的优势是什么，它们常因记住一个程序的优点而变得更有价值。
程序员偶然达成以上八点的频率令人惊奇。有的人有做一个新项目的点子，但因为其并未得到官方认可，他不得不用业余时间来做它————其结果是因为没有精力分散而变得更高产。有热情驱动而长时间去做。因为它起初只是一个实验，相对一个“产品”语言，它仅适用“脚本”语言————实际上却更强大。他完全地多吃重写程序，这对一个官方项目来说是不可理解的，但这是爱的劳动结晶并且他想要它趋于完美。因为没人会看到，因此他省略了除了能够起到自我注释作用的注释。他一定是在小范围里工作，因为他要么没有告诉过任何人这个点子，要么它看起来如此没前途因此没有人会参与。即使有个小团队，他们也不可能会让不同的人去编辑相同的代码片段，因为变化太快。这项目会从小处开始，因为这个点子本身也是从小开始：他仅仅是有一些很酷的想法想要尝试。
-----------------------------
出处：http://paulgraham.com/head.html
翻译：妄为
在一个项目的初始，这是非常珍贵的。因为最初最重要的事情是可以改变你正在做的事。并不仅仅是用不同的方式解决问题，而是改变你正在解决的问题。
你的代码是你对你正在探索的问题的理解。因此仅仅在你脑子里有代码的时候你才真正了理解了那个问题。
把一个程序放到脑子里并不简单。如果你离开一个项目数月，当你重新接手时，可能需要几天时间来重新理解它。即使你天天持续与它保持亲密接触，每天开工前你还是需要半小时来将它载入到你脑中。并且那是最好的情况。工作在特定办公环境下的普通程序员从不会进入他自己的模式。或者戏剧性的来讲，工作在特定办公环境下的普通程序员从不会真正理解它们正在解决的问题。
即使最棒的程序员也不能总是将整个程序装到他们脑中。但以下几条会对你有所帮助：
1. 避免注意力分散。注意力分散对很多种类的工作都不好，对编程来说尤其不好，因为程序员倾向于操控他们能控制的细节的极限。分散注意力的危险不取决于它持续多长，而取决于它有多扰乱你的大脑。一个程序员可以离开办公室，走去拿三明治而不会丢失其脑中的代码。但糟糕的打扰类型却能在30秒内擦除这一切。足够古怪的是，有计划的注意力分散可能会比无计划的注意力分散更糟。如果你知道一小时后会有一个会议的话，你甚至直接不会开始做某些困难的事情。
2. 长周期工作。因为每次开始做一个程序时都有一个固定成本，以长周期的形式工作，会比以n个短周期工作要高效。当然这同时会引入一点，当你疲惫时你会变蠢。在这一点上，人与人不同。我见过有人连续工作36个小时，但我最多能够持续18个小时，而对于我来说，最好的状态是低于12小时。
3. 使用简明的语言。越强大的编程语言使得代码越短。程序员往往会至少将一部分程序以他们正在使用的语言来进行思考。使用的语言越简明，程序便越短，也更容易被载入和保存在你脑中。你可以通过应用自底向上（从细节到整体）编程法来放大一个语言的效果。即用多层级来写程序，底层的部分作为上层的编程语言。如果你正确做到这点，你仅需要将最上层的记在脑中即可。
4. 持续重写你的程序。重写程序常屈服于一个更干净的设计。但他的好处是：你必须完全理解一个程序从而才能重写之，因此没有比这更好的方式来将它装在你的脑子里。
5. 写可以被重读的代码。所有程序员都知道写可以读懂的代码的好处。但你自己是最重要的读者。尤其在开始时，原型是你与自己的对话。为你自己写作，你会有不同的优先级。如果为别人写，你会不想要把代码弄得太密。某些部分如果被拆分开或铺开也许就会更好读，就像入门教材。相反，如果你要写易于你被载入你脑中的代码，写的简明是最好的。
6. 小团队作业。当你在脑中操纵一个程序时，你的想象倾向于停在你拥有的代码边缘。其他部分你也不会理解，更重要的是，没有自由。因此，程序员数量越少，一个项目能变得越完整。如果仅有一个程序员，就像往往一开始的时候那样，你能做全包围的重新设计。
7. 不要让多人编辑代码的相同片段。你不可能像理解你自己的代码一样理解别人的代码。无论你如何彻底的阅读它，你做的也仅是阅读它，而不是写它。因此如果一个代码片段被多人来写，他们中任何一位的理解都不会像一个单独的作者理解那么到位。
当然，你不能安全的重新设计其他人正在做的东西。这不仅仅是你需要获得允许的问题。你甚至不该这么去想。若干个作者重新设计代码就像修改法律；而你自己重新设计代码则像是看别人对一副充满歧义的图画的阐述。
如果你要让多人共同进行一个项目，把它分成多份并将每一份给到不同的人。
8. 从小的开始。一个程序会随着你对其的了解加深而被更容易的记住。你可以先对待那些你感到有信心已完全掌握的部分。但当你开始一个项目的时候，你将被强迫关照一切。如果你从一个很大的问题着手，你可能会不那么容易解决它。因此如果你需要写一个又大又复杂的程序，开始最好不要写它的细则，而是写一个解决问题子集的原型。无论计划的优势是什么，它们常因记住一个程序的优点而变得更有价值。
程序员偶然达成以上八点的频率令人惊奇。有的人有做一个新项目的点子，但因为其并未得到官方认可，他不得不用业余时间来做它————其结果是因为没有精力分散而变得更高产。有热情驱动而长时间去做。因为它起初只是一个实验，相对一个“产品”语言，它仅适用“脚本”语言————实际上却更强大。他完全地多吃重写程序，这对一个官方项目来说是不可理解的，但这是爱的劳动结晶并且他想要它趋于完美。因为没人会看到，因此他省略了除了能够起到自我注释作用的注释。他一定是在小范围里工作，因为他要么没有告诉过任何人这个点子，要么它看起来如此没前途因此没有人会参与。即使有个小团队，他们也不可能会让不同的人去编辑相同的代码片段，因为变化太快。这项目会从小处开始，因为这个点子本身也是从小开始：他仅仅是有一些很酷的想法想要尝试。
-----------------------------
出处：http://paulgraham.com/head.html
翻译：妄为
