看到第六章中的“搞掂”一词，很疑惑，为什么不是“搞定”呢？百度了一下，看到了这样一种结果：“这一章出现了GTD，没想到这本书的产品chandler竟然与GTD也有关系，原来这个软件的UI设计师尹咪咪受到了戴维艾伦的Get Things Done书的影响，不过这里翻译为《搞掂》，而不是《搞定》，看来如果chandler早点发布，流行于世面上的GTD工具可能不会是omnifocus，而是chandler了。”果然知识的累计是异常重要的，这样就不至于在我读书时，脑子却处于“懵”的状态。

      在第9章“方法”中IBM执行强制进度纪律的成功基于两条原则：（1）计划是强制性的（2）计划必须符合现实情况 ----“从底向上”，依据那些负责按计划执行的程序员的经验和知识而来，而不是“从顶至下”，靠管理者拍脑袋或对市场的期望而来。CMM这个沉重的软件开发成熟度模型在国内完全变了味，曾看着一个软件公司为了通过CMM4，编出一堆从来无人细看的厚厚的文档，CMM果然只重过程，而国内更把这种过程流于形式，通过CMM，只为了向用户抬高价码。TSP、PSP也看过，感觉相当繁琐，在国内都难于实行。2001年17位领军人物，提出了敏捷软件开发宣言，向这种笨重的CMM宣战，从此极限编程XP和SCRUM开始流行。Google让开发者把五分之一的时间花在个人项目上。这种管理方式在国内想都不敢想。

      在第10章“工程师和艺术家”中的问题：编程是工程还是文学？是科学还是艺术？

      在第11章中出现了一个神奇的地方：吃自己的狗粮。这种思路确实有助于提升软件质量和用户体验，想想连自己都不屑一用的软件凭什么去折磨用户呢？真的可以说是十分有趣了。