第 8 章规模化的良好影响力

你如何提升身边人的技能？作为 Staff 工程师，你的部分工作就是让同事们把工作做得更好、拿出更好的解决方案、成为更好的工程师。上一章我们已经踏上了这段旅程，提出了榜样工程师的概念：尽你所能做出最好的工程工作，并让别人看到。我们说某人是“良好的影响”时，通常就是这个意思：他们的行为方式正是我们希望别人效仿的。

但现在我们要更进一步，看看你可以用哪些更主动的方式，运用你的良好影响力来提升他人的技能，改善组织的工程文化。

良好影响力

当你与技能欠缺或标准不如你的人共事时，不要沮丧：花点时间把他们带上一个台阶。

为什么帮助其他工程师把工作做得更好如此重要？首先，好的工程必然会超出你个人的范畴。如果你的同事工作做得更好，你也能把工作做得更好。虽然有些工程师是非凡的独奏者，但即便是最强大的大师，也会遇到一些大到无法独自解决的问题。如果你能帮助同事成为更好的工程师，你就能与更有能力的人共事，这意味着你自己的工作会更轻松（也更少烦心事）。更好的工程师意味着更好的软件，也就意味着更好的业务成果。

第二个原因是这个行业一直在变。即使你的工程组织眼下处于最前沿，迟早也会出现某种改变游戏规则的新架构、新工具或新流程，你会希望所有人都采用它。除非你懂得如何施加影响、如何传授新技能，否则让与你合作的团队用上它将是一场令人沮丧的折腾。

最后一个原因是，这本来就是正确的事。作为资深人士，你对组织构建软件的水平，甚至对整个行业的行为方式和发展方向，都有着超乎寻常的影响力。就像你会为提升代码质量、可靠性和可用性而自豪一样，你也可以为自己的高标准而自豪。如果你把中级同事培养成出色的工程师，想想 10 年后他们又会培养出多少中级工程师。你是在把高标准传递到未来。

对我们大多数人来说，通过影响力来领导，始于一对一的关系：评审某人的代码、带一名实习生，或者指导一名应届毕业生。之后你可能会开始带领小团队，大概会和团队里的每个人进行一对一会谈。但随着你的范围扩大，单靠个人之间的互动就越来越难产生足够的影响力了。一天的时间根本不够用。正如 VMware 的首席工程师 Bryan Liles 所描述的：“我在 VMware 的工作是能够影响 14,000 名工程师……我一直在思考‘我能做些什么让 14,000 名工程师变得更好？’”

取决于你的资历、范围和抱负，你想影响的人可能要少得多（也可能多得多！）。本章我们将从微观和宏观两个层面来看良好影响力：从提升同事、团队或小组的技能，到改变整个组织乃至整个行业的发展轨迹。我会描述影响力的三个层级（见图 8-1）：

个人

你的工作方式能让另一个人的技能得到成长。

群体

你通过同时为多个人带来新技能或新做法，来扩大自己的影响力。

催化

你带来的改变超出了你的直接影响。你建立起框架或社区结构，让你的积极影响在你抽身之后仍能延续下去。

图 8-1. 影响力的层级。群体影响力比个人影响力走得更远。催化影响力即便在你停止投入更多精力之后，仍会持续发挥作用。

影响力可以采取哪些形式？我会介绍四种帮同事提升一个台阶的机制，并为每个层级举出例子：

建议

我们从给出建议开始，包括别人主动征求的建议和未经征求的建议。在个人层级，这可以是指导、同侪反馈，或者只是回答问题。你可以通过写作和演讲把建议扩展到群体层级，并通过让同事们更容易互相给建议来达到催化层级。

教学

我们会看看如何通过培训、结对、跟岗或辅导，有意识地向个人传授技能。然后借助入职资料、codelab、课程和工作坊扩展到群体。催化层级则是教别人如何教学、制定课程体系，以及影响每个人会接触到的主题。

护栏

我们会探讨如何为人们提供护栏，让他们能够安全地工作。针对个人，我会谈到代码评审、设计评审，以及如何成为某人项目的护栏。针对群体，我们会看看一些能让我们保持正轨的流程、政策和机器人。最后，在催化层级，我们会探讨终极护栏：文化变革。

机会

最后，我们会看看如何通过为人们匹配有助于学习的机会来帮助他们成长。针对个人，我会谈到委派、举荐和表彰出色的工作。针对群体，你能给团队的最大机会，或许是退后一步、腾出空间、分享聚光灯。而当你举荐过的初级和中级同事成长为充满活力、技术娴熟、善于解决问题的资深人士，去迎接挑战、创造出你从未想象过的新机会时，它就成了催化。

表 8-1 展示了这三个层级和四种机制，并附有一些例子。

表 8-1. 在组织内外扩展建议、教学、护栏和机会的一些例子。

	个人	群体	催化
建议	指导、分享知识、反馈	技术分享、文档、文章	导师计划、技术分享活动
教学	代码评审、设计评审、辅导、结对、跟岗	课程、codelab	入职课程体系、教别人如何教学
护栏	代码评审、变更评审、设计评审	流程、linter、风格指南	框架、文化变革
机会	委派、举荐、加油打气、持续支持	分享聚光灯、为团队赋能	营造机会文化、自豪地看着你那些出类拔萃的初级同事改变世界

把这些层级和机制看作一份可供你选择的选项清单，而不是一张需要逐项完成的检查表。发挥你的长处，去做那些你喜欢的、觉得容易的或者想要做得更好的事。另外，虽然它们是按层级排列的，但不要跳过那些“较小”的事。通过代码评审或举荐来提升同事，会在整个公司产生涟漪效应；即便是最能改变世界的技术专家，也仍会指导那些他们认为值得投入的人。

同样，也不要太执着于追求表 8-1 右侧一栏那些催化类型的影响力。项目和框架太多会让组织不堪重负，而参与一项现有的举措，往往比另起炉灶更有影响力。比如，如果已经有一套入职课程体系，在其中讲一门课通常比另外搞一个培训计划更有价值。带领一个团队完成一项困难的设计，往往比修修补补 RFC 流程重要得多。先做好个人和群体层面的工作，只有在需求和价值非常明确时才去拓展得更广。

说了这么多，我们就从建议开始吧。

建议

俗话说：“免费的建议，就值你付的那个价钱。”建议确实噪声很大：好信号里混杂着坏信号，而且它往往不是为接收者量身定制的。但每个人都有需要建议的时候，而给出建议是你传递经验的方式之一。如果你取得过成功、也犯过错误，就让别人也从中学习吧。

谁问你了？

