大一刚接触编程时，我以为软件工程就是写代码。代码写得快，项目就做得快；代码写得好，项目就成功。直到读完《人月神话》，我才意识到这种想法并不正确。
布鲁克斯在半个世纪前写下的那些论断，今天读来依然振聋发聩。
最让我印象深刻的是“人月神话”本身。以前我会这么想：一个项目十个月做完，那十个人做一个月总该行吧？书里的回答很干脆：不行。因为人与人之间的沟通成本是线性增长的，甚至是指数增长的。十个人不是十个独立单位，他们需要开会、对齐、理解彼此的代码。把人数翻倍，沟通链路远不止翻倍。这个道理听起来简单，但我回想自己写小组作业的经历——哪怕只是两三个人合作，也经常出现“等对方接口”“理解错需求”“改了一处崩了另一处”的情况。人数少尚且如此，百人千人的项目该是怎样一番景象？不敢想象。
并且，更让我意外的是布鲁克斯对“银弹”的否定。作为一个学技术的学生，我天然相信进步：今天解决不了的问题，明天的新工具一定能解决。但他说，软件工程的本质困难不是那些“次要问题”——比如语言不够高级、工具不够顺手——而是“概念结构”本身。你要建的东西是什么，它怎么组织，各个部分怎么协同，这些只能靠人脑想清楚。没有捷径。哪怕我们现在有了AI辅助编程，有了更敏捷的开发流程，软件仍然常常延期，仍然充满缺陷。这让我有点沮丧，但也让我开始正视这门学科的真正难度。
此外，书中还有一个概念让我反复琢磨：概念完整性。布鲁克斯说，一个系统必须由少数人——甚至一个人——负责设计内核，否则就会变成各种风格的拼凑物，用起来割裂，维护起来更是灾难。这和我平时的想法不太一样。我总觉得“大家一起讨论”等于民主，等于更好。但他提醒我，软件不是投票出来的，它是艺术品，需要统一的灵魂。这并不意味着不让别人提意见，而是说，最终的设计决策必须收束到一个人或一个极小的团队手里。这个观点让我开始重新理解“独断”与“协作”之间的关系。
读这本书的过程中，我时常产生一种错位感。书里描述的那些问题——进度失控、需求变更、文档缺失——放在今天任何一个技术论坛依然是热门话题。六十年过去了，硬件性能提升了亿万倍，开发工具从汇编变成了云原生，可人的问题还是那些问题。我们以为自己在攻克新技术，实际上可能只是在重蹈覆辙。
当然，作为学生，书里有些内容离我还很远。我没有管理过百人团队，没有经历过系统彻底推翻重来的绝望，读那些章节时更多是旁观者的心态。但我也意识到，技术之外的东西，我需要提前开始留意。比如怎么和同伴沟通接口定义，怎么在写代码前先想清楚结构，怎么在妥协与坚持之间做选择。这些不是“以后的事”，它们已经发生了。
最后合上书的时候，我想的不是“学到了一套方法”，而是“看到了一个行业”。软件工程不是码农的堆砌术，而是一群人和复杂性的漫长搏斗。书名叫《人月神话》，但我觉得它不是在嘲笑神话本身。它只是告诉我们：没有银弹，没有捷径，你要一点一点，老老实实地面对那些困难。
而愿意面对正是第一步。