第三、四、五、六章，是一些实际项目的系统设计准则，知晓即可。第七章和第八章分别阐述了交流的必要性和实践中学的重要性。巴比伦塔会失败？这是第七章的开篇发问，巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。“因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假设，团队成员之间的理解开始出现偏差。交流是我一直以来比较欠缺的能力，一方面是个人性格，另一方面则是每每表述完后，仍然存在的误解和割裂打击着我再次交流的想法。
第八章中提到实践是最好的老师，但如果不能从中学习，再多的实践也没有用。估算有三个要素。一是实践。二是量化指标。三是根据量化的指标建立模型。而名言的意思是，实现->量化指标->估算模型->实现->量化指标->重新建立模型。是一个不断实践和学习的循环。编程是一个多敲代码总有收获的活动，初学C语言编程老师也反复强调代码量是关键，之后的数据结构课老师也把“敲个百遍，其意自现”类似的语句反复告诫。这两章的内容放之四海而皆准，无论哪个专业哪门学科，都是值得学习于参考的。
后面的章节我就草草翻过去了，一方面有些书中内容已经过时了，譬如第九章在讲解程序占用资源的控制、第十二章干将莫邪讲解辅助机器与工具，另一方面部分章节的思想在软件工程的课上也有所涉猎，如第十三章整体部分防范bug的方法：1、防范bug要从产品定义开始。2、先让各个部分都能够单独工作，再进行整体联调。就是软件测试的自顶向下和自底向上的测试方法。
“没有银弹”是一个很酷的概念，在没有银弹与人月与再论没有银弹章节中提到：软件开发的根本困难是搭建什么样的系统既需求，次要问题是搭建系统的技术和编码过程。根本困难的复杂性、一致性、可变性和不可见性，决定了10年内开发效率不会有量级的提升。但可用的改进方法是：购买软件产品包、需求精炼与快速原型、增量开发——增长而非搭建系统、面向对象、重用（重用会带来词汇量增加的问题）。没有任何技术或管理上的进展，能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。这是软件本身的性质所带来的缺陷，但随着时代的进步，技术的不断发展，包括面向对象技术和软件复用等等，这些便利的新技术是否就是软件业界在寻找的银弹呢？