在提出建议之前，先想一想它是否受欢迎。征求的建议，是指别人主动向你要一些东西：一个推荐、对其工作的反馈、帮忙决定该怎么做。未经征求的建议，则是对方并没有问。

在说出你的想法之前，先想想对方是否在向你征求意见。也想想你是否有足够的上下文，能告诉他们一些既有帮助又不那么显而易见的东西。如果你不确定自己的建议是否受欢迎，问问他们。

有时候，未经征求的建议是有价值的。“你的幻灯片很棒，但你演讲时一直对着自己的鞋子说话，很难听清你在说什么”，这是一条难以开口但大概是善意的未经征求的建议。¹ 但要考虑你的角色以及你和对方的关系。有些建议应该来自朋友，而不是陌生人。还有，同样不要直接开口就说。先问一句“我可以给你一些建议吗？”，得到对方的允许。

下面是另外一些未经征求的建议可能有帮助的场合：

当你认为对方身处某种他们自己看不清的处境时。“嘿，我知道这不是你要问的问题，但你描述的那份工作的状况看起来并不健康。你值得更好的。”
当你掌握着对方不知道的关键信息时。“我听你说要开始使用 Foo 平台了；只是想确认你知道它明年就要下线了。”

如果你迫不及待地想就一个没人问你的话题给出未经征求的建议，不妨考虑写篇博客或者发条推文。²

个人层面的建议

你可以通过几种方式，就某人所处的情况给出个人层面的建议。包括充当他们的导师角色、回答他们的问题、对他们完成的工作给出意见，或者在绩效评估时给出同侪反馈。

指导

指导往往是工程师第一次体验领导力。在设有正式导师计划的公司里，你可能会被指派去帮助一位新人熟悉环境。指导也可以自然而然地发生：坐在某人旁边，介绍一下自己，回答他们的问题，你可能就会发现自己有了一位非正式的被指导者。

通过分享你的视角和所学，你可以加速别人的学习，让他们免于犯不必要的错误。你可以给他们讲讲你经历过的类似情况、你当时是怎么做的、结果如何。高级工程总监 Neha Batra 把指导描述为“分享你的经验，让工程师自己能够加以利用”。但要记住，指导关注的是你的经验。

无论是否被征求，对你有效的建议未必对别人有效。作家兼管理教练 Lara Hogan（本章会多次提到她的名字！）提醒说：“对一个人可能有效的建议（‘开会时声音大一点！’或者‘找老板要求加薪！’）可能会对另一个人不利，因为少数群体的成员会在无意识中被以不同的方式评价和对待。”³ 十年前的最佳实践对现在一位更年轻的同事也可能不再适用，而你当年经历中的社交动态（或技术栈）也未必能很好地对应你同事眼下面对的情况。我就曾经有同事反驳过我给错了对象的建议。当总监是你的平级时，“直接私信总监，请他们邀请你参加会议”说起来很轻松；而当对方是你老板的老板的老板时，这就难得多了！

在导师与被指导者的对话中，要小心未经征求的建议。比如，当某人开始描述一个困难的项目时，最容易、最直觉的反应就是说出你这位睿智的建议者在同样情况下会怎么做。而弄清楚他们真正需要什么，才是更善意（尽管更难）的做法。也许他们确实想要帮助。但同样可能的是，他们只是想确认别人也会觉得这个问题或情况很难。他们可能是在做小黄鸭调试，通过给你讲解来帮自己理清思路。他们也可能只是想讲讲自己的“战斗故事”，听听别人对他们一路走来的同情和祝贺。未经征求的建议会打断所有这些。不妨问一句“你是需要倾诉一下，还是在寻求建议？”，然后按对方的需要，给予安慰和认可，或者给出解决方案。

指导不只是针对新人的：我的被指导者中有拥有几十年经验的人，我自己也有会去请教的导师。指导也不一定是单向的。你的被指导者可能会给你带来新的视角，或者教你一些他们比你更了解的主题。

如果你要开始一段指导关系，就要为它的成功做好准备。设定预期，比如在六周内每周见一次面。就你们想达成的目标达成一致：被指导者是想顺利入职、在新公司感到自在，还是想熟悉一个新的代码库，或者想获得职业建议、朝着一个新角色努力？如果这些都事先确定好，你们就不太可能坐在房间里大眼瞪小眼，一副“我们本来要聊什么来着？”的样子。

回答问题

如果你拥有一座庞大的知识宝库，而每个人都不敢问你任何问题，那么你的知识就只会留在你自己的脑子里。要让人容易接近。取决于你的工作风格，这可能意味着设立答疑时间、表现得友好且方便私信，或者花些时间就待在与你合作的团队附近——有沙发的办公空间特别适合做这种事。

让人觉得找你是值得的。有些工程师似乎把自己的知识守得严严实实，只回答直接的问题，多一个字都不说。

“/user 接口能给我用户的全名吗？”初级工程师问。

“不能，”高级工程师回答，“它只能给你用户名。”

初级工程师试图绕过这个问题折腾了一个小时，然后才紧张地问：“有没有别的接口能给我全名？”

“当然有，”高级工程师说，“用 /fulluser。”

白白浪费了一个小时！这位资深人士掌握着信息，却没想到要把它告诉对方。这并不是说你应该信息倾泻，把每一条可能与当前话题有关的零碎信息都一股脑儿倒出来。但要理解对方在隐含地征求什么建议，即使对方没有直接问出来。如果你不确定，就问问同事想做什么，问问他们是否需要帮助。

代码评审和设计评审也是回答隐含问题、给出建议的时机。如果你发现同事有某个地方可以用更好的方式解决问题，就告诉他们。但要说清楚你只是在分享一些有趣的信息，还是在要求他们改变方向：收到一条光秃秃的评论，比如“Foo 库在这里也能用”，却没有任何上下文说明这是否意味着对方讨厌当前的做法，这会让人很沮丧。

领域相关的信息不只是技术。如果你已经摸索出在组织中周旋和把事情办成的方法，这就是可以传授给被指导者和其他同事的宝贵知识。把你在第 2 章中绘制的地形图分享出去吧！

反馈

在我目前的工作中，我给自己指派的角色之一，是为准备会议演讲的同事充当试听观众。我喜欢看技术演讲，也花了很多时间学习如何把演讲做好，所以演讲者和我都能从中受益。看演讲时，我会记大量笔记，标出我觉得有趣、有洞见或有教育意义的部分。但我也会指出任何不奏效的地方、任何我认为不正确的地方、任何让我开始走神的地方。好的坏的，我都实话实说。否则就是在浪费演讲者的时间。

