第五章 管束奇客和狗
用代码行数做判断标准只会鼓励程序员写臃肿、蹩脚的代码。
即时通信、聊天室、缺陷跟踪、源借故传统的邮件列表等工具，个人感觉要慎用这些工具，否则你的工作时间会被这些工具吃得一干二净。
第六章 搞掂设计方案
别做大项目。从小项目开始，而且永远不要期望它变大。如果这么想（指做大型软件），就会做过度设计，把它想象行过于重要。更坏的情况是，你可能会被自己想象中的艰难工作所吓倒。所以要从小处起步，着力考虑细节。别去想大图景和好设计。如果项目没解决某些需求，多半就是被过度设计了。
别指望在短时间内达到大成就，我致力于Linux达13年之久，我想后面还得花上好些时间。如果一早就妄想做个大东西，可能现在还没动手呢。
第七章 细节视图
需求搞错的严重后果，18英尺的巨石拱门变成了18英寸的石桩子。
第八章 白板上的即时贴
非常敬佩写标准的人，你要用5年为计量标准的眼光看问题。得花上5年时间，才能得到你真正想要的有用之物。
用贴纸法来讨论项目各个小版本应该具有的功能特性，也是敏捷开发里重点推广的。
第九章 方法
IBM执行强制进度纪律的成功基于两条原则：
1）计划是强制性的
2）计划必须符合现实情况 ----“从底向上”，依据那些负责按计划执行的程序员的经验和知识而来，而不是“从顶至下”，靠管理者拍脑袋或对市场的期望而来。
第十章 工程师和艺术家
编程是工程还是文学？是科学还是艺术？
高德纳写的书名叫《计算机程序设计艺术》，他在1984年获得图灵奖时发表感言说：“计算机编程是门艺术”。写《计算机程序设计艺术》这本书他花了十年，写TeX和metafont程序设计没写到也花了近10年。他宣称，写软件要比写书“难多了”。
第十一章 通往狗食版之路
吃自己的狗粮，这种思路确实有助于提升软件质量和用户体验，想想连自己都不屑一用的软件凭什么去折磨用户呢？
尾声 长赌
机器会越来越复杂，但不会比运行他们的社会更复杂。
你越懂软件，就越不会去做软件。