最近，我阅读了人月神话的下一部分，有了一些感悟。
过去，我对于团队之间的交流不够重视。非正式途径，清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对所书写文档的共同理解。会议，常规项目会议，会议中，团队一个接一个地进行简要的技术称述。这种方式非常有用，能澄清成百上千的细小误解。工作手册，在项目的开始阶段，应该准备正式的项目工作手册。在以后，可以更加重视团队之间的交流。
过去，我认为实践是非常重要的。实践是最好的老师，但是，如果不能从中学习，再多的实践也没用。在以后，实践是应考虑能不能从实践中得到学习。
过去，我对于规模的控制不够重视。由于规模是软件系统产品用户成本中如此大的一个组成部分，开发人员必须设置规模的目标，控制规模，考虑减小规模的方法，就像硬件开发人员会设立元器件数量目标，控制元器件的数量，想出一些减少零件的方法。同任何开销一样，规模本身不是坏事，但不必要的规模是不可取的。在以后，可以更加重视规模的控制。
过去，我对于正式的文档的原因理解不够。首先，书面记录决策是必要的，只有记录下来，分歧才会明朗，矛盾才会突出。第二，文档能够作为同其他人的沟通渠道。最后，项目经理的文档可以作为数据基础和检查列表。在以后，可以更加重视有正式文档的原因。
过去，我对于变化的认识还不够。唯一不变的就是变化本省。一旦认识到实验性的系统必须被构建和丢弃，具有变更思想的重新设计不可避免，从而直面整个变化现象是非常有用的。第一步是接受这样的事实：变化是与生俱来的，不是不合时宜和令人生厌的异常情况。开发人员交付的是用户满意程度，而不仅仅是实际的产品。用户的实际需求和用户感觉会随着程序的构建、测试和使用而变化。在以后，可以提升自己对于变化的认识。
过去，我对于高级语言的认识不够。调试上的改进来自下列事实——存在更少的bug，而且更容易查找bug更少的原因，是因为它避免在错误面前暴露所有级别的工作，这样不但会造成语法上的错误，还会产生语义上的问题，如不当使用寄存器等。编译器的诊断机制可以帮助找出这些类似的错误，更重要的是，它非常容易插入调试的快照。在以后，可以更加深入的了解高级语言。