当有人请你评审一份文档、一个拉取请求或一场会议演讲时，一定要指出你认为很棒的部分，但也要尊重对方，（善意地！）诚实对待他们的工作。给出建设性的批评反馈并不容易。要准确梳理出哪里不奏效，再找到合适的话来解释它为什么还不够好，这需要花费精力。这是一场更难的对话。但如果你隐瞒真相，就帮不了你的同事。

同侪评审

如果你的公司有绩效管理周期，你可能会被要求提供一种特定的反馈：同侪评审。这类评审有两类读者，你应该把两者都放在心上。

第一类读者是请你提供反馈的人。假设他们之所以问，是因为真心想知道如何改进。我见过有人在同侪反馈中被“这个人可以在哪些方面做得更好？”这类问题难住，因为答案很容易被看成批评。但请按字面意思理解这个问题：你的同事可以在哪些方面做得更好？他们怎样才能变得更出色？如果你一个也想不出来，就问问自己为什么他们还没有高一个级别（或者两个！），然后就他们为此应该着重培养的行为给出建议。

但也要记住，这份反馈会被对方的经理读到，可能还会被其他正在校准其绩效或评估其晋升的人读到。给这些人提供他们所需的信息，帮助你的同事成长，并让他们注意到需要解决的模式。但要想一想你的话会被如何理解，以及不了解你所描述工作的人是否会断章取义。如果你发现自己因为不想意外毁掉一次实至名归的晋升，而迟迟不肯描述某个有待成长的方面，不妨考虑改为通过邮件或当面私下给出反馈。

就像给出指导建议一样，要记住对一个人有效的建议，对另一个人可能是糟糕的建议。这在关于沟通风格的建议中尤其普遍。例如，“要强势一些”这条建议会让某些人看起来更像领导者，却会给另一些人带来麻烦。科技界女性圈子里有个常见的玩笑：当你第一次收到说你“咄咄逼人”的同侪评审时，你就知道自己在以高级别的方式行事了。⁴（那也可能是你的评审第一次没有说你应该“更有主见”。这条线很难拿捏。）所以要警惕隐性偏见，留意你是如何描述不同人身上的相同行为的。那是“凝聚共识”还是“优柔寡断”？他们是“难得的接地气”还是“不专业”？这往往取决于你说的是谁。Project Include 的人就如何提供反馈给出了更多建议。

把建议扩展到群体

你不可能和每个需要建议的人单独见面，也不可能为整个组织写反馈：那样你这个季度就一点时间都不剩了。但你可以就任何你想讲的东西做一场技术分享或写一篇文章，而且它很可能会触达一些觉得它有用的人。这是扩展建议的好办法。

多年前，Google 的一群志愿者想要提高测试质量，想出了一个新颖的办法：他们开始把建议写成简单的单页文档，打印出来，贴在厕所隔间里。“厕所里的测试”（Testing on the Toilet）是未经征求的建议的极致，但它很受欢迎，也很有趣，而且大家真的会读！

如果你想把某件事告诉更多人，就把它写下来。有了文档，你就不必一遍又一遍地解释怎么做某件事。一份 FAQ、一篇操作指南，甚至一个描述清楚的频道主题，都能让你只说一次，却被很多人读到。如果你写的东西也适用于公司以外的人，不妨考虑以博客或文章的形式进一步分享。

此外，要寻找机会拿到话筒和听众。你能在全员大会、技术会议或技术分享活动上争取到一个时段吗？有时你可以利用这些机会，在传达别人请你分享的信息的同时，传达你自己关注的信息。有一次我受邀在一个很大的群体面前讲一次由我挑选的事故。当时我正在努力宣传依赖管理，以及审慎对待你所依赖的系统有多么重要。于是我给大家讲了最近的一次故障：一个循环依赖导致系统无法恢复上线，让那次故障严重得多。⁵ 在这场大型会议上演讲的机会，让我能够以突出我想传达的信息的方式来讲述那次故障。这就是在恰当的时机拿到了听众和话筒。

成为催化剂

如果你想成为催化剂，就要建立起不需要你参与的建议流动渠道。让同事们更容易互相帮助。

如果你的团队或组织要依靠一对一的交谈才能弄明白任何东西是怎么运作的，那么你能做的最有力的事情之一，就是鼓励大家把东西写下来。从小处着手：从口口相传的文化一下子变成把所有东西都写下来，不会给你赢得任何朋友。相反，要寻找一个小而有意义的改变。你们是否缺少一个好用的文档平台？各团队是否愿意为最常打断他们的问题建立一份 FAQ？你的总监是否会支持每季度设立一个文档日？

你可以通过组织每月的技术分享或午餐学习会，来扩展“听众加话筒”式的建议。这比仅仅安排会议的投入要大得多：你得去征集演讲、发送提醒，可能还要观看彩排。要清楚自己要投入什么，在你的时间图上为它做好规划，最好一开始就至少有三个人来分担工作量。

同样，你可以通过建立导师计划来进一步扩展指导。提醒一句：其中的行政工作会比你预想的更耗时，而且这类工作通常不被视为工程师职责的一部分。如果你能找到一位有兴趣做同样事情的经理，他们可能更容易把这项工作纳入自己的职责描述。说服别人来建立导师计划，同样算是在当催化剂！

教学

接下来是第二种良好影响力，它比建议更进一步：教学。告诉别人一些事情和教别人一些事情有什么区别？在于理解。当你给出建议时，你是在解释你与这个话题的关系，接收者可以采纳你的建议，也可以不采纳。而当你教学时，你要努力让对方不只是接收信息，而是把它内化为自己的东西。

有意识的教学并不只是资深的人帮助资历浅的人：每当有新人加入团队，或者你比别人掌握更多领域知识时，它都很有用。比如，我很喜欢请同事给我概述一下他们的系统，这样我就能补上自己对整体架构认知中的空白。在白板前讨论一个小时之后，我会对他们的系统如何与其他系统交互有清晰得多的认识，还会画出一张自己的图，供日后查阅或补充到他们的文档里。

个人层面的教学

只要你和共事的人之间存在知识差距，就存在教学的机会。有时这意味着正式的培训或辅导。但在日常协作的常规结构中，也有大量教学可以做：结对编程、跟岗和评审。

打开一个主题

回想一下你上过的最好的课。它们成功在哪里？我敢打赌，你离开时会觉得自己掌握了一些以前没有掌握的东西：一项可以在此基础上继续发展的新技能或新理解。好的课程会为你“打开”一个主题，激发你的好奇心和兴趣。

教师有明确的目标，通常会正式写进教案里。如果你在教学，你也应该有目标。一些例子：

