一位CTO的私藏书单：永久改变我工程师生涯的5本书
神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：写了十年代码，才发现真正的成长瓶颈不在技术，而在认知。文章来自编译。
我爱书。当我看着书架上那5000本书时，我眼里看到的不仅仅是纸张和油墨，而更像是一个我从未拥有过的私人导师团。多年来，作为一个狂热的读者，这些书已悄然重塑了我对待编程、领导力乃至思维方式本身的态度。
在我的职业生涯早期，我和其他人一样，以为提升技能就是多写代码或学习最新的框架。然而，我最大的成长，却来自于花在翻阅那些顶级好书上的无数个小时。
阅读、在页边空白处涂写笔记、折起书角，这些具体而审慎的动作，迫使我放慢脚步，进行反思。
在这篇文章里，我想分享五本对我从工程师做到CTO的职业旅程影响最深的书。这些书的贡献远不止于技术知识；它们挑战了我的固有观念，引入了新的心智模型，并最终改变了我的工作方式和领导方式。
我会解释每一本书为何对我如此重要，以及它们如何改变了作为技术专家和领导者的我的做法——从永不过时的个人效能原则，到系统架构方法，不一而足。
这些书共同成为了我的业余速成课，让我成长为一名更优秀的工程师、架构师和决策者。
那么，让我们开始吧。
1. 《程序员修炼之道》（The Pragmatic Programmer）
作者：大卫·托马斯（David Thomas）, 安德鲁·亨特（Andrew Hunt）
我总会向开发者推荐《程序员修炼之道》。虽然这本书不新了，但它所构建的基础在今天依然重要，并且未来也将如此。
这本书在1999年的横空出世对我而言是革命性的，因为里面讲述的是在一个高度缺乏规范的行业里，如何让开发者成为专业人士。我读完书就领悟到了。
以下是一些让我至今铭记的教诲：
软件写到足够好就行。追求完美可能导致项目没完没了。相反，应该追求“足够好”并快速迭代。早交付，多交付。写出能工作的代码，用测试来证明，并确保这些测试能自动执行。
使用示踪弹。用跟踪代码或原型来验证你对问题的理解。这可以帮助在全面实现一个功能之前澄清需求。那时候， MVP（最小可行性产品）的概念还没出现。
多说无用，行动之上！有时候你会遭遇别人写的烂代码。有时候你会发现自己过去写的烂代码。务实的程序员不会说：“不是我写的我不管”，而是会接管这个摊子，并着急大家就原因展开讨论。
不要忍受破窗。在书中，你会了解到“破窗理论”，破窗理论是说，如果窗户破了不修好，就会有更多窗户被破坏掉。作为一名务实的程序员，你应该在写代码时，尽力修复所发现的一切主要问题。
要坚持更新知识。持续学习至关重要。随时了解新的工具、技术和最佳实践。每年至少学习一种编程语言或技术栈。时不时地阅读技术和非技术书籍（是的！）。这项技能投资会在日后的职业发展中得到回报。
不要重复自己。冗余的代码维护起来更复杂。一旦发现复制的情况，就要重构为共享函数或模块。这可以促进一致性并减少错误。
《程序员修炼之道》教会我，优秀的工程不仅仅是编写能运行的代码；更是要构建出能在未来数年里保持正常工作、适应性强且整洁的代码。
以下是涵括整本书的章节与技巧的思维导图：
ℹ️ 《代码大全》另一部堪比《程序员修炼之道》的大块头，跟读起来会更难一些。
这个系列的第三本书是罗伯特·马丁（Robert Martin） 撰写的《代码整洁之道》，一份关于软件开发专业精神的宣言。
2. 《设计数据密集型应用》（Designing Data-Intensive Applications）
作者：马丁·科勒普曼（Martin Kleppman）
即便已在软件行业工作了二十年，我仍然觉得马丁·科勒普曼的《设计数据密集型应用》（DDIA）是一本让人谦卑、开阔思路的读物。这本书常被称为“现代数据系统的百科全书”，这不无道理。
在读 DDIA 之前，像复制、分区和 CAP 定理这些术语，我以为自己都懂了。但读完这本书（两遍）后，感觉就像上了一堂关于数据系统如何运作的大师课。
CAP 定律
可以这么说，这是后端工程领域最具影响力的书籍之一，而且我能明白其中的原因。
以下是我从书中领悟到的一些东西：
一个关键的收获是学会对任何架构决策进行权衡取舍。比方说，书中讨论了特定数据库是怎么偏好一致性而非可用性（反之亦然），以及天下没有免费的午餐；你必须根据需求做出选择。这帮助我理解到，没有一体万用的最佳选择。相反，我会这么问：“我们要解决的是什么问题？哪种权衡取舍用在这里最合适？”
关注基础。我也很欣赏 DDIA 对基础知识的强调：存储引擎、索引和分布式共识，这些即便在新产品不断涌现的今天也依然不变。具体来说，读完后，我重新审视了我们的数据架构，并改进了我们系统中处理数据复制和一致性的方式。比方说，我们有一个微服务在高负载下偶尔会提供过时的数据。应用了 DDIA 的原则后，我们优化了对复制延迟和只读副本的处理方法，使得该服务可以在不牺牲数据新鲜度的情况下进行扩展。
评估数据库。我在评估数据库时也变得更加严谨：不再听信供应商的吹嘘，而是将每个选项与具体用例进行匹配（它需要事务吗？需要水平扩展吗？等等）。然后，再选择合适的数据库类型和供应商。
深入理解分布式事务。科勒普曼对分布式事务和基于日志的流处理等概念的详细解释，为在复杂分布式系统中正确诊断系统行为提供了深刻的见解。
最重要的是，这本书教会了我将可靠性、可扩展性和可维护性作为首要设计目标来思考。它改变了我的思维定式，让我明白系统设计关键是要做出清醒的权衡，而不仅仅是追随潮流。
结果是，我现在应对新的架构决策变得更自信更清楚了。DDIA 真正“弥合了”我自以为知道的知识与底层实际工作原理之间的鸿沟。
值得一提的是，DDIA 不是一本轻松的读物；它的内容多达500页。适合阅读它的人群是：处在职业生涯中期的系统设计工程师，或任何准备系统设计面试的人。
不过，我认为它不适合初级开发者或那些在找快速指南的人。
以下是我从书中摘录的笔记：
3. 《软件设计的哲学》（A Philosophy of Software Design）
作者：约翰·奥斯特豪特（John Ousterhout）
作为一名工程师，我亲眼目睹了代码复杂性是如何变成生产力（以及项目）的无声杀手的。约翰·奥斯特豪特教授的《软件设计的哲学》给了我一套词汇和思维模式，让我能从根源上解决这个问题。
这本书篇幅相对不长，但充满了智慧，教导我们如何将系统分解为更简单、更易于管理的模块，并把可读性和可维护性当作设计目标。奥斯特豪特将复杂性定义为代码当中任何令其难以修改或理解的东西，然后系统地展示了如何减少复杂性。
他认为，代码的编写应该为了便于人类阅读，而不仅仅是为了给编译器性方便而编写。这为我的代码审查提供了一个新的视角。我现在会问：“一年后还会有人看得懂这段代码吗？”——如果答案是否定的，那我们就需要简化。
我学到的最强大的概念之一是“深层模块”（ deep modules）：即接口简单但底层功能丰富的模块（这与《代码整洁之道》的某些观点相反）。如果一个接口隐藏了大量的复杂性，那么这个模块就做得很好。
这让我大开眼界；它颠覆了我对抽象的看法。我不再将复杂性推给调用者（浅层模块，shallow modules），而是尝试将更多的复杂性保留在模块内部，只暴露必要的部分。这种深层模块与浅层模块的概念，从根本上改变了我开发库和服务的方式，鼓励我在前期投入更多精力设计简洁的接口。
这本书还提供了一系列不良设计的危险信号，比如“类过于庞大”或“痴迷原子类型”，我开始在代码审查中将它们用作预警系统。
软件设计的预警系统
我记得读完奥斯特豪特的哲学后，我回去重构了我们的一个核心项目，将一堆纠缠不清的类重构成了几个具有更清晰 API 的模块。结果是，新开发者上手变得更容易了，而且因为代码的意图更加明确，bug 的数量也下降了。
书里面还有一句话也让我记忆犹新：“复杂性是日积月累出来的”，一个个看似细微的小决定会潜移默化。这促使我变得更加警惕；我现在会在设计阶段就处理潜在的复杂性，以防后面变得更加难以收拾。
简而言之，这本书教会我，只是能工作的代码是不够的；如果代码不整洁、不简单，它就是一种负债。这种观点让我成为一个更务实的架构师，更加重视质量而非权宜之计。
4. 《思考，快与慢》（Thinking, Fast and Slow）
作者：丹尼尔·卡尼曼（Daniel Kahneman）
丹尼尔·卡尼曼向世界证明了，我们的思维并不像我们自己认为的那样理性，并因此（在行为经济学领域）获得了诺贝尔奖。
他的著作《思考，快与慢》将数十年的研究成果变成了一本全球畅销书，使其思想不仅为科学家所知，也为大众所接受。
这是对我批判性思维提升最大的一本书。卡尼曼的研究关注的是我们的大脑其实有两种运作模式：
系统1（快思考）。直觉、自动、情绪化，是我们的默认设置。我们用它来进行快速判断和日常决策。
系统2（慢思考）。分析性、费功夫、审慎，是我们有意识地进行批判性思维的系统。我们用它来处理需要集中精力的复杂问题。
事实证明，我们人类，即便是最优秀的工程师，也常常对自己的直觉过度自信，并且在日常不知不觉地欺骗自己。
当我们95%的时间都花在系统1上时，难怪我们会成为它的奴隶。我们如何才能围绕这两种思维模式更好地设计体验呢？
读这本书给我的启发很大。我意识到，在我职业生涯中，有多少 bug、设计缺陷，甚至是管理上的失误，归根结底都是由认知偏见和草率判断造成的。
以前，如果我在调试问题或做系统设计决策时，我常常相信自己对解决方案的直觉。之后，我开始强迫自己慢下来。我会问：我正在做什么样的假设？我下结论是不是过于草率了？
比方说，如果发生服务中断，我不再立即归咎于最新的部署（一种系统1的反应），而是有条不紊地收集数据并考虑多种假设，这是一种更偏向系统2的方法。
卡尼曼还向我介绍了像锚定效应和确认偏误这样的概念，这让我更愿意质疑自己的第一印象。
一个让我印象深刻的强大概念是 WYSIATI（所见即是全部，What You See Is All There Is）。它描述了我们如何迅速地直接跳到结论，却常常忽略了关键事实。“不从记忆中（哪怕是无意识地）提取出来的信息，就跟不存在一样，”卡尼曼指出。我们的大脑会寻找好的故事，但对于构成这些叙事所需的客观信息的质量和数量，却表现出顽固的抗拒。
来自《思考，快与慢》一书的WYSIATI原则
这种现象解释了作为领导者我曾经历的许多挫败感：为什么人们会做出错误（但迅速）的判断，忽略相反的证据，或者固执地坚守不完整的故事。
读完卡尼曼的书后，我强烈地意识到偏见是如何影响技术决策和团队动态的。也许最重要的是，它改变了我与团队互动的方式。我听得更仔细了，承认自己可能犯错也更快了，这一点与卡尼曼的核心教诲正好相呼应：我们都会犯错，这没关系。在会议上，我会说：“这是我的直觉，但让我们用数据来验证一下。”
这本书教会了我，要想成为一名更优秀的工程师或CTO，不仅仅在于你知道什么；还在于认识到你思维中的盲点并加以弥补。它是一套帮助我做出更佳决策的思维工具。
这本书绝对是每个人的必读之作！
5. 《高效能人士的七个习惯》（The 7 Habits of Highly Effective People）
作者：斯蒂芬·柯维（Stephen Covey）
柯维的书教会我，有效的工程领导力始于个人领导力。它提供了一个包含七个习惯的框架，从积极主动、“以终为始”，到寻求双赢思维和不断更新（持续改进），不一而足。
对大多数人来说，这些习惯可能听起来像是常识，但读这本书对我来说是一记警钟。柯维挑战我为自己的成长负责，并牢记原则高于紧急事务。
我认为这本书算是让我的生活和事业提升10倍的功臣之一。
“影响圈”与“关注圈”的概念深深触动了我（源自己斯多葛主义）。我学会了将精力集中在我能影响的事情上（比如掌握一门新技术或帮助一位队友），而不是去担忧我无法控制的外部因素，比方说别人的看法。
三个影响圈（灵感来自史蒂芬·柯维）
另一个教训是“先去理解他人，再去寻求被理解”，这彻底改变了我与团队沟通的方式（以及如何积极倾听）。正如柯维那句名言所说：“大多数人听的目的不是为了理解，而是为了回应。” 当我读到这句话时，我不得不停下来；它太真实了。
有多少次，我身在代码审查或计划会议中，却已然在构思自己的回应，而不是真正地倾听？柯维传达的信息是：慢下来，先倾听。
现在，当有团队成员带着问题来找我时，我会有意识地努力去完全理解他们的观点，然后再发表意见。这极大地增进了我们对话的信任与明确程度。
另一个让我产生共鸣的习惯是“宝剑锋从磨砺出”，这是柯维的说法：要不断投资自己。它提醒我，花时间阅读、学习新技能，甚至只是充充电，都不算停工；而属于对效能的投资。我开始每周留出一点时间用于自我提升（有时候是读一本新书，或探索我好奇的一项技术）。
这很讽刺，但通过暂时脱离日常的忙碌来“磨磨刀”，我重返工作时反而变得更敏锐、更高效。
读完柯维的书后，我开始在周计划中牢记我的长期目标，确保即便作为一个埋头写代码的工程师，我也永远不会忽视更宏大的目标。这意味着要制定合适的长期和短期目标。
高效能人士的七个习惯
这本书永不过时的原则成为了我行事方式的基石：它给我灌输了严于律己、积极主动、有同理心以及持续改进的习惯，为我应对CTO生涯的挑战做好了准备。
这本书就像一面镜子；它迫使你反思自己的习惯和心态。对我而言，这种反思带来了我领导工程团队方式的切实改变。
6. 结语
在写这篇文章时，我注意到：这些书中没有一本是教我新的编程语言或如何使用某个特定框架的。然而，每一本都对我作为工程师和领导者的成长起到了变革性的作用。
从如何管理自己，到如何设计软件，再到如何做出决策，它们扩展了我的视野。这些书共同构成了一种在职教育课程，这是任何正式学位或工作培训都无法提供的。它们提醒我，我们的书架可以兼作导师架，每一位导师都在我们准备好吸收教诲时，向我们传授知识。
如果说我希望你能从中领悟到一件事，那就是：投资自己的成长并不总是意味着写更多代码或参加更多会议。有时候，这意味着要阅读和反思。我经常鼓励年轻的工程师建立自己的“导师书架”，去寻找那些能挑战他们思维方式的书籍。
我在这里分享的五本只是一个起点，你的书单可能会有所不同。重要的是保持好奇心，永远不要认为自己已经停止成长。
作为一名CTO，我仍然是那个下班后手捧一本书的工程师，对下一个能让我变得更好的见解充满期待。
那么，在你的旅程中，你会选择哪些书呢？
答案可能会以你今天无法想象的方式塑造你的职业生涯。
祝你阅读愉快，成长快乐！
译者：boxi。
