这两天看到一篇由 Google Cloud AI主管Addy Osmani写的一篇博文21 Lessons From 14 Years at Google，引起了我的共鸣，翻译转载一份到我博客分享给大家，以下是翻译后的内容。
当我大约14年前加入谷歌时，我以为这份工作就是写出优秀的代码。我只说对了一半。但待得越久，我越意识到那些真正成功的工程师未必是最佳程序员——他们是那些学会了如何驾驭代码之外一切的人：人际关系、办公室政治、目标对齐与协调、模糊性。
这些是我希望自己早点知道的教训。有些本可以让我免去数月的挫败感。另一些则花了数年才完全理解。它们与具体技术无关——技术变化太快，无关紧要。它们关乎那些不断重现的模式，项目复项目，团队复团队。
我分享这些，是因为我曾从那些同样为我付出的工程师那里获益匪浅。这算是我试图将这份善意传递下去。
-
最优秀的工程师痴迷于解决用户问题
爱上某项技术并寻找应用场景很诱人。我做过。每个人都做过。但创造最大价值的工程师反其道而行：他们痴迷于深入理解用户问题，并让解决方案从这种理解中浮现。痴迷于用户意味着花时间看支持工单、与用户交谈、观察用户挣扎、不断问"为什么"直到触及根本。真正理解问题的工程师常常发现，优雅的解决方案比任何人预期的都要简单。
从解决方案出发的工程师，往往为了证明其合理性而构建复杂性。
-
正确是廉价的。共同达成正确才是真正的工作
你可以赢得每一场技术争论却输掉整个项目。我见过才华横溢的工程师因总是成为房间里最聪明的人而积累无声的怨恨。代价后来以"神秘的执行问题"和"奇怪的阻力"显现。真正的技能不是正确。而是进入讨论以达成共识、为他人创造空间，并对自己的确定性保持怀疑。
坚持己见，但保持开放——不是因为你缺乏信念，而是因为不确定性下做出的决定不应与身份绑定。
-
偏向行动。发布。你可以编辑糟糕的页面，但无法编辑空白的页面
追求完美会让人瘫痪。我见过工程师花数周时间争论他们从未构建过的东西的理想架构。完美的解决方案很少仅从思考中浮现——它从与现实的接触中浮现。人工智能在很多方面可以在这里提供帮助。先做出来，然后做对，然后做得更好。把丑陋的原型拿给用户看。写下设计文档的混乱初稿。发布让你略感尴尬的最小可行产品。从一周的真实反馈中学到的，比一个月的理论辩论更多。
动力创造清晰。分析瘫痪创造虚无。
-
清晰是资深。巧妙是开销
写巧妙代码的本能几乎普遍存在于工程师中。它感觉像是能力的证明。但软件工程发生在你加入时间和其他程序员时。在那样的环境中，清晰不是风格偏好——它是降低运营风险。
你的代码是写给陌生人看的战略备忘录，他们将在凌晨2点的故障期间维护它。为他们理解优化，而非为你的优雅优化。我最尊敬的资深工程师学会了每次都拿巧妙换取清晰。
-
新颖性是贷款，你将在故障、招聘和认知开销中偿还
把你的技术选择想象成一个只有少量"创新代币"预算的组织。每次采用本质上非标准的东西时花掉一枚。你负担不起太多。关键不是"永不创新"。而是"只在你有独特回报的地方创新"。其他一切都应默认选择无聊，因为无聊有已知的失败模式。
"最适合工作的工具"常常是"许多工作中最不差的工具"——因为管理一个动物园才是真正的成本。
-
你的代码不会为你辩护。人会
职业生涯早期，我相信优秀的工作会为自己说话。我错了。代码静静地躺在仓库里。你的经理在会议上提到你，或者不。同事推荐你参与项目，或者推荐别人。在大型组织中，决策在你未被邀请的会议上做出，使用你未写的摘要，由那些只有五分钟和十二个优先事项的人做出。如果没人在你不在场时能清晰表达你的影响力，那么你的影响力实际上可有可无。
这不完全是自我推销。而是关于让价值链对每个人——包括你自己——清晰可见。
-
最好的代码是你永远不必写的代码
我们在工程文化中庆祝创造。没人因为删除代码而获得晋升，尽管删除往往比添加更能改进系统。你不写的每一行代码都是你永远不必调试、维护或解释的一行代码。在构建之前，穷尽这个问题："如果我们只是……不做会怎样？"有时答案是"没什么坏事"，那就是你的解决方案。
问题不在于工程师不会写代码或用AI写代码。而是我们太擅长写代码，以至于忘了问我们是否应该写。
-
在规模下，甚至你的错误也有用户
有足够多的用户时，每个可观察的行为都会成为依赖——无论你承诺了什么。有人在抓取你的API，自动化你的怪癖，缓存你的错误。这带来了一个职业生涯层面的洞见：你不能把兼容性工作当作"维护"，把新功能当作"真正的工作"。兼容性就是产品。
将你的废弃设计成有时间、工具和同理心的迁移。大多数"API设计"实际上是"API退役"。
-
大多数"慢"团队实际上是缺乏对齐的团队
当项目拖延时，本能是责怪执行：人们不够努力，技术错了，工程师不够。通常这些都不是真正的问题。在大公司中，团队是你的并发单位，但随着团队增多，协调成本呈几何级数增长。大多数缓慢实际上源于缺乏对齐——人们在构建错误的东西，或以不兼容的方式构建正确的东西。
资深工程师花更多时间澄清方向、接口和优先级，而不是"更快地写代码"，因为真正的瓶颈就在那里。
-
专注于你能控制的。忽略你不能控制的
在大公司中，无数变量超出你的控制——组织变化、管理决策、市场变化、产品转向。纠结于这些会产生无力感的焦虑。保持理智和高效的工程师专注于他们的影响圈。你无法控制重组是否发生。你可以控制工作质量、如何回应以及学到什么。面对不确定性时，将问题分解成块，并识别你可用的具体行动。
这不是被动接受，而是战略专注。花在你无法改变的事情上的能量，是从你能改变的事情上偷来的。
-
抽象不消除复杂性。它们将复杂性转移到你值班的那天
每个抽象都是在赌你不需要理解底层实现。有时你赢了这个赌注。但总有东西会泄漏，当它泄漏时，你需要知道你站在什么上面。资深工程师即使栈越来越高也继续学习"底层"东西。不是出于怀旧，而是出于对抽象失败时刻的尊重——凌晨3点你独自面对系统。使用你的栈。
但要对其底层失败模式保持工作模型。
-
写作迫使清晰。更好地学习某件事的最快方法是尝试教它
写作迫使清晰。当我向他人解释一个概念时——在文档、演讲、代码评审评论中，甚至只是与AI聊天——我发现自己理解中的空白。使某物对他人清晰的行为也使其对我更清晰。这并不意味着你将通过教它来学习如何成为外科医生，但这个前提在软件工程领域大体上仍然成立。
这不只是关于慷慨分享知识。这是一个自私的学习技巧。如果你认为自己理解某事，尝试简单地解释它。你磕磕绊绊的地方就是你理解肤浅的地方。
教学是调试你自己的心智模型。
-
使其他工作成为可能的工作是无价的——也是无形的
协调性工作——文档、入职、跨团队协调、流程改进——至关重要。但如果你无意识地做它，它会阻碍你的技术轨迹并让你精疲力尽。陷阱是把它当作"乐于助人"而不是将其视为有意的、有界的、可见的影响。给它设定时间盒。轮换它。将其转化为具体成果：文档、模板、自动化。并使其作为影响清晰可见，而不是作为人格特质。
无价且无形对你的职业生涯是危险的组合。
-
如果你赢得每场辩论，你可能在积累无声的阻力
我学会了怀疑自己的确定性。当我"赢"得太容易时，通常有什么不对劲。人们停止与你争论不是因为你说服了他们，而是因为他们放弃了尝试——他们会在执行中表达这种分歧，而不是在会议中。真正的对齐需要更长时间。你必须真正理解其他观点，纳入反馈，有时公开改变主意。
短期感觉正确的价值远低于与愿意合作的协作者长期构建的现实。
-
当衡量标准成为目标时，它就不再衡量
你向管理层公开的每个指标最终都会被操纵。不是出于恶意，而是因为人类会优化被衡量的东西。如果你跟踪代码行数，你会得到更多行。如果你跟踪速度，你会得到膨胀的估算。
资深做法：回应每个指标请求时提供一对。一个用于速度。一个用于质量或风险。然后坚持解释趋势，而不是崇拜阈值。目标是洞见，不是监视。
-
承认你不知道的比假装知道创造更多安全感
说"我不知道"的资深工程师不是在展示弱点——他们是在创造许可。当领导者承认不确定性时，它表明房间对其他人做同样的事是安全的。另一种选择是每个人都假装理解、问题隐藏直到爆炸的文化。我见过最资深的人从不承认困惑的团队，也目睹过其造成的损害。问题不被提出。假设不被挑战。初级工程师保持沉默，因为他们假设其他人都懂。
示范好奇心，你会得到一个真正学习的团队。
-
你的人脉网络比你将拥有的每份工作都持久
职业生涯早期，我专注于工作而忽视了人脉建设。事后看来，这是个错误。投资于关系——公司内外——的同事收获了数十年的好处。他们最先听到机会，能更快搭建桥梁，被推荐担任角色，并与多年来建立信任的人共同创立企业。
你的工作不是永远的，但你的人脉是。以好奇心和慷慨对待它，而不是交易性的心态。
当需要继续前进时，往往是关系打开大门。
-
大多数性能胜利来自移除工作，而不是添加巧妙性
当系统变慢时，本能是添加：缓存层、并行处理、更聪明的算法。有时这是对的。但我见过更多性能胜利来自问"我们在计算什么不需要的东西？"删除不必要的工作几乎总是比更快地完成必要工作更有影响力。最快的代码是永不运行的代码。
在优化之前，质疑工作是否应该存在。
-
流程存在是为了减少不确定性，而不是创造文书痕迹
最佳流程使协调更容易、失败成本更低。最差流程是官僚剧场——它存在不是为了帮助，而是为了在出错时分配责任。如果你无法解释一个流程如何降低风险或增加清晰度，它可能只是开销。
如果人们花在记录工作上的时间比做工作还多，那就出了大问题。
-
最终，时间变得比金钱更有价值。相应行动
职业生涯早期，你用时间换取金钱——这没问题。但在某个时刻，计算反转。你开始意识到时间是不可再生资源。我见过资深工程师为了追逐下一个晋升级别、优化几个百分点的薪酬而精疲力尽。有些人得到了。大多数人后来想知道，这是否值得他们放弃的东西。
答案不是"不要努力工作"。而是"知道你在交易什么，并有意地进行交易。"
-
没有捷径，但有复利
专业知识来自刻意练习——稍微超越当前技能、反思、重复。年复一年。没有浓缩版本。但这里有希望的部分：当学习创造新选项而不仅仅是积累新琐事时，它会复利。写作——不是为了参与度，而是为了清晰。构建可重用原语。将经验教训整理成可复用的模式。
将职业生涯视为复利而非彩票的工程师，往往最终走得更远。
最后思考
二十一条听起来很多，但它们实际上归结为几个核心理念：保持好奇，保持谦逊，记住工作总是关于人——你为之构建的用户和你与之构建的队友。
工程职业生涯足够长，可以犯很多错误但仍然领先。我最钦佩的工程师不是那些一切都做对的人——他们是那些从错误中学习、分享发现并持续出现的人。
如果你在旅程早期，要知道它会随时间变得更丰富。如果你已深入其中，我希望其中一些能引起共鸣。