你是在概述一个系统吗？如果是，到课程结束时，你教的人应该能在白板上画出这个系统，并向别人描述它。
你是在带人过一遍代码库吗？目标是给他们提交第一个拉取请求所需的一切。
你是在演示如何使用某个工具或 API 吗？描述三到五个常见场景，到课程结束时他们应该能独立应对。

成功的教学包括动手学习和激活知识：学生在听的同时也应该动手做。寻找让他们主导的机会，无论是让他们自己使用工具、敲命令，还是在他们自己而不是你的笔记本电脑上打开标签页。如果他们最后能留下一个可供日后查阅的“产物”，比如一张图或一段代码片段，那就更好了。

结对、跟岗与反向跟岗

还有一种教学方式：直接和别人一起工作。一起工作有一系列不同的方式（见图 8-2）：从跟岗，即你做所有的工作、同事在旁观察；到结对，即你们一起工作；再到反向跟岗，即他们做所有的工作，你在旁观看并给出反馈。

图 8-2. 一起工作的不同方式。这条线上的不同位置适用于不同的情况。

跟岗是一种通过示范来教学的方式：你的“影子”观看你如何运用一项技能，并记录你是如何着手的。这是一个成为可见榜样的好机会，可以向同事展示如何以高标准工作。

在结对中，你们仍然一起工作，但“影子”变成了积极的参与者。结对可以是结对编程、合写一份文档、在白板上设计架构，或者一起解决问题。这又是一个树立榜样的机会，同时也是教学的机会：并肩工作意味着你能实时分享知识、检查对方是否理解。

最后，你还可以“反向跟岗”，即由学习者执行任务，由有经验的人观看并给出意见。无论学习者之前多么用心观察，激活知识、亲手练习这项任务才能让他们学到最多。反向跟岗也可以作为一种护栏，我会在本章后面讨论。

代码评审与设计评审

评审代码和设计可以是一种绝佳的教学形式。你可以指出同事可能没意识到的风险，并建议更安全的替代方案。你还可以鼓励那些你希望看到更多的行为。

来自资深人士的评审能让人真正增强信心。但要小心：评审做错了，会摧毁一个人的信心，而不是增强它。面对一连串居高临下、看似武断或者让人看不懂的评论，逐条处理下来可能会让人心力交瘁。

作为教师，你的工作是传授知识、指出问题，同时保住学生的信心和成长型思维。代码评审还会在“护栏”一节再次出现，我会在那里谈谈如何通过评审防止系统受损。但现在，在为了教学而评审时，有以下几点需要牢记：

理解任务了解上下文。你的同事是刚接触这门语言或技术、想要学习，还是只需要多一双眼睛来确保安全？⁶ 还要了解工作所处的阶段：如果你读的是第一版高层草稿，就从基础和方法入手，不要纠缠于吹毛求疵的细节。如果大家都已经认可，而这是发布前的最后一次评审，那就不是提出重大方向性问题的时候了：直接深入细节，格外警惕可能出错的地方。

既解释是什么，也解释为什么像“不要用 shared_ptr，用 unique_ptr”这样的评审意见，只告诉了代码作者现在该做什么。下次他们还是不知道该怎么做。教学意味着分享理解，而不只是事实。虽然代码作者可以去读你刚提到的东西的文档，但他们可能看不出它为什么适用于这里。一段简短的解释，或者一个指向相关文章或具体 Stack Overflow 帖子（而不是通用手册）的链接，会成为帮助他们学习的捷径。

举例说明怎样更好如果设计中有一部分让人困惑，不要只说“请把这里写清楚些”。这让人很难知道该怎么改！给出几个你认为作者想表达的意思的建议。

说清楚什么是重要的经验较少的时候，很难判断别人给你的建议有多重要。有些事情至关重要，有些锦上添花，有些只是个人偏好。给你的建议加上注释，让这一点一目了然。一些例子：

“这里改用参数化查询吧。你这样会给 SQL 注入攻击留下可乘之机——恶意用户可能会删掉我们的数据库！”
“你这种做法能正常工作，但我们更倾向于避免单例模式。这是我们风格指南中解释原因的那一节的链接。”
“我建议这里用一个大一点的微服务，而不是两个小的——我觉得这样更容易维护。不过我不是很坚持，你来决定。”
“这只是个吹毛求疵的意见，但这个文件里其他的拼写都是美式英语，所以这里就写成 organization 而不是 organisation 吧。”⁷

有所取舍 John Turner 是一名软件工程师，曾为 Squarespace 工程博客撰写过关于代码评审的文章。他建议分几轮评审代码：先给出高层意见，再逐步深入细节。正如他所指出的：“如果代码没有完成它应该做的事，那缩进对不对就无关紧要了。”这条建议也适用于 RFC：如果你的第一条意见是作者在解决错误的问题，那么再留一百条技术建议也无济于事。

如果你的意思是“可以”，就说“可以” 说清楚你是否认为自己的意见是阻塞性的，以及除此之外你是否认可这个变更。好的和坏的都要指出来。尤其是在设计文档上，要明确地说“我觉得这个没问题”。代码评审通常以点击一个按钮结束，表示你认为这个变更可以安全合并。但当评审者很多时，每个人都可能犹豫着要等其他人发表意见之后再批准。如果你没有异议，就说出来。

要记住，职业生涯较早期的工程师可能会觉得你令人生畏，即使他们认为你错了，也可能不愿质疑你的建议。想一想如何让你的评论友好、平易近人，嗯，有人情味。如果拉取请求或 RFC 需要大量修改，最有建设性的做法可能并不是用评论把同事淹没，不妨考虑约个时间和他们聊聊，或者一起结对。

辅导

我要谈的最后一种个人层面的教学形式是辅导。指导涉及分享你的个人经验，而辅导则是教人们自己解决问题。这可能是一个更慢的过程，但比起你直接给出答案，你的同事通过自己建立联系能学到多得多的东西。

辅导是一套听起来相当简单、却需要时间和刻意努力才能学会的奇特技能。别指望你一上来就擅长！下面是你需要的三项主要技能：

提开放式问题开放式问题是那些不能用“是”或“否”回答的问题：它们能带来多得多的信息。试着深入挖掘问题本身，而不是一上来就给出解决方案。提出一些问题，帮助被辅导者识别并梳理他们可能还没有考虑过的问题的各个方面。

积极倾听把你听到的内容复述回去，确保你真的理解了，也让对方听听你是如何概括他们所说的话的。被理解的感觉可能非常有力量，能让人不那么孤单。你的概括可以为同事提供一种描述他们正在处理的事情的新方式，帮助他们想出新的解决方案。

