在谷歌 14 年的 14 个额外经验教训
内容
一段时间前，我写下了 21 条来自我在 Google 时的经验。我对这些经验的反响感到意外，因为人们关注的并不是我预期的内容。人们关注的不是技术方面的建议，而是关于人、决策以及团队合作的复杂现实。
这让我意识到，我之前的经验还不够全面。第一份经验列表更侧重于个人技能——如何写更好的代码，如何思考你的职业生涯。但是我学到的最难的经验并不是关于如何工作，而是关于团队如何工作：决策如何真正做出，协调在哪里破裂，什么区分了那些能够交付成果的团队和那些陷入困境的团队。
这些经验从第一份列表的基础上继续发展。它们不再仅仅关注如何成为一个更好的个人工程师，而是更侧重于工程师周围的系统。
1. 最好的工程师选择合适的问题来解决。
每一个“是”的回答意味着对其他事情的“否”。
我曾经看到有才华的工程师因为答应了所有事情——每一个 bug，每一个功能请求，每一个“快速帮忙”——而导致精疲力竭。他们的日程表被他人的优先事项填满了，他们自己的路线图变成了一个半成品想法的墓地。
有时候，这只是因为他们真正关心产品。保护你的带宽不被“好奇心”占据，就像保护生产环境不被宕机一样。正确的做法是做正确的事情，并让错误的事情保持未完成。
产生不成比例影响的工程师不一定更快或更聪明。他们只是更无情地决定哪些事情值得他们的关注。他们已经学会了，处理错误事情的机会成本就是处理错误的事情。
2. 如果你不能说明你在会议中请求什么，你就还没有准备好开会。
大多数会议失败的原因不是因为它们不必要，而是因为它们被伪装成日记。 我曾经花了数百个小时听聪明的人在没有明确说明他们需要什么的情况下讨论问题。会议结束时，只有情绪，没有所有者。
我学会了从请求开始：批准、选择、解除阻塞或通知。
仅仅这四个词就改变了我为每次会议做准备的方式。如果我不能选择其中一个，我就还没有准备好占用别人的时间。当我处于接收端时，我开始在前两分钟内问“您需要我做出什么决定？”这听起来很直接，但人们通常都很松了一口气——他们经常没有意识到自己没有定义它。
模糊会议的隐性成本不仅仅是浪费的一个小时，还有随之而来的整整一周的漂泊，大家都在等待永远不会到来的明确指示。
3. “我们应该”不是一个计划。“在星期二，我会”才是一个计划。
动作和进步之间的区别在于具体性。
团队在意图中溺亡。我曾经看到路线图中充满了“我们应该改进入门流程”和“我们应该减少延迟”和“我们应该记录 API”。几个月后，相同的项目仍然存在，积累着灰尘和内疚。你可能认为这已经是一个解决方案，尤其是现在我们有了 代理工程，但事实并非如此。
将讨论转化为某个人可以实际执行的最小下一步行动，然后为其指定一个名称和日期。不是“我们应该改进入门流程”，而是“在星期二，莎拉将运行三个用户会话并记录顶级摩擦点”。
这关乎尊重人类需要牵引力来取得进步。模糊的意图会产生焦虑。具体的承诺会产生动力。计划不需要完美——它只需要具体到某个人可以开始执行。
4. 慢速代码有时是症状。慢速决策永远是一个问题。
速度是关于消除使聪明人犹豫的摩擦。“偏向行动”是你可以做到的。
当项目拖延时，人们的直觉是责怪速度：人们没有努力工作，代码库很混乱，没有足够的工程师。但在我的经验中，慢速代码往往是症状。慢速决策才是疾病。
如果决策通常需要数周或数月，请深入调查。缺乏背景信息意味着人们无法评估权衡。所有权不明确意味着每个人都在等待其他人做决定。害怕承担责任意味着人们会犹豫而不是承诺。
我合作过的最快的工程团队并不是拥有最好的程序员的团队，而是决策可以在数小时内做出而不是数周的团队，因为权威明确，背景信息共享，犯错也不是职业风险。
5. 可靠性是产品功能。将其视为产品功能。
用户不会赞扬可靠性，但他们会注意到其缺席。
这造成了一个危险的动态：可靠性工作是隐形的，直到它失败，这意味着它在资源分配上总是低于闪亮的新功能。
错误预算是使权衡显式化的一种方法。如果您的服务有 99.9% 的正常运行时间 SLA，您有 0.1% 的停机时间“预算”来用于创新。如果您用完了它，您就会专注于可靠性，直到您赚回了它。这是一个进行关于风险的诚实对话的框架。
同时保持速度和可靠性的团队并不通过英勇行为来实现。他们通过将可靠性视为具有自己的路线图、自己的指标和自己的倡导者的第一类产品功能来实现。
你不会在没有产品审查的情况下发布功能。不要在没有可靠性讨论的情况下发布系统。
6. 你不能通过“沟通”来摆脱团队之间的糟糕接口。
团队交互模式存在的原因是协作（紧密合作）、服务（清晰的 API 和 SLA）或促进（一个团队帮助另一个团队建立能力）。
大多数跨团队的痛苦并不是关于努力或良好的意图。它是关于不明确的边界和混乱的合同。我曾经看到团队通过增加更多会议、更多的 Slack 频道、更多的同步来“改善沟通”，但这并没有让事情变得更好。
问题不是人们不说话。问题是团队之间的接口没有定义。谁拥有什么？什么是合同？团队 A 可以依赖团队 B 做什么，反之亦然？
有意选择，你将需要更少的会议来使事情运作。试图用沟通来掩盖糟糕的接口，你将会让你最具协作精神的人精疲力竭，而潜在的功能失常仍然存在。
7. 最好的升级伴随着一个提议。
“这里有一个问题”只是完成了一半的工作。我曾经认为我的角色是识别问题并将其带给领导。这是必要的，但不够。
“这里有两个选项、权衡和我推荐的内容”是如何解除阻塞并赢得信任的。它表明你已经做了思考。它为决策者提供了一个非常具体的东西来做出反应，而不是一个开放式的问题来解决。
这使得他们的工作更容易，这使得他们更有可能给你你需要的东西。
“我需要帮助”和“我需要你在 A 和 B 之间做出选择，并且我倾向于 B”的区别在于，前者是问题发现者，后者是问题解决者。
两者都能识别问题。只有后者才能赢得越来越多的信任和自主权。
8. 避免英雄文化。建立不需要英雄的系统。
英雄是精疲力竭的、没有文档的，并且是单点故障。
如果一个人拯救世界的模式经常出现，那是一个故障模式，而不是荣誉徽章。我曾经看到团队庆祝他们的英雄，同时忽略了使英雄主义必要的功能失常。
当他们离开时——他们最终会离开——团队发现没有人真正知道事情是如何运作的。对英雄主义的庆祝掩盖了一个系统问题：正常人在正常日子里的路径不起作用。
使正常路径成为默认路径。记录系统。分享知识。为平均星期二设计，而不是异常危机。英雄应该是多余的，如果他们是必要的，你应该努力使他们变得多余。
9. 将可观察性作为功能的一部分。
没有遥测的功能是伪装的责任。
如果你在不知道它在生产环境中如何表现的情况下发布功能，你发布的是不确定性。
我曾经看到团队庆祝发布，只是几周后才发现他们的功能对 20% 的用户悄悄失败。他们没有日志、没有指标、没有仪表盘，但应该有理解的地方却有一个空白。这可能会在你想要修复它时造成各种各样的痛苦，包括取消发布，只是为了正确地进行带有可观察性的 A/B 测试。
日志、跟踪、仪表盘和警报不是“运维工作”。它们是你学习的方式。它们是你知道自己构建的东西是否真正为真实用户在真实条件下工作的方式。
我认识的最好的工程师将可观察性视为完成定义的一部分。不是“我写了代码”，而是“我写了代码，我可以看到它工作”。
10. 小型 PR 是仁慈。尤其是如果 PR 是由 AI 生成的。
小变化更容易审查、更容易推理，也更容易回滚。
我曾经写过大型拉取请求。我喜欢这样一个想法：一个完整的功能可以一次性进行审查。我是在优化自己的便利性，而不是审查者的理智。小型 PR 通常对每个人都更好。
它们可以更快地发布，因为它们不会在审查队列中等待某人花一个小时来理解你的千行差异。如果你想让队友相信你的速度，请让你的工作可以审查。
隐藏的好处是，小型 PR 会迫使你逐步思考。不是一次性完成一个巨大的变化，而是逐步建立能力。每一步都会得到反馈。每一步都可以独立回滚。这可能会使每个 PR 的速度变慢，但实际上会更快地进入生产。
11. 当你添加一个团队时，你添加的是边缘，而不是节点。
协调成本的增长速度快于员工人数的增长。
这就是为什么“只要向问题扔更多人”通常会失败的原因，也是为什么在项目后期添加人员会使其变得更晚的原因。每个新人都会在他们需要协调的每个人身上增加沟通负担。图变得更加密集，而不是更大。
我曾经看到经理们真正感到困惑，当团队规模增加一倍，但产出几乎没有变化。答案总是相同的：新边缘吞噬了新容量。更多的人意味着更多的对齐会议、更多的上下文共享、更多的等待决策，这些决策现在需要更多的利益相关者。
解决方案不是停止招聘。它是有意减少边缘。明确所有权。自主团队具有最小的依赖关系。接口允许人们并行工作，而不是同步工作。最好的组织不是拥有最多人的组织，而是拥有每人最大的杠杆作用的组织。
12. 迁移永远不仅仅是迁移
每次迁移都是系统之间、你想要的系统和没有要求的系统之间的谈判。
我曾经看到估计为一个季度的迁移项目延伸到数年。不是因为技术工作是错误的，而是因为没有人考虑到人为因素：说服团队将你的迁移置于他们的路线图之上，支持长尾部的边缘情况，没有人知道存在，维护两个系统同时运行，而旧系统拒绝消亡。
技术计划是容易的部分。难的部分是设计共存。你将比你想象的更长时间地同时运行旧系统和新系统。你将发现“遗留”系统编码了没有人记录的决策和没有人记得设计但每个人都依赖的工作流。你将需要一个采用策略，不需要每个团队同时放弃他们正在做的事情。
实际完成的迁移具有三个共同特征：一个在启动后仍然保持参与的赞助商，真正拥有迁移的团队，而不是将其视为副任务，以及一个清晰的弃用日期，人们相信这是真实的。没有所有这些，你将得到一个永远“几乎完成”的迁移——这比不开始更糟糕，因为现在你将无限期地支付两个系统的成本。
如果你不愿意为完成迁移提供资金，就不要开始迁移。
13. AI 使草稿变得廉价。品味变得昂贵。
每个人现在都可以生成代码。产生代码、内容、设计的障碍——它基本上正在消失。AI 将在以前写一个版本所需的时间内为你生成任何内容的十个版本。
区分者是选择：什么要构建，什么要删除，什么要简化，什么不发布，以及什么是“好”的。品味——区分选项并选择正确的一个的能力——变得稀缺的资源。
使用 AI 快速探索选项，然后无情地应用判断力。在这个环境中茁壮成长的工程师不会是生成最多内容的人，而是策划最好的内容的人。
生产是廉价的。编辑是昂贵的。选择是一切。
14. 信任是团队的延迟优化。
这是你可以建立的最高杠杆的事情。不是一个系统，而是可信度。
当人们信任你时，他们不需要五次会议来批准一个决定。他们假设有能力、良好的意图和后续跟进。那些在低信任环境中需要数周的决定，在高信任环境中可以在数小时内做出。
每次你兑现承诺，每次你对错误坦诚，每次你让某人的生活更容易，你都会在一个将在未来几年内带来回报的账户中存入资金。
我曾经看到技术能力一般的工程师取得了巨大的成就，因为每个人都信任他们。我也看到非常优秀的工程师几乎没有成就，因为没有人会接听他们的电话。
代码不重要，如果你无法让任何人与你一起发布它。
最后的思考
第一次，我说这些经验归结为保持好奇、保持谦逊和记住工作是关于人的事实。我仍然相信这一点。
但是，如果这第二份列表有一个共同点，那就是更具体的东西：工作是关于让正常人在正常日子里做出非凡的事情变得更容易。工程师的职业生涯给了你足够的时间来学习这些东西的艰难方式，我在 Google 的时间里也学到了很多。
我希望其中一些经验能让你少走一些弯路。如果它们做到了，请与旅程早期的人分享你所学到的东西。
这就是好的经验如何传播的。