书名：程序员的README
ISBN：978-7-115-59943-8
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 [美] 克里斯·里科米尼（Chris Riccomini）
[美] 德米特里·里亚博伊（Dmitriy Ryaboy）
译 付 裕
责任编辑 郭 媛
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Copyright © 2021 by Chris Riccomini and Dmitriy Ryaboy. Title of English-language original: The Missing README: A Guide for the New Software Engineer , ISBN 9781718501836, published by No Starch Press Inc. 245 8th Street, San Francisco, California United States 94103. The Simplified Chinese-edition Copyright © 2023 by Posts and Telecom Press Co., Ltd under license by No Starch Press Inc. All rights reserved.
本书中文简体字版由美国No Starch出版社授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式复制或传播。
版权所有，侵权必究。
对于刚刚成为软件工程师的新手来说，知道如何编写代码只是成功了一半。你可能很快就会发现，学校并没有教授在现实世界中至关重要的技能和工作中必要的流程。本书恰恰填补了这一环节，它是作者十多年来在大型公司指导初级工程师工作的教程，涵盖软件工程的基础知识和最佳实践。
本书第1～2章讲解当你在公司开启你的职业生涯时会发生什么；第3～11章会扩展你的工作技能，教你如何使用现有代码库、解决和防止技术债、编写生产级软件、管理依赖关系、有效地测试、评审代码、交付软件、处理On-Call时的事故和构建可演进的架构等；剩余章节涵盖管理能力和职业阶梯的提升等相关内容，例如敏捷计划、与管理者合作以及成长为资深工程师的必经之路。本书中非常重要的一部分内容是教你如何应对糟糕的管理，以及如何调整自己的节奏。
本书内容不仅浅显易懂，还覆盖整个软件开发周期，是一本技术主管希望每名新入行的工程师在开始工作之前都能阅读的书。
就职于一家软件公司，对于刚毕业的学生或已经拥有几年工作经验的软件工程师来说，都可能是令人望而生畏的。
对于刚毕业的学生来说，他们可能只经历过一些规模较小的项目，所以大概会对技术概念和大规模的企业代码感到不知所措。这本书是一本极好的入门级教程，有助于他们从软件工程专业的学生转变为独当一面的工程师，通过公司特定的流程，使用特定的工具来编写高质量、生产级、可测试的代码。
对于拥有几年工作经验的软件工程师来说，他们可能会在新的工作方式、工具和流程上遇到挑战，更不用说与新人协作时的社交难题了。随着软件开发行业的与时俱进，工程师之间也可能存在技术上的差距。这本书是一本非常好的用于自我精进的教程，尤其除第1章和第14章外，每章末尾都有“升级加油站”，读者可以按图索骥，找到更匹配自己的内容。
人类是具有习惯的生物。虽然软件工程师可能会被一些人视为特殊人群，但他们也可能会陷入习惯中。作为一名软件工程师，不断地学习和发展至关重要，不管当前的经验或职位怎样，这本书对每一名志在从事软件开发工作的人员都很有用。一名成熟的软件开发者的标志是打破固有的习惯，批判性地回顾旧代码，发现瑕疵，做到自省，且为没多做些什么而感到羞愧。
在本书的前几章中，“提问”就被高度重视，这让我感到非常高兴。向同事提问和学习是快速成长和习得新技能的有效方式。为你的工作成果感到自豪通常是件好事，但当自己在持续改进和交付中比以前做得更好时，你应该优先感到自豪。
这本书针对如何改进、如何学习、如何推进职业生涯发展，以及如何成为一名更好的开发者提供不同的方法和步骤。这本书包含适应团队的工作流程、处理会议、如期交付、善用学习工具和技术领域的最佳实践，并指导人们如何成为团队中有价值的成员。
向资深工程师寻求帮助可能会让人感到一丝畏惧，因为打断他们的工作通常是不妥的。资深工程师往往在聚精会神工作时会因为被打扰而失去在脑海中已构建的系统的短期记忆，但大多数资深工程师都很愿意提供帮助，优秀的资深工程师更是以指导和协助他人为荣。如果你在寻求帮助时感受到了敌意，大可不必心烦意乱，因为这在每个人身上都可能发生。不要让某一次糟糕的遭遇阻断了你再次寻求帮助的欲望。但总是打断他人的工作并非是合适的，这时就可以使用这本书中涵盖的其他策略和原则，它们都可以指导你将职业生涯提升到新的阶段。
无论你处于职业生涯的哪个阶段，这本书都非常实用。请保持开放的心态，好学深思，渴望提高，不惧破旧习，不惧提问题。
雅克·奥洛夫松（Jerker Olofsson）
索尼移动公司前核心架构师
本书的两位作者在最后一章中说：“你可以为任何行业做出贡献，从科学到农业、健康、娱乐，甚至是太空探索。”我一直都认为软件工程师的工作带来的成就感并不亚于小说家、建筑师或音乐家。软件开发本身带来的欣喜是一种“尤里卡时刻”的幸福体验，尤其是在无数个面对调试器“狂按”F10键的夜晚，自己提交的特性成功上线时的喜悦，抑或是眼看着自己设计的技术架构方案从纸面上的框图到代码实现再到最终交付的满足感。
当然在软件行业工作也有艰辛，变动的需求、阻滞的沟通、糟糕的管理和紧迫的工期，总有些时刻会令人产生倦怠。毕竟真实世界中并不存在只和机器进行沟通的工作，更多的还是人与人之间的交流。本书能够很好地帮助刚刚踏入这个行业的工程师去认识真实世界。似乎从来都是程序员为他人撰写README，从来没有人为程序员撰写过README。
由于工作的关系，我个人不仅参与过采用瀑布流模型的传统项目，也参与过极度灵活多变的研发项目，以及采用改良后的Scrum框架的敏捷项目。虽然各自采用的开发模型不尽相同，但是遇到的问题都很相似。在实际的工作中，成功地交付软件并不是只有唯一的路径可走。如何衡量与之匹配的需求、成本和风险才是考验团队的地方。本书中，两位作者提到了软件开发过程中的诸多困境，在我曾经的工作中也遇到过类似的情况。至今我还记得曾经有一次由于共享的数据层竞合而引发的生产环境故障，整个团队高负荷地工作了一周才最终解决。而在应对这起故障的过程中，团队明明在非常积极地处理，却引起了客户的极大不满。让客户不满的并不是故障本身，而是出了故障之后得不到应急方案导致了长时间的服务器宕机。如果那个时候能采用本书中提到的事故处理的标准流程（分流、协同、应急方案、解决方案和后续行动），那么很多弯路就可以避免了。
翻译完本书的最后一章时，正好是我踏入软件行业的12年整，此时的我却觉得自己的职业生涯好像才刚刚开始。
在翻译本书期间，首先要感谢我的朋友托老师，在我犹豫要不要接受翻译这本书带来的挑战时，是托老师“一脚把我踹进了翻译的大门”，并帮我辨析了许多汉语和英语在表意细节上的差异。接下来要感谢Stacy分享了许多关于专业的商业文案写作的经验，快速地纠正了我在书面语言表达中的不良习惯。然后要感谢就职于硅谷“大厂”的移动端工程师Lide，他提供了一种兼容东西方软件工程文化的视角，每当我遇到技术领域的专有名词没有办法贴切地翻译时，他总是能提出非常精妙的思路。最后要感谢有多年海外生活经验的Allen和ARK，译文中有多处涉及美式俚语，是他们耐心地向我解答这些俚语的日常使用场景。另外Lide、Allen、ARK都是我从小逮蜻蜓、丢口袋、“摇街机”时就认识的好朋友。没想到在这个年纪，我们会因为我翻译了一本书而隔空聚在一起。仔细想想这是我的幸运。
最后要着重感谢几位同样优秀的工程师Jeff、Hobbes、Silver和Jerker，他们现在依然奋斗在各自的业务一线，他们的工作场景几乎涵盖了本书的各个章节，同时也意味着涵盖了软件工程的全部流程。他们用各自业务领域的鲜活案例和经验为我解答了诸多疑惑。尤其是Jeff让我看到了科学和人文融合的领域会散发出多么强烈的人格魅力。
此时的你刚接任新的工作，已经做好了万全的准备，正蓄势待发地迎接一切难题，希望通过优雅的代码施展才华。多么激动人心！祝贺你！我们希望你能轻松地应对有趣的挑战，与优秀、机敏且激情满满的同事一起工作，并构建出有用的东西。
但你很快就会发现，或者说你已经发现了，知道如何编写代码——也就是如何使用计算机去解决问题，仅仅是“战斗的一半”。它是你技能包中一个关键的部分，然而要成为一名高效的软件工程师，你还需要那些学校里没有教授过的技能。而本书将会教你这些技能。
我们将解释构建、测试和运行生产软件的现代实践，并阐释那些可以使团队更强大和使队友更默契的行为和方法。我们会给你一些实用的建议，诸如如何获得帮助、如何撰写设计文档、如何维护旧代码、如何On-Call（待命）、如何规划你的工作以及如何与你的管理者和团队互动。
本书并不包含你需要知道的所有内容，因为这是一项不可能完成的任务，还会让你读起来很疲劳。相反，我们把重点放在那些计算机科学课程并没有涉及的主题上。这些主题通常都需要深入了解。如果你想了解更多信息，我们在许多章的结尾放置的“升级加油站”包含推荐的内容，以供阅读。
本书第1～2章介绍你初入一家公司开启职业生涯时应该知道的内容。第3～11章拓展你的职业技能：编写生产级别的代码、高效地测试、代码评审、持续集成和部署、撰写设计文档和进行技术架构上的最佳实践。第12～14章涉及软技能，诸如敏捷计划、与你的管理者协作以及职业生涯规划。
这是一本有态度的书。本书中构建团队的经验取自那些快速成长的、由风险投资公司资助的或者准上市的硅谷公司。你所在的环境可能会有所不同，但是没关系。公司与公司之间总会有些差异，但基本原理总是相通的。
本书是我们希望你在职业生涯刚起步时就拥有的书，同时也是一本送给那些新加入团队的工程师们的书。读到最后，你就会知道成为一名专业的软件工程师都需要什么。让我们开始吧！
由衷地感谢我们的编辑Athabasca Witschi。没有她，本书就不会是现在的样子。感谢Kim Wimpsett在文字编辑上提供的帮助，感谢Jamie Lauer的校对，感谢Bill Pollock、Barbara Yien、Katrina Taylor以及来自No Starch的其他成员在本书的写作过程中对两名新手提供的指导。
感谢我们的评审人员：Joy Gao、Alejandro Crosa、Jason Carter、Zhengliang (Zane) Zhu以及Rachel Gita Schiff。你们的反馈非常珍贵。感谢Todd Palino对运维相关章节的反馈，感谢Matthew Clower对第6章进行了详尽的校对并提出了坦诚的意见，感谢Martin Kleppmann和Pete Skomoroch将我们引荐给出版社并提供指导，感谢Tom Hanley、Johnny Kinder和Keith Wood对管理相关章节提出的反馈。
如果没有我们的雇主和管理者的支持，我们不可能完成本书。感谢Chris Conrad、Bill Clerico、Aaron Kimball和Duane Valz让我们得以在这个项目上一展身手。
本书由异步社区出品，社区（https://www.epubit.com）为您提供后续服务。
本书提供如下资源：
● 本书思维导图。
要获得以上配套资源，您可以扫描下方二维码，根据指引领取。
您也可以在异步社区本书页面中点击
，跳转到下载界面，按提示进行操作即可。注意：为保证购书读者的权益，该操作会给出相关提示，要求输入提取码进行验证。
如果您是教师，希望获得教学配套资源，请在社区本书页面中直接联系本书的责任编辑。
作者、译者和编辑已尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“发表勘误”，输入错误信息，单击“提交勘误”按钮即可（见右图）。本书的作者、译者和编辑会对您提交的错误信息进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/ submission即可）。
如果您所在的学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近40年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的Logo。异步图书的出版领域包括软件开发、大数据、人工智能、测试、前端、网络技术等。
异步社区
微信服务号
你作为一名软件工程师的旅程将跨越你的整个职业生涯，沿途将有许多站点——学生、工程师、技术负责人，甚至可能是管理者。大多数新入行的工程师在开始时都有技术基础，但没有什么实质上的经验。本书前面的章节将会引导你走向职业生涯的第一个里程碑。当你能够安全地交付代码并与你的团队无缝协作时，你就会到达这个里程碑。
到达第一个里程碑是很困难的。因为你需要的信息会散落在互联网上，或者更糟糕的是，隐藏在某人的脑袋里。本书整合了成功所需的关键信息。但是一名成功的软件工程师究竟是什么样子的呢？以及如何成为一名成功的软件工程师呢？
每个人都是从入门级工程师开始做起的。如果想晋级，你就需要具备下面几个核心领域中所需要的能力。
● 技术知识：你知道计算机科学的基础知识。你知道如何使用集成开发环境（IDE）、构建系统、调试代码和测试框架。你熟悉持续集成、系统指标和监控、配置和打包系统。你积极主动地创建和改进测试代码。在做架构决策时，你会考虑到长期运维。
● 执行力：你通过用代码解决问题来创造价值，并且你了解你的工作和业务之间的联系。你已经可以构建并部署中小型的特性。你会编写、测试和评审代码。你分担On-Call的职责，调试运维问题。你是积极主动并且可靠的。你参加技术讲座、阅读小组、面谈和路演。
● 沟通能力：你能同时以书面和口头的形式进行清晰的沟通。你能够有效地给予和接受反馈。在模棱两可的情况下，你会主动寻求帮助并得到明确的结果。你能以建设性的方式提出问题和定义课题。你在可能的情况下可以提供帮助，并开始影响同事。你会文档化你的工作。你撰写清晰的设计文档并征求反馈意见。在与他人打交道时，你富有耐心和同理心。
● 领导力：你能在指定的工作范围内独立地完成工作。你能迅速地从错误中学习。你能很好地处理变动和模糊的问题。你积极参与到项目和季度的规划中。你能帮助新的成员融入团队。你可以向你的管理者提供有意义的反馈。
要想到达你的终点，你需要一张地图。本章的其余部分将帮助你导览全书和你的职业生涯初期。我们将从“新手营”开始，因为那里是所有新手出发的地方。之后沿着“试炼之河”漂流，来到编写代码并学习规范和流程的地方。接下来去“贡献者之角”，在这里发布一些有意义的特性。发布特性意味着你将不得不在“运维之海”的风暴中扬帆航行。最后，我们会在“胜任之湾”这个安全港着陆。
我们对很多段落都提供了注释。你可以从头至尾地通读本书，也可以直接跳到你最关心的章节。我们有意让许多注释在下文中多次出现。各章是按照主题来进行分类的，但我们所涉及的主题将会贯穿你的整个职业生涯，常读常新。
你以一名新手的身份开启了你的旅程。你需要熟悉公司、团队，以及如何完成本职工作；参加入职会议；设置你的开发环境和系统权限，并弄清楚团队的常规流程和会议；阅读文档并与队友进行讨论。如果你在入职过程中发现了漏洞，你可以在文档中做出一些补充。
为了帮助你顺利地开展工作，你的公司可能会有一个新人入职培训。这些培训课程会让你了解公司是如何运转的，带领你参观整个组织，并介绍一些公司领导。新人入职培训还会向你介绍其他部门的员工，那些是你未来的同事。如果你的公司没有安排新人入职培训，那需要你自己去向你的管理者要一份公司的“组织架构图”，了解清楚谁负责什么，谁向谁汇报，都有哪些不同的部门，以及它们之间的关系。记得做好笔记。
坎宁安定律[1]和自行车棚效应[2]
我们建议你在团队中用文档记录下会议的内容、入职流程和其他口口相传的东西。你会得到很多的评论和纠正。不要把这些评论和纠正当作针对你个人的批评。重点并不是要写一份完美的文档，而是要写得足够多，以引发讨论，充实细节。这是坎宁安定律的一个应用，该定律认为：“在互联网上获得正确答案的最好方法并不是提出问题，而是发布错误的答案。”
过度集中在细枝末节上的讨论总是会很冗长，这种现象被称为“自行车棚”（bike-shedding）效应。自行车棚效应是西里尔·诺思科特·帕金森的一则寓言故事，该寓言描述了一个被指派到发电厂对该发电厂的设计方案进行评审的委员会的故事。对该委员会来说，因为发电厂的设计方案过于复杂，以至于无法讨论出什么实际的内容，所以他们花了几分钟就批准了这些计划。然后，他们又花了45分钟来讨论发电厂旁边的自行车棚的材料问题。“自行车棚效应”在技术类的工作中经常出现。
[1] 沃德·坎宁安（Ward Cunningham）是网络百科概念的发明者。——译者注。如无特殊说明，本书注释均为译者注。
[2] 西里尔·诺思科特·帕金森（Cyril Northcote Parkinson）在1957年提出了一个名为“帕金森琐碎定理”（Parkinson’s law of triviality）的理论，也叫琐事理论。它指出人们考虑一件事情的时间和事情的重要性成反比。帕金森说：“我们总对小事纠缠不休是因为我们懂这些小事，而我们回避复杂的问题是因为我们对这些问题摸不着头脑，同时又害怕出丑而不敢发问。”
有些公司会有额外的新手教程来帮助你获得系统权限、构建开发环境、检出和编译代码。如果没有这样的教程，正好借此机会去创建一份。写下所有你在构建环境时所做的事情。（参见第2章“步入自觉阶段”。）
你应该被分配到一个小任务去学习如何修改代码并将其安全地发布到生产环境。如果没有的话，就主动寻找或要求去做一些有用的小幅改动。这些改动一定要小，甚至可以小到只更新一行注释。这样做的目的是让你去了解那些步骤，而不是去打动谁。（参见第2章“步入自觉阶段”和第8章“软件交付”。）
设置你的代码编辑器或IDE。IDE要和你团队的保持一致。如果你还不了解团队所使用的IDE，就去网上找一个教程。学习IDE将为你以后节省出大量的时间。配置你的IDE去适配团队的代码规范，搞清楚代码规范里都有什么以及怎样才能符合这些规范。（参见第3章“玩转代码”。）
确保你的管理者邀请你参加团队和公司的会议，诸如站会、迭代计划会、项目总结会、全员会议等。如果你的管理者有一对一面谈的习惯的话，提醒他们给你安排一个。（参见第12章“敏捷计划”和第13章“与管理者合作”。）
一旦你完成了新手任务，你将开始为团队分担真正的工作。你可能会在一个现有的代码库上工作。你发现的东西可能会使你感到困惑或害怕。多提问，并经常让团队评审你的工作成果。（参见第3章“玩转代码”和第7章“代码评审”。）
在你的成长过程中，持续学习是至关重要的。了解如何编译、测试和部署代码。阅读那些提交代码的请求和代码评审意见。不要害怕询问更多的信息。多报名参加技术讲座、午餐会、阅读小组、导师计划，诸如此类。（参见第2章“步入自觉阶段”；第5章“依赖管理”；第6章“测试”和第8章“软件交付”。）
现在是时候与你的管理者建立一些联系了。了解他们的工作风格，理解他们的期望，并与他们谈谈你的目标。如果你的管理者有一对一面谈的习惯，那么你要期待有几场这样的谈话。管理者通常都希望跟踪事情的进展，所以问问他们后续如何沟通。（参见第13章“与管理者合作”。）
你第一次被邀请参加的计划会议，通常是迭代计划会议。你也可能参加项目总结会或全员会议。要了解一下路线图和开发计划的全貌。（参见第12章“敏捷计划”。）
一旦你着手开发大一些的任务和特性就意味着你进入了“贡献者之角”。团队会信任你能更独立地完成工作。学习如何编写生产级别的代码，使这些代码对运维者友好。恰当地管理组件间的依赖关系，并进行完备的测试。（参见第3章“玩转代码”；第4章“编写可维护的代码”；第5章“依赖管理”和第6章“测试”。）
现在你也应该去帮助队友。参与到代码评审中去，做好队友会询问你的想法和反馈的准备。因为你的团队可能会忘记你是最近才加入的，所以你一旦感到困惑，就请提出问题。（参见第2章“步入自觉阶段”；第7章“代码评审”和第10章“技术设计流程”。）
大多数公司都会有季度规划和目标设定的周期。参与到团队的计划中去，并与你的管理者一同制定目标或OKR（目标和关键成果）。（参见第12章“敏捷计划”和第13章“与管理者合作”。）
当你参与到更大的任务中时，你将会学到如何向客户交付代码。在交付过程中会发生很多事情：测试、构建、发布、部署和展开。完善这个过程需要一些技巧。（参见第8章“软件交付”。）
在你的修改生效之后，你将不得不去运维这个软件。运维工作中你会面临很大的压力并且需要勇气。客户会因为软件的不稳定而受到影响。你需要使用监控指标、日志和跟踪工具来实时调试软件。这时你也可能需要参与轮流的On-Call。接触运维工作会让你清楚地了解那些代码如何在客户的手中发挥作用。同时你也要学会保护你的软件。（参见第4章“编写可维护的代码”和第9章“On-Call”。）
你的团队现在将依靠你来负责一个小项目。你需要撰写一份技术设计文档并帮助团队进行项目规划。设计软件将迫使你面临全新级别的复杂度。不要满足于你的第一版设计。反复斟酌，要随时做好准备，因为你的系统会随着时间的推移而不断变化。（参见第10章“技术设计流程”；第11章“构建可演进的架构”以及第12章“敏捷计划”。）
你工作中的早期光芒已经消散。你在系统架构、编译环节、部署环节以及测试环境中都看到了不足之处。你要开始学习在必要的维护和重构中间寻找平衡。不要试图重构一切。（参见第3章“玩转代码”。）
你可能也对团队的工作流有见解。写下你的观察，哪些是有效的，哪些是无效的，然后与你的管理者一对一地谈谈你的想法。（参见第13章“与管理者合作”。）
现在是设定长期目标和评估绩效的时候了。同管理者一起理解这个过程，并从同事那里获得反馈。同管理者谈谈职业上的志向、未来的工作、项目和想法。（参见第13章“与管理者合作”和第14章“职业生涯规划”。）
你现在已经有了初学者旅程的地图和目的地。在“胜任之湾”着陆后，你将成为一名成熟的软件工程师，此时的你能够与你的团队合作，贡献价值。本书中的其他部分将引导你的职业生涯。接下来，我们的旅程即将开始。
马丁·M. 布罗德威尔在其文章《为学而教》（“Teaching for Learning”）中定义了能力的4个阶段：“无意识的无能力”（unconscious incompetence）、“有意识的无能力”（conscious incompetence），“有意识的有能力”（conscious competence）和“无意识的有能力”（unconscious competence）。具体说来，无意识的无能力意味着你无法胜任某项任务，并且没有意识到这种差距。有意识的无能力意味着你虽然无法胜任某项任务，但其实已经意识到了其中的差距。有意识的有能力意味着你有能力通过努力完成某项任务。最后，无意识的有能力意味着你可以很轻松地胜任某项任务。
所有的工程师都是从前两个阶段开始的。即使你对软件工程了如指掌（这不太可能），你也必须学习公司的那些具体操作流程和规范。你还必须学习实用的技能，正如本书中所涉及的那些。你的目标是尽快到达第三个阶段。
本章的大部分内容将阐释如何自主学习和如何获得帮助。校外学习是一种技能。我们会为如何养成独立自主的学习习惯提供一系列建议。我们还将准备一些提示，方便你在“万事都求人”和“独行侠”之间取得平衡。本章的最后将讨论冒充者综合征和邓宁-克鲁格效应，这可能会导致新工程师感到自信不足或自信爆棚，而这两种情况都会限制他们的成长。我们将解释如何自省并遏制这两种极端情况。在避免落入自我怀疑和过度自信的陷阱的同时，练习独立学习并提出有效的问题将会使你迅速地到达第三个阶段。
学习将帮助你成为一名合格的工程师，并在未来的日子里持续进步。软件工程领域在不断地发展。无论你是一名刚毕业的学生还是一名经验丰富的老手，如果你不学习，你就会落后。
本节将列举各种各样的学习方法。切勿试图同时去做本章中列出的所有事情！因为那样会让你感到倦怠。切记善用个人的时间——虽然说持续进步非常重要，但是把所有清醒的时间都花在工作上是不健康的。应该根据你的现实情况和自然倾向，从下面的方法中选择。
在工作的前几个月里，你要学习一切如何运作。这将有助于你参与设计讨论、On-Call轮换、解决运维问题和评审代码。前期的学习会让你感到不舒服，因为你总会希望尽快将软件上线，而花时间阅读文档和摆弄工具却会让你慢下来。别担心，大家都预料到你会需要些时间来成长。前置学习是一项有价值的投资，许多公司会专门为新员工设计学习课程。Facebook公司就有一个著名的为期6周的被称作“boot camp”的新手工程师训练营。
前置学习并不意味着要整天坐在那里阅读文档。在实践中学到的东西要比只坐在那里单纯地阅读学到的多出许多。你应该上手编写并且发布代码。第一次发布代码很可怕。要是你弄坏了什么东西怎么办？但是管理者们通常不会把你放在一个可以造成严重破坏的环境中（尽管有时新员工需要在别无选择的情况下从事高风险的任务）。尽你所能去理解你的工作会造成的影响，并以适当的谨慎程度行事。与变更高流量数据库上的索引相比，编写单元测试可以不那么谨慎，从而更快。
克里斯删除所有代码的那一天
在克里斯的第一次实习中，他与一名高级工程师搭档做项目。克里斯完成了一些修改，并需要部署它们。这名高级工程师向他演示了一下如何将代码并入他们所使用的版本控制系统（VCS）。克里斯按照说明盲目地执行了涉及分支（branch）、标记（tag）和合并（merge）的相关步骤。紧接着他继续完成了当天的其他工作，然后就回家了。第二天早上，克里斯兴高采烈地逛了一圈，和大家打招呼。大家尽了最大的努力做出善意的回应，可情绪却很低落。当克里斯问起发生了什么事时，他们告诉克里斯，他破坏了整个VCS代码库。公司的所有代码都丢了。大家整晚都没睡，拼命地恢复那些能恢复的东西，最终找回了大部分的代码（除了克里斯提交的和其他几个）。克里斯被整件事吓坏了。他的管理者把他拉到一边，告诉他不要担心：克里斯和高级工程师做了正确的事情。错误难免会发生。每名工程师都有类似的故事。尽你所能，努力理解你在做什么，但要知道这种事情总会发生。
错误是不可避免的。成为一名软件工程师的路途艰辛，我们有时会失败。这几乎是所有人都知道的事情。降低系统风险并使这些错误不那么致命是你的管理者和团队的工作。如果你失败了，也不要被击垮：写下经验教训，然后继续前行。
运行实例代码可以真正地了解代码的工作原理。文档可能会过期，同事们也会忘记某些事情，但是实例代码是安全的，因为你可以在生产环境之外运行它们，而且非生产环境的实例会允许使用一些具有侵入性的技术。例如，你知道某个方法被调用了，但无法确定它是如何触达的。你可以通过抛出一个异常，输出一串堆栈跟踪信息，或者附加一个调试器来查看调用层级。
调试器是你运行实例代码时最好的朋友。你可以用它来暂停正在运行的代码，然后查看运行中的线程、堆栈信息和变量的实际值。添加一个调试器，触发某个事件，并单步执行代码，就可以查看该事件是如何被处理的。
虽然调试器很强大，但有时了解一个软件行为的最简单的方法是在关键位置输出几行日志或在控制台输出。你可能对这种方法很熟悉，只是要注意，在复杂的情况下，特别是在多线程的应用程序中，输出调试信息可能会产生误导。因为操作系统会使用缓冲的方式将内容写到标准输出接口，这样会让你在控制台中看到的信息有延迟。而且多个线程都在向这个接口写入信息，这样输出的信息就会交织在一起。
一个看起来有些笨拙但非常实用的方法是在程序执行的入口处输出一行特殊的语句。这样你就可以很容易地知道现在运行的程序究竟是你修改过的，还是原来的旧版本。你会节省出那些跟踪程序“谜之行为”的时间。“谜之行为”通常都是由正在被调用的程序是旧版且你修改的内容没有生效造成的。
请每周都花一部分时间去阅读。可供阅读的内容有很多：团队文档、设计文档、代码、积压的任务票、书籍、论文和技术网站。不要试图一下子把所有东西都读完。请从团队文档和设计文档入手。这些文档会就事情是如何组合在一起的给你一个整体的概念。要特别注意那些关于如何权衡取舍和背景的讨论。接下来你就可以深入研究那几个与你最初任务相关的子系统了。
正如罗恩·杰弗里斯所说“代码从不说谎。注释有时却会”（Code never lies. Comments sometimes do，更多细节可以参见作者的个人博客），去读源代码，因为它并不总是与设计文档相吻合！不要只读你自己的代码库，还要去阅读高质量的开源项目，特别是那些你使用的类库。不要像阅读小说一样从前到后地通读代码：请利用你的IDE来浏览代码。为关键的操作绘制控制流和状态图。仔细研究代码的数据结构和算法。注意那些临界值的处理。留意那些惯用写法和风格，也就是去学习“本地方言”（local dialect）。
在“任务票”（ticket）或“问题点”（issue）中跟踪未完成的工作。阅读团队的任务票，看看每个人都在做的事情以及即将发生的事情。那些积压的工作也是寻找新手任务的好地方。旧的任务票大概分为三大类：不再相关的，有用但次要的，以及过于重大且无法立刻解决的。弄清楚你正在看的任务票属于这几类中的哪一类。
出版物和在线资源是互补关系。阅读书籍和论文是深入研究某个主题的很棒的途径。出版物大多很可靠，只是有些过时。在线资源则正好相反，不那么可靠，但很能跟上潮流。在实施黑客新闻（hacker news）中的最新想法之前要记得“踩下刹车”，因为采用保守一些的技术选型是有益处的。（在第3章中有更多关于这个问题的介绍。）
加入一个阅读小组来跟进学术界和工业界的最新进展。一些公司可能有内部的阅读小组，去问问看。如果你的公司没有，可以考虑成立一个。你也可以加入当地的“Papers We Love”组织，这些组织会定期地阅读和讨论计算机科学方面的论文。
学习阅读代码
在职业生涯的早期，德米特里被分配了一个传统的Java应用程序，并被要求“搞定它”。他是团队中唯一对Java比较熟悉的人，而他的管理者想改进一些特性。源代码中充满了……奇特之处。所有的变量都使用了类似于a、b、c这样的命名。更糟糕的是，一个方法中的a会在另一个方法中变成d。这份源代码既没有更新履历，也没有测试代码。最初的开发者早已离开。不用说，这肯定是一个雷区。
每当德米特里需要改变代码库中的某些东西时，他都会屏蔽所有的杂念，仔细阅读代码，重新命名变量，跟踪代码逻辑，在纸上画一些东西，并进行实验。这是个缓慢的过程。德米特里越来越欣赏这个代码库了。该代码库正在做复杂的事情。他开始对写这个东西的人有些敬畏，因为这个人可以在没有合理的变量命名的情况下，把所有的东西都记在脑子里。最后，在午餐时，德米特里流露出了敬佩之情。他的同事看着他，仿佛他长出了第二个脑袋。“德米特里，我们没有原始的代码。你正研究的东西是反编译器的输出结果。正常人是不会这样写代码的！”我们不建议用这种方式来学习阅读代码。但是，孩子们，这种经历让德米特里学会了慢慢来，为了理解而阅读，而且永远都不会相信变量名称。
你可以从一个优秀的讲座中学到许多东西。从过去录制的视频演示开始，包括公司内部演示和外部的YouTube视频。观看教程、技术讲座和阅读会议简报（conference presentations）。四处打听打听，找到好的内容。你通常可以用1.5倍速甚至2倍速观看视频，以节省时间，但不要被动地观看。你需要做笔记来帮助记忆，并学习任何不熟悉的概念或术语。
如果你的公司提供午餐会（brown bag）和技术讲座，就去参加。这些非正式的演讲一般是在现场举办的，所以很容易就可以参加。它们也是你公司内部的活动，所以你会获得真正有价值的信息。
会议和聚会非常有利于建立联系和发现新的想法。它们值得偶尔参加，但不要过度。那些有价值的内容与所有内容的比例——也就是信噪比，通常都很低，而且许多会议之后都可以在网上获得。
会议大致有3种类型：学术会议、草根兴趣小组聚会和供应商展示会。学术会议有很棒的内容，但阅读论文和参加小型的、更有针对性的聚会通常会更好。对于想获得实用技巧和想会见有经验的从业者的人来说，那些基于兴趣的聚会非常好，可以找几个这样的聚会去参加一下。供应商展示会一般是较大和较吸引眼球的。它们是大型科技公司的营销工具，但不适合学习。与你的同事一起参加这种展示会很有趣，但每年超过一次就可能是在浪费时间了。问问周围的人，找到那些比较好的。请记住，有些雇主会支付门票、旅行和住宿的费用。
旁听学术聚会
几年前，德米特里和他的同事彼得·阿尔瓦罗正在努力地使他们的数据仓库发挥作用，他们认为将聚合任务分发给廉价服务器集群是一个好办法。在他们的研究中，彼得发现谷歌最近发布了关于MapReduce的论文。强大的谷歌公司正在做彼得和德米特里想做的事情！他们发现了更多有趣的论文，并想找人深入探讨一下。德米特里发现加州大学伯克利分校的数据库小组在举办技术方面的午餐会并对公众开放。彼得和德米特里成了那里的常客（他们小心翼翼地不吃免费的比萨饼，直到所有的学生都吃饱了）。他们甚至可以偶尔地参与到对话中。
他们的学习进入了高速发展阶段。最终，彼得永远留在了这里，他开始学习这里的博士课程，现在是加州大学圣克鲁兹分校的教授。德米特里也跳到了加州大学的研究生院。在他们离开两年后，昂贵的数据仓库被Hadoop所取代，这是一个开源的分布式聚合系统。
如果你开始觉得你不再有学习进展了，可以去当地大学看看。他们有大量向公众开放的项目。扩大你的圈子，接触新的想法。去上研究生是一个可选项。
跟班学习是指在另一个人执行任务时跟着他。跟随者是一个积极的参与者：他做笔记并提出问题。跟随一名高级工程师是学习新技能的好方法。为了获得更大的收益，你应该在整个跟班学习过程的前后安排时间进行计划和回顾。
当你准备好了，就把角色调换过来。让一名高级工程师跟随你。和你一样，他应该提供反馈。如果出了问题，他也会充当一个安全网。这是一种温和的方式，它可以帮助你轻松面对可怕的情况，例如面试。
结对编程（pair programming）也是一种很好的学习方式。两名工程师一起写代码，轮流打字。这需要一些时间来适应，但这是相互学习最快的方式之一。这种技术的倡导者还声称，它可以提高代码质量。如果你的队友愿意，我们强烈建议你尝试一下。结对编程也不仅仅是针对初级工程师的，所有级别的队友都可以从中受益。
一些公司也鼓励向非工程角色进行跟班学习。跟随客户支持部门和销售演示部门学习是一种可以开阔眼界的方式，这样做可以了解你的客户。写下并分享你的观察，与你的管理者和高级工程师一同优先考虑由经验激发出来的想法。
从事副业项目会让你接触新的技术和想法。当你只有自己工作时，你可以跳过那些被称为“软件工程”的环节（测试、运维、代码评审等）。忽略这些方面可以让你快速地学习新技术，只是不要忘记在工作中还有那些“真实的”环节。
你也可以参与开源项目。大多数开源项目欢迎所有人贡献力量。这是一种学习和建立职业联系的好方法。你甚至可以通过开源社区找到未来的工作。请记住，这些项目通常是由志愿者运营的。不要指望你能获得和工作中同样的周转速度。有时人们会很忙，他们会消失一段时间。
不要根据你认为你需要学习的领域来选择项目。找到你有兴趣去解决的问题，并使用你想学习的工具来解决这些问题。一个可以从内激励你的目标会让你更长时间地参与，你也会学到更多。
公司一般会对外部的工作有规定，询问你公司的政策。不要使用公司资源（你的公司提供的笔记本计算机）来从事副业项目，不要在工作中从事副业项目，避免那些与你公司有竞争的副业项目。确认你是否可以在工作中或在家里为开源项目做贡献，有些公司会希望你只用指定的工作账户提交代码，有些公司则会希望你只使用个人账户。了解你是否保留对你的副业项目的所有权。问问你的管理者，你是否需要得到批准。从长远来看，获得明确的信息将保护你免受挫折。
所有的工程师都应该提出问题，这是学习的一个重要部分。新手工程师会担心打扰队友而试图自己解决所有问题，这样做既慢又没有效果。有效地提出问题将帮助你快速地学习，而不会烦扰其他人。使用这3个步骤：做研究，提出明确的问题，并恰当地安排解决你的问题所需的时间。
尝试自己寻找答案。即使你的同事知道答案，你也要付出努力，这样你会学到更多。如果你没有找到答案，当你寻求帮助时，你的调查仍然会成为你的起点。
不要只是在互联网上搜索。信息还存在于文档、内部论坛、自述文件（README）、源代码和错误跟踪器中。如果你的问题是关于代码的，试着把它变成一个可以演示的单元测试。你的问题有可能曾经被别人问过：查看邮件列表或聊天记录。你收集的信息将会引领你到那些可测试的方案中去。如果你找不到任何线索，试着自己通过实验来解决它。记录下你在哪里寻找过，你做了什么，为什么这么做，发生了什么，以及你学到了什么。
限制你研究一个问题时预期花费的时间。在你开始研究之前就应该设定好时间限制，这样可以鼓励你遵守这个限制，防止收益递减（研究最终会拖累生产性）。考虑你最终何时需要知道答案，然后留出足够的时间来提出问题，得到回答，并根据你学到的东西采取行动。
一旦你到达了设定的时间限制，就需要请人帮忙。只有在你取得良好进展的情况下才可以超过之前的时间限制。如果你已经超过了第一个时间限制，那么需要再设定一个。如果你在第二个时限之后仍然找不到确定的答案，就应该及时止损并寻求帮助。及时止损需要自律和练习，因为你要对自己负责。
在提出问题时描述你已经知道的情况。不要只是分享你的原始笔记。简要地描述你所做的尝试和发现，这表明你已经花了很多时间去试图自己解决这个问题。这样做也会给别人一个回答你的起点。
下面的例子是一种糟糕的提问方式。
嗨，艾丽斯。
你知道为什么testKeyValues在TestKVStore中会失败吗？要重新运行这个真的拖慢了我们的构建速度。
谢谢！
潘卡
这让艾丽斯几乎没什么可说的。这听起来隐约像是潘卡在责怪艾丽斯，这可能不是他的本意。这种表述有一点儿懒惰。将上面的表述与下面的表述进行比较。
嗨，艾丽斯。
我在调查为什么testKeyValues在TestKVStore中会失败时遇到了一些麻烦（在DistKV的代码库中）。肖恩建议我来问问你。希望你能帮助我。
在我看来，这个测试差不多每执行3次就会失败1次。这似乎是随机的。我试着单独运行它，但还是失败了，所以我认为这不是测试用例与测试用例之间的问题。肖恩在他的计算机上循环运行了这个测试，但仍无法重现它。我在源代码中没有看到任何明显的东西能解释这个测试失败的原因。这似乎是某种竞争条件。有什么想法吗？
有人告诉我这不太可能影响到生产环境，所以并不十分紧急。但是，每次发生这种情况，拍打测试都会花费我们20到30分钟，所以我很想知道如何解决这个问题。我附上了显示测试失败的日志和我当前所有的环境设置，以备不时之需。
谢谢！
潘卡
在第二个例子中，潘卡给出了一些背景，描述了问题，告诉艾丽斯他已经尝试了什么，然后才请求帮助。他还指出了影响和紧急程度。第二个例子非常简洁，但又附有详细的信息，所以艾丽斯不需要主动去捕获这个问题。艾丽斯会帮助潘卡解决问题。她同时会记住，潘卡是可靠的。像这样的请求将建立潘卡在同事眼中的可信度。
写第二种邮件需要更多的努力，但这是值得的。请把它应用到工作中。
就像你一样，其他人也在努力完成工作，他们需要专注。当他们进入状态时，不要打扰他们——即使问题很简单，即使你心里清楚他们知道答案，即使你的工作被卡住了。除非有重大问题发生，真的，请不要打扰他们。
公司有不同的惯例来标识“请勿打扰”。耳机、耳塞或耳罩是通用的标识。关于“休息区”（lounge space）的解读有一些混乱，有些人认为在办公桌以外的地方工作是“神圣不可侵犯”的，他们不想被人发现；有些人则将在共享空间内的工程师理解为“可以打扰”。请确保你了解你公司的惯例！
走上前去与人交谈会迫使他们做出反应。即使他们只是回答说很忙，你也已经打断了他们，使他们失去了注意力。如果你需要的人很忙，同时你又不想自己的工作进程被卡住，这时候你就需要找到一种异步的沟通方式。
在网络通信中，组播（multicast）是指将消息发送到一个组而不是个人目标；异步（asynchronous）是指可以稍后处理的消息，而不需要立即响应。这些概念也适用于人们之间的通信。
发出你的问题，方便大家可以在自己的位置上（异步）做出回应（组播）。以一种大家都能看到的方式来发出问题，这样当你得到帮助的时候就很显眼。解决办法也会变成可被发现的，所以其他人以后也能找到当时讨论的内容。
这通常意味着需要使用群发邮件列表或群聊（例如，德米特里的公司有一个叫作#sw-helping-sw的频道）。即使你需要一个特定的人来回答问题，也要使用共享论坛。你可以在帖子中提到他们的名字。
聊天和电子邮件对简单的问题很实用，但复杂的讨论很难异步进行。面对面的交流是“高带宽”和“低延迟”的。你可以快速地解决很多问题。不过，这依然有代价。打断你的同事会影响他们的工作效率。要想避免出现这种情况，可以同你的技术领导或管理者约定专门的时间来解决非紧急的问题。
安排一次会议，或者使用“办公室答疑时间”（如果他们预留了的话）。写下你的问题并保留到会议上。在此期间，你可以继续做你的调查。随着其他问题的出现，你的清单也会越来越长，这很好。在你设置的会议议程中应包括这个清单，不要只靠脑袋来记问题，也不要事前不做功课就来参加。
如果你已经没有问题了，就请取消会议。如果你发现自己反复地取消会议，就自省一下这种会议是否还有用。如果已经没用了，就不要再安排。
知道如何学习以及如何提出问题还不够。你还必须避开那些会减缓你成长的障碍。一般有两个常见的障碍会影响许多工程师，即“冒充者综合征”和邓宁-克鲁格效应。如果你了解这些现象是什么，以及如何克服它们，你会成长得更快。
大多数新手工程师在开始工作时处于“有意识的无能力”阶段。有很多东西需要学习，而其他人似乎早已遥遥领先。你可能会担心你不属于这个行业，或者找到工作只是运气好。对自己苛责很容易，我们也有过这样的经历。无论我们多么频繁地告诉工程师他们做得很好，有些人就是不相信。即使他们升职了，还是不信！这让他们感到很不舒服。他们说他们只是很幸运，他们不值得别人认可，或者是升职标准太宽松了。这就是冒充者综合征。保利娜·罗斯·克朗斯博士和苏珊娜·阿门特·艾姆斯博士在1978年的一篇名为《高成就女性中的冒充者现象：动态与治疗干预》（“The Impostor Phenomenon in High Achieving Women: Dynamics and Therapeutic Intervention”）的研究文章中首次描述了这种现象。
尽管有着杰出的学术和职业成就，经历着冒充者现象的女性仍然坚持认为她们真的不聪明，而且还愚弄了任何不这么想的人。众多的成就似乎并不影响冒充者的信念，而这些成就本身就是能充分证明智力水平卓越的客观证据。
如果这能引起你的共鸣，你就知道自我怀疑很常见。只要努力，这些感觉就会过去。你可以用几种策略来推动事情的发展：觉知（awareness）、重塑（reframing）以及与同事交谈。
冒充者综合征会自我强化。每一个错误都会被看作能力匮乏的证明，而每一项成功都是优秀“冒充者”冒充的证据。一旦某个人进入了这个循环，就很难摆脱它。觉知会在下面的场景里帮助你。如果你注意到了上文的循环，你可以有意识地打破它。当你取得一些成就的时候，那是因为你真真切切地做到了，你并不只是运气好。
不要忽视赞美和成就。即使是小事情，也要把它们写下来。你的同行都是有能力的人，如果他们说一些积极的话，那是因为他们确实有充分的理由这样做。练习重塑消极的想法：“我不得不求助达里亚来帮助解决软件上的竞争条件难题”变成“我联系了达里亚，现在我知道了如何解决竞争条件难题！”。规划你要完成的任务，并注意你实现了目标的时候。这将帮你建立信心。
获得反馈也有助于缓解冒充者综合征。请你尊敬的人来告诉你，你做得怎么样。这个人可以是你的管理者、导师，或者只是你仰慕的工程师。重要的是你要信任他们，并觉得与他们谈论自我怀疑是安全的。
治疗可能也会有帮助。可以利用治疗来获得你的优势，并克服短期的挑战。冒充者综合征，以及可能随之并发的焦虑和抑郁，是一个复杂的话题。如果你仍在苦苦挣扎，考虑接触几名治疗师，找到一个适合你的方法。
与冒充者综合征相反的是邓宁-克鲁格效应。这是一种认知偏见，人们认为自己比实际情况更有能力。处于“无意识的无能力”阶段的工程师不知道自己不知道什么，所以他们不能准确地评估自己和他人的表现。他们太自信了。他们总是到处批判公司的技术栈，抱怨代码的质量，贬低设计。他们确信自己的想法是正确的。他们的默认模式是直接回绝或无视反馈。拒绝所有的建议会亮起一盏巨大的红灯：完全自信标志着盲点。
幸运的是，邓宁-克鲁格效应在新手工程师中并不常见。有许多方法可以对抗它：有意识地培养好奇心；对犯错持开放态度；找到一位受人尊敬的工程师，询问他你做得怎么样，并真正地倾听；讨论设计决策，尤其是那些你不同意的决策，问问为什么会做出这样的决策；培养一种权衡利弊的心态，而不是非黑即白的心态。
| 需要做的 |
不应该做的 |
|---|---|
| ● 多尝试和实验代码 |
● 只是大量炮制劣质代码 |
| ● 多阅读设计文档和他人的代码 |
● 害怕承担风险和失败 |
| ● 参加一些聚会、在线社区、兴趣小组和导师计划 |
● 过于频繁地参加研讨会 |
| ● 多读论文和博客 |
● 害怕提出问题 |
| ● 多采用“非打扰式”交流 |
|
| ● 旁听面试以及参与On-Call轮换 |
戴夫·胡佛和阿德瓦莱·奥希尼亚合著的《软件开发者路线图：从学徒到高手》（Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman，已由机械工业出版社于2010年引进出版）是一个伟大的“模式”（pattern）集合，人们可以利用这些模式在新的环境中起步，从中寻求指导，深入地学习技能，并克服常见的障碍。
关于如何提问的更多信息，我们推荐韦恩·贝克写作的《你要做的全部就是提问：如何掌握成功最重要的技能》（All You Have to Do Is Ask:How to Master the Most Important Skill for Success，由Currency出版社于2020年出版），这本书分为两部分：第一部分讨论了提出问题的价值以及为什么它很难；第二部分是一个有效提问的工具箱。
关于结对编程的更多信息，一本经典的书是由肯特·贝克和辛西娅·安德烈斯写作的《解析极限编程——拥抱变化》（Extreme Programming Explained: Embrace Change，已由机械工业出版社于2011年引进出版）。这本书涵盖的内容远远超过了结对编程。如果你只对较短的介绍感兴趣，比吉塔·贝克勒和尼娜·西塞格的文章《论结对编程》（“On Pair Programming”）是一篇优秀的使用指南。
如果冒充者综合征或邓宁-克鲁格效应的部分引起了你的共鸣，请查看埃米·卡迪的《高能量姿势：肢体语言打造个人影响力》（Presence: Bringing Your Boldest Self to Your Biggest Challenges，已由中信出版集团于2019年引进出版）。该书涉及许多工作焦虑和过度自信的常见原因。