留出空间为被辅导者留出足够的空间和沉默，让他们去思考。如果你习惯在出现沉默时条件反射般地插话，那就在再次开口之前在心里数到五，让对方有时间消化。

刚开始做辅导时，不直接帮忙会让你觉得很奇怪。如果你知道答案，难道不该直接给出来吗？不该。正如管理顾问 Julia Milner 在她的 TEDx 演讲中所提醒的，你不可能了解情况的每一个细节。当你提供解决方案时，被辅导者很可能会条件反射般地回应 Milner 所说的“是的，但是……”，也就是一个你的建议行不通的理由。她说，好的辅导应该是引导出他们自己最好的想法，为他们提供思考的空间，并帮助他们走完自己的旅程，找到适合他们的解决方案。

把教学扩展到群体

一次教一个人，对那个人来说很好，但这种传播信息的方式太慢了。你可以通过制作课程材料来扩展你的教学。

准备一门课需要花费大量精力。第一次讲课的前期成本很高，但每多讲一次，这个成本就被摊薄一次。和个人层面的教学一样，你的课程应该有一个明确的目标：学生在结束时会知道什么，或者能做什么。加入练习，或者其他能让学生实践所学内容的方式。

如果你想让课程异步进行，不妨考虑做一些学生可以按自己节奏使用的东西。这类教学的一个绝佳例子是 codelab：一种引导式教程，带领学生一步步构建某样东西或完成练习。⁸

我曾经参与过一个项目，它长期资金不足，靠着一批轮换的志愿者、实习生和参加短期驻留计划的人维持下来。其中很多人刚进公司，甚至刚入行。直接把他们扔进我们的代码库（一个令人生畏的网络库），会把他们吓得尖叫着逃跑，所以我们设计了一条学习路径，并把它写成了文档。

第一天，我们让他们提交两个拉取请求：一个是往我们的笑话仓库里加一个笑话，另一个是把他们的名字加到团队成员名单上。我们会找个理由在评审中来回讨论几轮，让他们熟悉代码评审流程。第二天，我们会让他们构建并运行一个专门为此编写的小型客户端和服务器。他们会看着它在生产环境中运行，看看它的 UI 以及它导出的日志和指标。然后他们会在本地对这个库做一点修改——比如加一条新的日志消息，甚至调整一下逻辑——再部署上去，向自己证明代码仍然能正常工作，而且他们能在监控数据中看到自己的修改。这非常有效。等到第二周开始做真正的修改时，他们已经不怕这些代码了。它只不过就是代码而已。

当大多数贡献者只待三个月时，你需要让他们尽快上手。我们为每一位新贡献者都使用了这条文档完善的学习路径，没过多久它就收回了我们的投入。

成为催化剂

你可以通过教别人来讲这门课，进一步扩展你的课程。不同的老师有不同的风格；接纳这一点。让新老师开始掌控自己的课程：他们应该有权限编辑幻灯片和练习，或者得到你的认可去创建自己的版本。跟岗观察他们并给出诚实的反馈：他们想要学习。一旦他们开始教别人来讲这门课，这门课就有了脱离你而存在的生命力。（到这个时候，我通常会悄悄溜走，把自己从授课轮值中撤下来。）

如果你的课程适用于所有工程师，就设法把它加进入职课程体系或内部的学习发展路径——这样所有新员工都能学到你希望他们知道的东西，而你不必想办法一个个去找他们。如果你的公司还没有这样的学习文化，那么倡导建立入职流程、推广学习路径，或者搭建一个让创建 codelab 变得容易的框架，都能产生巨大的影响。

护栏

想想悬崖边步道上可能会有的栏杆。它们不是用来倚靠的，但在你需要的时候，可以扶着它们站稳。一个小小的踉跄不会要了你的命：栏杆会阻止你跌落悬崖。护栏能鼓励自主、探索和创新。当前路安全时，我们都会走得更快。在本节中，我们会看看你可以用哪些方式为同事加上护栏，先是个人层面，然后是规模化的方式。

个人层面的护栏

你可以通过评审代码、设计和变更，以及在令人望而生畏的项目中提供支持，来充当护栏。

代码、设计与变更评审

我已经介绍过代码评审和设计评审可以成为很好的教学工具。还有第三种评审也很有效：变更管理。这是一个在动手之前，先准确写下你要做什么，并让另一个人确认你描述的步骤是正确的流程。它就像代码评审，只不过评审的是命令行，或者按正确的顺序点击按钮。

你可以把代码、设计和变更评审当作强有力的护栏来帮助同事。当一个人知道自己的工作会被评审时，他们就更容易有信心独立工作。他们知道会有一道检查，确保他们不会引发故障，也不会花几个月时间构建一个根本行不通的架构。护栏帮助他们避免危险的错误。

如果你想当一道好护栏，就永远不要橡皮图章式地批准变更。仔细阅读：每一行代码、设计的每一节、拟议变更的每一步。以下是你应该留意的几类问题：

这项工作应该存在吗？

你的同事打算解决什么问题？他们是不是在用技术方案去解决一个本该通过找人谈谈来解决的问题？

这项工作真的解决了问题吗？

这个方案行得通吗？用户能做到他们需要做的、期望做的事情吗？有没有错误或笔误？有没有 bug 或性能问题？设计中是否打算以一种行不通的方式来使用某个系统？

它将如何处理失败？

这个方案将如何处理奇怪的边界情况、格式错误的输入、网络突然消失、负载激增，或者其他任何可能出错的情况？它会干净利落地失败，还是会损坏数据，或者收了用户的钱却不提供他们付费购买的服务？你们将如何发现问题？

它好理解吗？

其他人能维护和调试新的代码或系统吗？组件或变量的命名直观吗？复杂性是否被控制在一个选得恰当的地方？

它符合全局吗？

这个变更是否开了一个你不希望别人效仿的先例，或者形成了一个你不希望别人照搬的模式？它是否会迫使其他团队在未来的变更中做额外的工作？这是不是一个被安排在某次备受瞩目的发布同期进行的高风险变更？

合适的人知道这件事吗？

该知会的人是否都已被抄送了这个变更？每一项需要执行的行动是否都写明了负责人，还是充斥着被动语态，看不清哪个团队在做什么？相关人员是否清楚对他们的期望？

作为评审者，要承认自己并非无所不知。多提问，并保持建设性。好的护栏不是武断的看门人：你和你要保护的人站在同一边，你希望他们成功。

项目护栏

