粗略读完Paul Graham的《黑客与画家》，收获并不太多，大抵是修为境界还远远不够。不过一边读一边回忆其他人的言论，倒是有些观点可以总结到一起，作为一种指导：

1. 不断地迭代：写丑陋的代码、改进质量、将其抛弃；
2. 为开源活动做出真正的贡献；
3. 多调试，少设计；
4. 用适当的语言做适当的事情，比如用Lisp思考、用Python做原型、用C或Java实现（Graham认为完全可以用Lisp来做开发，并且这种非大众语言甚至是一种壁垒性的竞争优势，我不认同）；
5. 做产品时，先快速出原型，再根据反馈改进（《软件开发者路线图》将其称之为反馈回路越短越好）；
6. 不要过早关注细节（或者说过早优化是万恶之源）；
7. 不被打扰状态将产生N倍的工作效率。

此外，《黑客与画家》这篇散文里，对“计算机科学”这一概念的质疑，我从心底赞同。将researcher、engineer、hacker产生价值的过程加以本质性区分，绝对是有必要的——事实上，我一直困惑于，总认为学术成果是最重要的，但又喜欢工程性或hack的东西，因此目标在两者之间不断徘徊。虽然还是没有真正明白hacker创造财富的本质，但至少主观上对这样的道路很坦荡。

说起内心坦荡，有一篇文章提到“不敢说出来的话”，其中的一个观点：每个学科的研究工作所需要的能力显然是大不相同的，但这样的观点在任何一个学校里都不能直白地摆到台面上来说。实际上我觉得，真正坦然地去承认这一点——承认总有那么一大批人是比自己强的，才是面对现实。内心不被主观情绪蒙蔽，方能认清自己的价值所在。

已经很久没有完整地精读一本书了，我终于意识到这是一件很奢侈的事。

要想明白为什么奢侈，首先得做一下划分：

1. 以消遣为目的，比如看小说，这种读书已经很久没有过了；
2. 以学习知识为目的，比如看经管、数学、英语等，也很久没有过了；
3. 以理解知识为目的，这是目前主要的。

后两者实际是难以区分的，但不区分开就造成了目前的坏习惯——用看第2种的方法来看第3种。

进一步说，第2种阅读的特点是：不太需要思考，但需要全方位了解。这种阅读的高峰出现在我大二到大四时，以整天泡图书馆为代表。用一个词来描述的话，是“吞噬”。因为知识极度匮乏，所以是原始积累阶段，见什么搂什么；又因为匮乏，所以需要什么都去学才能继续下去。于是最多会有平均两天一本的速度。但这个时期所学的都是概念性知识，也不会深入。

但目前的阅读变了。在很多外围知识已经知道的情况下，需要的是思考——对模式的理解、对逻辑的重建。真正要学的，已经不是一个东西是什么，而是为什么这样。这种的阅读，如果再用每天几十上百页的速度，反而是浪费时间。

实际上我应该有这样的经验。学数学的同学们，往往一年能读完领域内两本经典著作，就很了不得了。数学是最典型的逻辑关系主导一切的知识，甚至于其中的定义都是由逻辑需要而衍生的。

年初有简单地思考：“过去的一年，读了哪些书？一年的时间，到底能读几本书？”于是在制定的计划中，今年精读不超过15本，同时跟进六七本期刊的出版进度。

而现在要再一次削减了。我打算每年精读不超过6本书，每个月细读不超过5篇论文。

而实际上6还是一个很恐怖数字。今年想在Linux内核和开发方面深入一点，但平心而论，APUE、UNP、LKD、LDD、ULK这五本书，有几个人能两年之内认真地读完？

想读的书真是太多，所以读哪些又成了头痛的问题。是确定将来方向的时候了。

这个世界已经趋于人云亦云了——在几个钟头前，墙内外的网络社区都在疯传着一个老作家逝世的消息，而没有多少人会去较真地验证一下。可恨的是，科技不但在传播上助长了这种人云亦云，更在反面推动了这一趋势——就算想验证这样的消息，还是会陷入大量虚假消息的泥潭，而一无所获。

一个朋友说：“中国人啥都信，也啥都不信。”然而，毛大爷传下来的后一种品质正在被人们所抛弃，思想也变得越来越快餐化。

《三体III》和这样一种“人云亦云化”的关系在于，几乎所有的人都说它好，于是后来的人也跟着说好，似乎不说好就不能体现自己的欣赏能力。

我的看法是，《三体III》存在以下几个问题：

Continue reading →

Seibel: 很多人都赞同你所说的，自己写代码更有乐趣。但除了乐趣之外——

Knuth: 不仅仅是乐趣而已。数学家的工作是给出证明，但在你求解数学问题时，几乎找不到某个定理的假设和你求解问题所需的假设恰好一模一样。通常来说，你已经得到了一个类似于书上定理的东西，你要做的就是看看它的证明，然后说，“嗯，为了证明我手头现有的假设，我要这样改动一下这个证明。”所以说，虽然数学书里总是塞满了定理，但你永远找不到严丝合缝的那个。你想看见的还是那个需要改动的证明，因为正好找到你想要的定理的概率只有百分之一。我认为这和软件的情况恰好吻合。

Seibel: Many people will agree with you that, yes, it’s more fun to write the code yourself. But other than the fun—

Knuth: It’s not only fun. The job of a mathematician is to make proofs but almost never, when you’re solving a mathematical problem, do you find a theorem for which the hypotheses are exactly what you need for the problem you’re solving. Almost always you’ve got something that’s sort of like the theorem that’s in the book. So what you do is you look at the proof of that theorem and you say, “Oh, here’s how I have to change that proof in order to prove the hypothesis that I really have.” So mathematical books are packed with theorems, but you never plug in exactly the theorem—you want to see that proof because it’s one time in a hundred when you’ll find just the theorem that you wanted. I think it’s exactly the same with software.

选自：Peter Seibel. Coders at Work : Reflections on the Craft of Programming. APress, 2009。中译本将由人民邮电出版社图灵公司翻译出版。

正好解了自己一段疑惑。

• Principles of Computer System Design : An Introduction
  MIT6.033 ”Computer Systems Engineering”的Lecture Notes结集出版而成。不抽象、不具体，对CS中的各种principle和idea讲得恰到好处。这本书第一卷在网上购买，国内也有影印版。第二卷作者将其available on-line了。特别推荐这本书和这门课。
• Binary Hacks，O’Reilly
  对开发中的二进制文件进行byte级别的hack，由一篇篇tips构成，侧重于操作。今天刚刚翻到这本书，觉得和正在读的《程序员的自我修养——链接、装载与库》一起看不错。这本书有中译本。
• Pragmatic Bookshelf
  这是个出版公司，我觉得他们的书都挺有意思的。刚刚看完《高效程序员的45个习惯：敏捷开发修炼之道》，正准备开始翻他们的《版本控制之道》、Ship It! A Practical Guide toSuccessful Software Projects。
• The Elements of Style
  这本书已经有92年的历史，所以必然是与计算机无关的。事实上，这是一本非常优秀的关于英文写作的小册子。它将一些构句的基本原则以rules的形式列举出来，并且通过例子加以对照、解释、说明。它只有不到50页，阅读起来并不费时间。我曾经打算翻译这本书，但发现作为一本英语文法的书，还是保持原汁原味比较好。至于从哪里获取……我记得著作权一般死后只保留50年吧，你们懂的。