这本书作者是stack overflow的创始人之一

里面有几个很有意思的观点值得记录分享一下。

待办事项不靠谱

每24小时就有一个To-Do软件发布，所以你大概需要一个To-Do软件来跟踪发布的新的To-Do软件。

所以不需要用到代办列表这种东西。它是一种折磨，会给你一种你正在进行的错觉。未完成的事又会给你负罪感和压力。

最好就只在代办列表上留一项。

或者每天清早起床时就想出今天一天最重要的三个事然后完成它。

你没有说服我

如果你想影响别人，你必须有能力说服他们。

成功的软件工程师要有好的说服能力。

方法：

从总体上说，观点是相当出色的

做事的方法自下而上

总能带头亲自做事

拥有足够的耐心等待机会的到来

勿以专家自居

作为一个专家，重要的不是告诉别人你就知道什么，而是要清楚你该问什么样的问题。

持续学习的过程

克服了漫不经心：我现在明白了，我需要学点东西

克服了恐惧：我觉得我可以学会这个技能。我会对它变得很了解，而不会惧怕比我懂得多的人

我变得有条理：我不再觉得自己不懂装懂或者不学无术。我觉得我有能力参加讨论或实践。我对自己说的话很有信心。

我超越了自身能力：现在我觉得对自己有了更高的要求。我想冒一点风险，富有创造力，不断学习，想要与那些充满热情的人共事。

管理中要有信任

大型软件项目成功率很低，最好的管理方案是“信任”

信任也是无法代替管理的

关于绩效考核：

丘吉尔有句名言，要不是由于其他形式都行不通，民主制度会是最糟糕的政府模式（democracy is the worst form of government except for all those others that have been tried）

毫无疑问，绩效考核可能会产生糟糕的影响，但是在有更好的形式替代之前想要摒弃绩效，只不过是图一时口舌之快。

博伊德迭代法则

迭代的速度胜过迭代的质量

一些测试的建议：

单元测试必须小而快，以便每次编译时都能运行

可用性测试：以两周为一个周期来做一些小改动，并且快速抛弃掉不好的部分

大多数敏捷开发都建议，迭代周期不超过4周

软件测试就是（在发布之前）让它提早失败，经常失败。

功能规范书最好能简明扼要，并且持续改进

切忌一根筋

《编程大师访谈录》

比尔盖茨的一个回答。

问：若要做好编程工作，必须积累很多年的经验才行吗？

比尔•盖茨答道："不是这样的。我觉得在最开始的3〜4年后，你是不是一名优秀的程序员就已经定型了。更多年的历练，只会让你更多地了解到大项目管理和人员管理。3〜4年的时间足以看清你的未来。在微款，没有一个人是在一开始几年毫无 建树，而在后来出人意料地成为多面手的。通过和一个人聊他所写的程序，我可以马上看出他是不是一名优秀的程序员。"

但是你可以成为一名更好的程序员，培养自己对于编程周边所有事情的热情。

后来在2005年的一次访谈中，比尔•盖茨继续阐述了他在1986年的观点。

工作的本质并不是闭门造车（埋头写代码），我相信这一点很容易理解。最最匮乏的人才是那些既对工程技术有超强的领悟能力，又可以与核心开发人员建立良 好的关系，并且可以充当与客户、市场等之间桥梁的人。像这种工程管理人才，即 使在微软也是很缺的，所以我们不得不经常鼓励一些人去尝试。

我很希望看到有更多人投身于这些职位。他们除了掌握基本的工程技能之外，也把人员管理和群体动力看作是一项对自己的历练。要是这样，那就太好了 ！

只有技能不够，客户、行业和业务也很重要。

最牛的编码套路

这一小节太好了。整个摘抄下来。