如果你曾经努力挑战过一个困难的项目，你就会知道这是锻炼技能的好方法，但也让人提心吊胆！你更有可能失败，因为你在做一件对你来说很难的事。所以，如果有一位做过类似规模或类型项目的更有经验的同事，那就太好了：他们可以帮助你保持安全。这并不意味着他们会替你做事，或者保护你免于犯下所有可能的错误，但如果你正在接近一场无法挽回的灾难，他们会提醒你。这就是充当项目护栏的含义。

我记得自己曾经领导过一个对我来说确实很有挑战的项目。它的组成部分比我以前做过的任何项目都多，利益相关者更多，政治因素更是多得多。每周我和我的团队负责人见面时，他都会问一些关于项目的问题：“只是好奇问一下，你打算怎么平衡这两个相互冲突的业务优先级？”当然，我并没有计划：我根本没注意到这个问题正在悄悄逼近。但这些问题足以让我回到正轨，我也能够提出前进的路径。虽然当时我没有意识到，但这位团队负责人就是在充当护栏。他在确保我注意到自己正走在悬崖边上，而如果我对该怎么做没有好主意，他随时准备辅导我。

充当项目护栏并不只是为了经验较少的人：任何正在领导项目或承担困难任务的同事，你都可以为其扮演这个角色。即使是经验非常丰富的人，在一个需要运用新技能的项目中也可能需要支持。如果有人请你担任某个项目的导师或顾问，他们多半是希望你至少能起到一点保护作用。

护栏既能提供安全，也能提供支持。Lara Hogan 建议具体说明你能如何帮助这个项目，比如承诺评审设计或者在高层管理者面前为某些想法争取支持，同时明确说明同事应该在什么时候、以什么方式向你求助。她建议使用这样的话：“如果 B 三天都不回复你，给我发封邮件；在这件事上我可以帮你撑腰。”

把护栏扩展到群体

你不可能亲自评审每一个变更、支持每一个项目，如果你试图这么做，只会拖慢所有人。我们来看看如何在不妨碍大家的情况下，为团队或组织加上护栏。

流程

与其逐个教同事什么才是正确的做法，不如写下一套标准步骤，并说服组织去遵循它们。比如，在你们公司，发布一项新功能的“正确方式”是什么？你们的发布前流程可能包括回答这样一些问题：

我们需要安全审批吗？
应该提前多久通知市场团队或客户支持？
应该放在功能开关后面发布吗？
有没有我们应该加上的标准监控、事件埋点和文档？
我们需要告诉其他团队准备好承受额外负载吗？

还有很多很多！随着公司壮大、组织变得更加复杂，一次发布引发故障或公关危机的途径也会越来越多。于是，流程就诞生了。

人们对流程的看法各不相同。有些人会很高兴有清晰的步骤，以及标准化带来的安全感。另一些人则会坚持认为，人们应该动脑思考，而不是盲目地遵循规程，清单和审批只会拖慢他们。没有人是错的；这是一种权衡。但公司越大，你就越可能需要某种结构，帮助人们做正确的事，而不必每次都问同样的问题。

下面是另外一些加入流程或检查清单可能有帮助的例子：

应对重大故障或安全事件
分享 RFC 或设计并就其达成一致
采用一项新技术或新语言
做出并记录跨多个组织的决策

一般来说，要让流程尽可能轻量。如果你加入一个复杂的程序，有大量模板化内容、集中审批和漫长的等待期，它就不会是一道好护栏：人们只会想方设法绕过它。要让正确的方式成为容易的方式。

流程前言

下面是我在工作中为一份流程 FAQ 文档写的引言。如果对你也有帮助，请随意使用。

关于 <主题> 应该如何运作，有很多疑问。对于这类流程，要把握规定到什么程度很难找到平衡。

如果什么都不写下来，大多数人会讨厌这样，抱怨不知道该怎么做任何事。
如果写下指导原则，人们会把它们当作法律来解读，并争辩说它们是错的，因为它们没有覆盖边界情况。
而如果把每一种边界情况都写下来，最后就会得到一本三环活页夹装订的政策和法律条文，而它很可能仍然覆盖不了所有情况。而且大家仍然讨厌它！

本文档试图为一些常见问题给出大体正确的答案。这些答案不会完美适用于每一种情况。在抛弃它们之前请三思，但如果它们对你所处的情况不合理，那就去做合理的事。所有的指导原则都有出错的时候。（如果这些指导原则经常出错，请提出修改。）

拿不准的时候，认真考虑一下你所做的事情中涉及的其他人，假设他们是在尽力而为的通情达理的人，同时你自己也要做一个尽力而为的通情达理的人。⁹

成文的决策

还有一种让做正确的事变得更容易的方法：一次性做出决策并把它写下来，这样人们就不必一遍又一遍地进行同样的争论。成文的决策可以为人们减轻一点决策疲劳：规则说我们通常做 X，那我们就做 X！

下面是四个例子：

风格指南正如 Google 的风格指南网站所解释的，一个项目的风格指南是“关于如何为该项目编写代码的一套约定（有时是武断的）。

当一个大型代码库中的所有代码都保持一致的风格时，理解它就会容易得多。”这里的风格一词涵盖的范围很广，从命名约定到错误处理，再到哪些语言特性可以使用。通过一次性做出决策并写下来，你可以让团队不必在每个新项目中都重复“变量名用小驼峰还是蛇形命名？”这样的争论。你也会得到风格更一致的代码。

铺好的路有些公司会把自己那套标准的、得到良好支持的技术写成文档，并建议（或强制要求）团队不要偏离这条“铺好的路”。我喜欢 Thoughtworks 技术雷达推广的那种格式，把技术标记为“采用”（Adopt）、“试用”（Trial）、“评估”（Assess）和“暂缓”（Hold）。

政策公司可以制定规则，例如“每个团队都应该在故障之后进行复盘”。如果这条规则被强制执行，违反它就可能被视为没有尽到职责，从而影响绩效评估。要谨慎使用政策。很难把所有的边界情况都考虑到——而边界情况总是会有的。此外，如果政策太多，人们根本记不住自己应该做的所有事情。

技术愿景和战略技术愿景或战略（见第 3 章）给出了一个清晰的方向，团队可以在这个方向内选择自己解决问题的路径。

机器人与提醒

软件顾问 Glen Mailer 说，他会想方设法让人们尽可能容易地记住去做正确的事。这意味着要把正确的解决方案摆在他们眼前——有时是字面意义上的！他举了一个例子：在某个工作场所，每个人都应该用工时表记录自己在项目上花的时间。当然，大家经常忘记，直到有人想出了一个解决办法：他们把一张工时表格和一支笔贴在出口门上与头部齐平的位置。任何人推门离开时，工时表都会出现在眼前——这就很难忘记了。

