第一遍读完我只记住了书中那句略显逗逼的话：无论多少个母亲，孕育一个生命都需要十个月。

我认为学习编程的最困难部分，是将做事的方式往追求完美的方向调整。

导致项目延期的主要原因：
首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。
第五，当意识到进度的偏移时，下意识的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。

作者关于软件任务的进度安排使用了很多年的经验法则：
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试，所有的构件已完成

每个团队成员认为自己是争取小红花的学生，而不是构建系统软件产品的人员。为了满足目标，每个人都在局部优化自己的程序，很少会有人停下来，考虑一下对客户的整体影响。

系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。

系统各个组成部分的开发者都会做出一些假设（很多可能是隐藏的），而这些假设之间的不匹配，是大多数致命和难以察觉的bug的主要来源。

史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。 过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统–不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。

焦油坑（国内又称 屎山），程序员无法绕开的梦靥。即便在 Google 和 Facebook，焦油坑也到处都是，由于自动化测试/持续集成/代码评审/源代码控制等现代软件工程理念的加成，这些项目不会像人月神话的焦油坑一样沉的那么快，此外，这些公司会定期（每年一次或两次）进行代码大扫除，清理尽可能多的焦油。

当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。无论多少个母亲，孕育一个生命都需要十个月。由于调试、测试的次序特性，许多软件都具有这种特征。

不完全正确。对一些特定任务，添加有领域经验的资深程序员会有奇效，从业近十年，我见过不少案例：几个菜鸡搞了几个月没弄出来，找个大神几天搞定——因为菜鸡见识少，给他们多长时间都搞不出来。添加新人就是在瞎几把搞。

对于软件任务的进度安排，以下是我使用了很多年的经验法则：

1/3计划 1/6编码 1/4构件测试和早期系统测试1/4系统测试

依然适用（不过我不太信国内的公司会花大把时间测试）
在大公司，对大多数项目而言，编码可能是最简单的一环，大部分时间都花在说服领导为啥要做这个项目，以及和同事撕逼抢项目占山头。

向进度落后的项目中增加人手，只会使进度更加落后。

这段话阐述了人月神话（Mythical Man Month）的含义——不能简单的用人月估算项目，人力和时间不能等价替换。
然而在实际中大家还是在往进度落后的项目中增加人手，在我看来，这并不是管理者蠢——甩锅手段而已。而且人越多话语权越大。

软件经理很早就认识到优秀程序员和较差的程序员之间生产率的差异，但实际测量出的差异还是令我们所有的人吃惊。在他们的一个研究中，Sackman、Erikson和Grand曾对一组具有经验的程序人员进行测量。在该小组中，最好的和最差的表现在生产率上平均为10:1；在运行速度和空间上具有5:1的惊人差异！简言之，$20,000/年的程序员的生产率可能是$10,000/年程序员的10倍。

严重低估，最好的程序员和最差的程序员之间能差出天际。
而且差的程序员经常会起到负作用，不少优秀的程序员，都把大把的时间花在排差的程序员的雷上。

我主张在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。

严重同意。系统设计绝对要找做过类似系统的顶尖资深工程师，不然后果不堪设想。

构建独立小型程序的数据不适用于编程系统产品。对规模平均为3200指令的程序，如Sackman、Erikson和Grant的报告中所述，大约单个的程序员所需要的编码和调试时间为178个小时，由此可以外推得到每年35,800语句的生产率。而规模只有一半的程序花费时间大约仅为前者的四分之一，相应推断出的生产率几乎是每年80,000代码行。计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。因此，上述小型项目数据的外推是没有意义的。就好像把100码短跑记录外推，得出人类可以在3分钟之内跑完1英里的结论一样。

严重同意。
小程序和大规模程序的复杂度根本没法比。
一些领导会把构建原型的时间当成软件开发的实际时间，碰上这种人，要么一起欺上瞒下瞎几把搞，要么赶紧跑。

Thomas J. Watson讲述了他年轻时在纽约北部，刚开始做收银机推销员的经历。他带着一马车的收银机，满怀热情地动身了。他工作得非常勤奋，但是连一台收银机也没有卖出去。他很沮丧地向经理汇报了情况，销售经理听了一会儿，说道：”帮我抬一些机器到马车上，收紧缰绳，出发！”他们成功了。在接下来的客户拜访过程中，经理身体力行地演示了如何出售收银机。事实证明，这个方法是可行的。

严重同意。
我自己大量的经验和技能源自于观察和模仿身边的高级/资深工程师，很多东西书里面是学不来的，更不要提什么网课（刷粉卖课的请自动对号入座）。
这也是疫情之后的一大问题，新人入职后很难融入项目，老人也不会主动传授新人技能。