最近，我大量阅读了Steve Yegge的文章。其中有一篇叫"Practicing programming"(练习编程），写成于2005年，读后令我惊讶不已。

与你所相信的恰恰相反，单纯地每天埋头于工作并不能算是真正意义上的锻炼 。参加会议并不能锻炼你的人际交往能力；回复邮件并不能提高你的打字水平。 你必须定期留出时间，集中锻炼，这样才能把事情做得更好。

我认识很多杰出的程序员——这是在亚马逊工作最好的额外"福利"之一。如果仔细观察他们，你会发现他们时时都在锻炼。他们已经很优秀了，但仍然不忘锻炼。他们锻炼的方法林林总总，而我在这篇文章中只会介绍其中的几种。

据我了解，这些杰出程序员之所以如此成功，就是因为他们一直在锻炼。完美的身材要靠定期的锻炼才能获得，而且必须坚持锻炼才能保持，否则身材就会走形。 对于编程和软件工程来说，道理是一样的。

这是一个重要的区别我每天都开车去上班，但我的驾驶水平远远不如专业车手；类似的情况，天天编程可能并不足以使你成为一名专业的程序员。那么，什么才能把一个普通人变成一名专业车手或者专业程序员昵？你需要锻炼什么呢？

答案就在《科学美国人》的一篇名为"the expert mind"(专家思维）的文章里。

爱立信提出，重要的并不是经验本身，而是"努力地学习"，也就是要不断地挑战自身能力之外的东西。一些狂热的爱好者花费了大量的时间去下棋，打高尔夫球或者玩乐器，但他们可能始终停留在业余水平，而一个训练有素的学生却可以在相对较短的时间里超越他们，原因就在这里。值得注意的是，在提高水平方面，花费在下棋上的大量时间（即使参加各种比赛）似乎还是比不过专门的训练来得更为有效。训练的主要价值在于发现弱点，并有针对性地进行提高。

"努力地学习"意味着，要常常去处理那些刚好在你能力极限上的问题，也就是那些对你来说有很大可能失败的事情。如果不经历一些失败的话，你可能就不会成长。你必须不断地挑战自我，超越自己的极限。

那样的挑战有时会在工作中碰到，但也未必。将锻炼从职业工作中分离出来，

这在编程领域常被人称为"编码套路"（code kata）。

所谓套路，就是一系列的招式。这个概念借鉴于武术。

如果你想要看一些编码套路的例子（也就是努力学习和磨练编程技能的方法)，steve Yegge的文章里倒是提出了一些不错的建议。他把它们称作为“实践演练”：

1.写一份自己的简历。把自己所有的相关技能都罗列出来，然后把那些在100年后还用得到的标出来。给每个技能打分，满分为10分。

2. 罗列出你所景仰的程序员。尽量包括那些与你一起工作的人，因为你会在工作中从他们身上获取一些技能。记录下他们身上的1〜2个闪光点，也就是你希望自己有所提高的方面。

3. 查看维基百科上的"计算机科学"栏目，找到"计算机领域先驱者"这个分类（网址：http://zh.wikipedia.org/wiki/Category 计算机领域先驱者），从这个列表中挑选一个人，阅读他的事迹，并且在阅读读时打开任何你感兴趣的链接。

4. 花20分钟通读别人的代码。读出色的代码和读糟糕的代码都是有益的，两者都要读，轮流切换。如果你无法感觉出它们之间的区别，可以求助于一位你尊敬的程序员，让他给你展示一下什么是出色的代码，什么是糟糕的代码。把你读过的代码也给别人看看，问问他们的看法。

5. 罗列出你最喜欢的10个编程工具——那些你觉得你用得最多、缺了它们不行的工具。从中随机挑选一个，花一个小时去阅读它的文档。在这一个小时里，努力去学习这个工具的某个你不曾意识到的新功能，或者发现某种新的使用方法。

6.想一想，除了编程之外作最擅长什么事情？再想一想，你是通过怎样的锻炼才变得如此熟练和专业的？这对于你的编程工作又有什么启发呢？（怎么把这些经验应用到编程方面？）

7.拿出一叠简历，并和一组面试官在同一个房间里持上一个小时。确保每份简历都至少被3个面试官看过，并且要給出1〜3分的评分。针对那些不同面试官评判大相径庭的简历展开讨论。

8.参与一个电话面试。事后写下你的反馈，抛出你的观点，然后与主持电话面试的人聊一聊，看看你们是否达成了一致的结论。

9. 进行一次技术面试，并且被面试的人应该是某个你不太了解的领域里的专家。让他假定听众在该领域里一无所知，因此请他从最基础的讲起。努力去理解他所说的，必要时问一些问题。

10. 有机会参与别人的技术面试。期间，你只是认真地听，认真地学。在应聘者努力解决技水问题的同时，你也要在自己脑子里尝试解决这些问题。

11. 找到一个能和你交换实际问题的人，每隔一周，相互交流编程问题。花 10〜15分钟来尝试解决这些问题，再用10〜15分钟进行讨论（无论能否解决）。

12. 当听到任何一时间你也无法解决的面试问题时，赶紧回到你的座位上，把这个问题用电子邮件发给自己，以留作日后的提醒。在那一周里找出点时间，用自己最喜欢的编程语言来解决它。

我之所以喜欢steve开出的这个清单，是因为它看上去很全面。有些有些程序员一想到"锻炼"，总认为就是一些编码上的难题。但在我看来，编程更在于人，而不是代码。因此，通过解决世上所有的、晦涩的编程面试题目，来提高你的个人能力， 这种方法是有局限的。

关于"努力地学习",我也很喜欢Peter Norvig在"Teach Yourself Programming in Ten Years" (花10年时间自学编程）一文中提出的诸多建议：

1. 与别的程序员交流。读别人的代码。这比任何书籍或培训课程都更重要。

2. 动手写程序！最好的学习方法就是边做这学。

3. 在本科或研究生的课程中学习编程课程。

4. 找一些项目来做，并且需要与其他程序员形成团队来合作。在项目的进行过程中，学会辨别最出色的程序员以及最槽糕的程序员。

5. 在项目中跟随别的程序员一起工作，了解如何维护那些不是你写的代码，并且学习如何写出利于他人维护的代码。

6. 学习多种不同的编程语言，特别是那些与你现在所熟悉的语言有着不同的世界观和编程模型的。

7. 了解硬件对软件的影响。知道你的计算机执行一条指令需要多少时间，从内存中取出一个字（在有缓存或没缓存的情况下）需要多少时间，在以太网（或者因持网）上传输数据需要多少时间，从磁盘中读取连续的数据或者在磁盘上跳转到另一个位里需要多少时间，等等。

你还可以从Dave Tomas的21种实用的编码套路中获取灵感(codeKata.com)，或者你更愿意加入一个你家当地的"编程武馆"(CodingDojo.org) 。

对于"努力的学习"，我无法像Steve、Peter或者Dave那样提供一个长长的建议列表。我远不如他们有耐心。实际上，在我看来，"编程套路"只需下面两个招式。

1.写博客。我在2004年初创办了codingHorror.eom博客，作为我自己努力学习的一种形式。它在一开始很不起眼，到后来成为我职业生涯中做过的最重要的一件事。所以，你也应该写博客。最后"闻达于天下"的人，往往就是那些能够有

效书写和沟通的人。他们的声音最响亮，是他们在制定游戏规则，并且引领世界的潮流。

2.积极参与著名的开源项目。所有的高谈阔论听起来都很好，但是，你是一个大话王还是一名实干家呢？别光说不练，这个非常重要，因为人们会用你的行动来衡量你，而不是你的言论。努力在公众面前留下一些实实在在有用的东西吧，到 时候你就可以说："我在那个项目中出过力。”

当你能编写精彩的代码，并且能用精彩的言辞向世人解释那些代码时，到那时候，我会觉得你已经掌握了最牛的编码套路！