如果你正在尝试引入一个流程或一项成文的决策，看看有没有办法（温和地）把它摆到人们眼前。更好的办法是，让自动化系统去做正确的事，这样人就不必操心了。一些例子：

自动提醒与其总是提醒某人这周轮到他们执行发布流程，不如设置自动化，把这件事加到他们的日历里，或者私信提醒他们。提醒中应该附上流程的链接。

Linter 让代码 linter 尽可能多地强制执行你们的风格指南，这样评审者就不必操心了。

搜索确保任何关于如何做某件事的搜索都能找到正确的做法，哪怕这意味着要给所有“错误”的文档都加上指向正确位置的标题。

模板如果所有 RFC 都应该有安全一节，就确保有一个好用的 RFC 模板，并且其中包含安全一节。

配置检查器与提交前检查你能否加入自动化，自动运行单元测试，或者在提交配置之前对其进行安全检查？Google 的数据中心安全系统 SRSly 就是一个很好的例子：它允许设置这样的护栏，比如“一次重启的服务器不得超过 5%”，以及“如果该系统的值班人员最近收到过告警，就不要下线这个系统的服务器”。¹⁰

成为催化剂

创建能强化你所传达信息的机器人、政策和流程，比为单个同事充当护栏的扩展性更强。但它们仍然都依赖于你去做些什么。如果你真想让一条信息深入人心，就需要每个人都相信它、在乎它。你希望组织达到这样一种状态：做别的事情反而会被认为很奇怪。最有效的护栏也是最难建立的：文化变革。除非你能让护栏成为文化的一部分，否则你将永远在追着别人去合规。

如今大多数科技公司都有代码评审，也都会写测试。但情况并非一直如此！我们今天视为理所当然的所有护栏，都是由那些足够在乎、愿意去论证这一变革值得投入时间的人引入的。如果你正在推动一项文化变革，要有耐心。让每个人都以不同的方式行事需要大量时间和持续的努力，但这是你唯一能够不再需要手动推动流程的方式。

下面是一些让文化变革之路更顺畅的方法：

解决真正的问题

文化变革应该与组织的需求紧密契合。预料到任何提议都会遭遇大量“为什么”的质疑。准备好不只是停留在愿景层面的好答案：说真的，业务能从中得到什么？

有所取舍

与其制定一套设计评审流程，不如努力培养大家对设计评审的重视，并相信各团队会自行选择适合自己的形式。提供一些简单的默认做法，但不要纠结于是否每个人都在遵循完全相同的流程。

提供支持

你的流程和自动化应该为你想要的变革提供支持：它们应该让做正确的事变得容易。

寻找盟友

不要试图单枪匹马地改变文化。理想情况下，你的盟友应该包括你想要改变的那个组织中的高层支持者和有影响力的人。参考一下你在第 2 章中绘制的影子组织架构图。

机会

我们要看的最后一种良好影响力，是为人们找到他们成长所需的经历。人们通过动手做来学习，这甚至比通过教学、辅导或建议学到的更多。每一个项目或角色，都是一次获得曝光、建立人脉、丰富简历的机会，而这一切又都能带来更多的机会。我们来看看如何把这些经历带给你的同事，既包括个人层面，也包括规模化的方式。

个人层面的机会

作为资深人士，你会有很多机会帮助别人找到成长的机会。你可以通过委派直接提供项目和学习经历。但你也可以推荐人去承担任务、宣传他们的工作，或者把对他们有帮助的信息介绍给他们。

委派

委派意味着把你的一部分工作交给别人。当你委派时，你通常不只是把项目丢给某人就一走了之：你在乎结果。这可能会让你忍不住想要微观管理，或者亲自处理项目中所有困难的部分。但当你把工作交出去时，就要真正交出去。正如 Lara Hogan 所说，如果你只在把工作变成“包装精美、整整齐齐的礼物”之后才委派出去，你的同事就学不到那么多东西。如果你交给他们的是“一个混乱的、没有明确范围的项目，外加一点安全网”，他们就有机会磨炼解决问题的能力，建立自己的支持体系，拓展自己的技能。一个混乱的项目，是一种在其他情况下很难得到的学习机会。

根据你要委派的人来设定难度——不要把组织层面的混乱丢给一个应届毕业生！但在寻找委派对象时，要把目光放到最显而易见的人选之外。任何能在一个项目上做到 A+ 满分的人，都不会从中学到什么。¹¹ 相反，试着找一个会觉得这项工作有点挑战、但在支持下能够胜任的人。向他们承诺这种支持。你可能需要稍微推他们一把，帮他们看到这项工作是他们力所能及的：他们可能还没有把自己视为项目负责人、事故指挥官等等，但你这样看待他们这一事实，就能极大地增强他们的信心。描述你能为他们提供的护栏，并解释你为什么认为他们能够胜任这个项目。

要注意，当你委派时，你不会得到一个克隆体。（抱歉，我们还没有这种技术。）你委派的人不可避免地会采取一种与你不同的方式。充当护栏，辅导他们，向他们提问，但要抑制住插手的冲动。只要他们能达成目标，就让他们按自己的方式去做。我非常喜欢 Molly Graham（最近一份工作是 Quip 的首席运营官）对交接工作的描述——“把你的乐高送出去”：

人们自然会有很多焦虑和不安：担心新来的人不会以正确的方式搭建你的乐高塔，担心他们会拿走所有有趣的或重要的乐高积木，或者担心如果他们接手了你正在搭建的那部分乐高塔，你就没有乐高可玩了。但在一家处于规模扩张期的公司里，把责任交出去——把你开始搭建的那部分乐高塔交出去——是你继续前进、去搭建更大更好的东西的唯一途径。

在交出乐高的过程中，有一个需要留意的关键行为：你应该把关于项目的问题转给对方，而不是代为传递信息。也就是说：当有人问你关于项目的问题时，你可能以为自己掌握着最新的情况。但回答这个问题会让你成为联系人，可能会削弱你把项目交接给的那位同事的地位。你的答案也可能是错的！相反，要让接手项目的人被看见：说明他们才是这个主题的专家和负责人，表明你信任他们来做决策。这样你就为项目负责人牵上了一个新的人脉，以及由此带来的任何额外机会。下次那位感兴趣的人再有关于项目的问题时，他们就知道该去找谁了。而这个项目也就从你的盘子里拿走了。

举荐

举荐是利用你有影响力的地位为别人争取机会。它比指导更主动：你是在有意识地为别人打开机会，而不只是给他们建议。它也需要更多的投入：如果你想成为一个出色的举荐人，就需要了解你的同事能从什么中受益，以及他们在寻找什么样的机会。你是在用自己的时间和社会资本投资他们的成长。

