这一章提出了一个经典概念：“人月”是个坑人的单位。一个人干一个月的工作量，不等于两个人干半个月——但不懂行的人总这么以为。书里那句名言我印象很深：向一个已经延期的项目增加人手，只会让它更加延期。
第一次读到这句话，觉得有点反直觉。多派人手不是应该加快进度吗？但仔细想想书里的解释，就明白了。首先，很多工作是无法拆分的。就像写代码，一个功能没写完，另一个人没法接着写，强行分派只会造成混乱。其次，人多了沟通成本就上去了。两个人合作需要沟通，五个人合作需要更多沟通，十个人合作？光是开会就能占去一半时间。新人来了还得有人教，这段时间不仅没产出，还拖慢了老人的进度。
虽然我还没经历过真正的大型项目，但这个道理放在学习上也适用。比如期末复习，不是同时翻开三本书就能学得更快。有些知识需要按顺序消化，急不来。写作业也是，一个模块没想清楚就急着开另一个，结果往往是两个都写不好。
书里还提到一个概念叫“乐观主义”。程序员总有一种迷之自信，觉得“这个bug马上就能修好”“这个功能两天就能写完”。我也是这样，每次预估时间都过于乐观，最后调试的时间比写代码的时间还长。书里说这是因为我们总假设一切顺利，但软件开发从来不是一帆风顺的。
读完这章，我开始反思自己做计划的方式。以后不管是写代码还是做其他事，都得把意外情况算进去。理想很丰满，现实很骨感，给“意外”留点余地，总比最后手忙脚乱要好。