卡内基梅隆大学组织行为与理论副教授 Rosalind Chow 描述了她所说的“举荐的 ABCD”：

放大（Amplifying）

宣传同事的出色工作，确保其他人知道他们的成就

助推（Boosting）

推荐他们去获得机会，为他们的技能背书

连接（Connecting）

把他们带入人脉网络，让他们接触到原本无法结识的人

维护（Defending）

在他们受到不公正的批评时挺身而出；扭转别人对他们的负面看法

你通过举荐所能提供的机会也许看起来很小，但它们会通向更大的事情。如果你推荐某人去领导一个小项目，你就是在为他们日后被看见、被选去领导更大的项目铺路。每当你点名表扬某人、评论他们的工作，甚至转发他们的推文，你都是在放大他们出色工作的信号，确保你人脉网络中的其他人知道他们，并在机会出现时想到他们。如果另一个团队里有人表现得非常出色，确保他们的老板知道。如果你所在的公司会写同侪评审，那么评审就是让出色工作被记录在案的好办法。

你应该举荐谁？寻找那些渴望成长机会、并且你相信能做好工作的人。推荐他们是在花费你的社会资本，所以不要把机会送给那些其实并不想要、或者不愿付出努力的人，白白浪费掉。举荐那些尚有未开发潜力、值得投资的同事。不过，要警惕内群体偏袒，这是一种认知偏差，会让你对与自己相似的人评价更高。用 Lotus 创始人、电子前哨基金会（Electronic Frontier Foundation）联合创始人、Kapor 社会影响力中心联合主席 Mitch Kapor 的话说：“我们谈论硅谷的精英制度（meritocracy），但实际上它是一种‘镜像制度’（mirrortocracy），因为与其他行业相比，这里的人更倾向于雇用和自己长得像的人。”留意你在推荐或帮助的是谁，确保你没有在无意中只举荐和你相像的人。这种事出奇地容易发生。

为人牵线

即使某个角色或项目不归你委派，也没有人请你做推荐，你仍然可以仅仅因为知道这些机会的存在而为别人提供机会。作为 Staff+ 工程师，你可能比与你共事的其他工程师拥有更广的上下文：正如我在第 2 章中所描述的，你会花更多时间去单纯地了解情况。留意那些能帮助同事的机会。你可能会记得某个会议正在征集演讲稿，某个技术负责人的职位即将空出来，或者某个新的内部培训计划正好提供某人想学的技能。通过把人和信息连接起来，你扩展了他们的选择。

把机会扩展到群体

我已经介绍过的一些催化类影响力，能给人们带来曝光，以及学习领导力和教学技能的机会。但还有一种扩展机会的方法：分享舞台。

分享聚光灯

作为团队或项目中最资深的人，会有很多事情是你做得最好的。这可能会让你忍不住想要扑向每一个难题。但是，虽然每天都当那个足智多谋、知识渊博、带领团队走向卓越的资深人士感觉可能很棒，你实际上却是在掩盖团队其他成员的光芒，阻碍他们成长。

相反，要把你的超级明星光环转化为帮助每个人把工作做得更好。让别人去做那些做得不如你好的工作，只要它足够好就行。他们就是这样学习的。分享舞台包括委派，但也可以意味着腾出空间：让别人注意到有工作需要做，这样他们就可以通过接手这些工作或学会自己委派来培养领导技能。

下面是一些确保你在分享聚光灯的方法：

如果有人在小组会议上提问，留出空隙，或者明确地把发言权交给你团队里的另一个人。
带一位资历较浅的同事参加你去的会议，让他们讲讲自己的工作。
邀请一位资历较浅的同事评审与其工作相关的设计或代码，并明确表示他们的意见很重要。

到了某个时候，你可能会看着那些正在做你过去所做工作的人，意识到自己已经上了一个台阶。那时你该做什么？在第 9 章中，我们会看看接下来做什么。

本章回顾

你可以通过提供建议、教学、护栏或机会来帮助同事。了解在具体情况下什么最有帮助。
想一想你是想一对一地帮助别人、提升团队水平，还是施加更广泛的影响。
分享你的经验和建议，但要确保它们受欢迎。写作和公开演讲可以让你的信息传得更远。
通过结对、跟岗、评审和辅导来教学。讲授课程或编写 codelab 可以扩展你投入教学的时间的效果。
护栏可以让人们自主地工作。为同事提供评审，或者充当他们的项目护栏。通过流程、自动化和文化变革把护栏固化下来。
机会可能比建议有价值得多。想一想你在举荐谁、委派给谁。在团队中分享聚光灯。
计划好把你的工作交出去。

“小心，你身后有头熊”也是可以接受的未经征求的建议。 ↩
不过，不要点名或羞辱你认为需要建议的那个人。 ↩
Resilient Management（A Book Apart） ↩
2014 年。那是个好年份。 ↩
X 没有 Y 就无法启动，Y 没有 X 也无法启动，所以两者都启动不了。 ↩
我有时会在变更描述中注明上下文，来给评审者定个基调。例如：“我刚接触这门语言，所以如果有什么看起来很奇怪，那多半不是刻意的风格选择！欢迎吹毛求疵，也欢迎告诉我什么才是地道的写法。” ↩
我生活的一个小小缩影。:laughing: ↩
Kotlin Koans 就是一个很好的例子，做起来也很有意思。Google 也有大量很棒的 codelab。 ↩
这通常也是不错的人生建议。 ↩
去看看 Christina Schulman 和 Etienne Perot 关于 SRSly 的精彩演讲，其中包括它的起源故事：自动化系统意外地把一个数据中心里的所有磁盘同时送去擦除。正如他们所说，如果你让高效的自动化去做一件蠢事，它也会非常高效地把它做完。 ↩
这种模式在招聘邮件中很常见：“来做和你现在一模一样的事，只不过换一家公司。”有时这也行得通（我们会在第 9 章探讨换工作的动机），但我见过的最成功的招聘，都是那些能让人更上一层楼、有点令人害怕的职位。 ↩

	个人	群体	催化
建议	指导、分享知识、反馈	技术分享、文档、文章	导师计划、技术分享活动
教学	代码评审、设计评审、辅导、结对、跟岗	课程、codelab	入职课程体系、教别人如何教学
护栏	代码评审、变更评审、设计评审	流程、linter、风格指南	框架、文化变革
机会	委派、举荐、加油打气、持续支持	分享聚光灯、为团队赋能	营造机会文化、自豪地看着你那些出类拔萃的初级同事改变世界

Keyboard shortcuts

The Staff Engineer's Path（中文版）