写程序不难，难在处理「人」与「复杂」。资深 Google 工程师分享 14 年心得，从用户思维到团队协作，这 21 条金律助你成就更深远的职涯。
（前情提要：Google 即时翻译正式开放所有耳机品牌：70+ 语言上线，美墨印 Android 手机先发 ）
（背景补充：Google 正式推出「Gemini 3」！登顶全球最聪明 AI 模型，有什么亮点？）

本文目录

• 1. 顶尖工程师痴迷于解决用户问题
• 2. 「证明自己是对的」毫无价值，共同达成正确目标才是重点
• 3. 偏向行动。上线吧！你可以修改烂页面，但无法修改空白页
• 4. 资深体现在清晰，聪明体现在负担
• 5. 「新奇」是向维修、招聘和认知负荷借的高利贷
• 6. 程序码不会为你发声，人会
• 7. 最好的程序码是你从未写下的那行
• 8. 当规模够大时，连你的 Bug 都有用户
• 9. 大多数「缓慢」的团队实际上是「失焦」的团队
• 10. 专注于你能控制的事，忽略你不能控制的
• 11. 抽象并不消除复杂性，只是将其转移
• 12. 写作强迫清晰，教学是学习最快的方法
• 13. 让其他工作成为可能的工作是无价的，却也是隐形的
• 14. 如果你赢了每一场争论，你可能正在累积无声的阻力
• 15. 当指标变成目标时，它就不再是好指标了
• 16. 承认「我不知道」比装懂更能创造安全感
• 17. 你的脉络比你做过的任何一份工作都长久
• 18. 大多数性能提升来自「移除工作」，而非「聪明的算法」
• 19. 流程的存在是为了减少不确定性，而非创造文书记录
• 20. 最终，时间会比金钱更值钱，请据此行动
• 21. 没有捷径，但有复利效应

• 最后的一点想法

Google Cloud AI 总监 Addy Osmani，是一名经验丰富的软件工程师与思想者，曾在 Chrome 担任开发者体验负责人近 14 年，参与 DevTools、Lighthouse 和 Core Web Vitals 等项目。如今，他负责协调 Google DeepMind 、工程、产品和开发者关系团队之间的工作。

他在 3 日在他个人博客发布了一篇深度职场心得文。将他多年在 Google 的工作经验与职业素养结合，总结出 21 条关于沟通、技术选择与职业规划的宝贵建议，动区编译整理如下：

---

当我约 14 年前加入 Google 时，我以为这份工作就是写出完美的代码。我只对了一部分。待得越久，我越意识到那些表现优异的工程师不一定是程序写得最好的，而是那些学会如何驾驭程序码之外的一切的人：包括人际关系、职场政治、共识对齐以及不确定性。

这些经验是我希望自己能早点明白的。有些能帮我节省数月的挫败感，有些则花了我数年才真正领悟。这些都与特定技术无关：技术更迭太快，并不重要。它们关乎的是那些在不同项目、不同团队中反复出现的规律。

我分享这些，是因为我曾从那些愿意提携后进的工程师身上获益良多。这是我回馈的一点心意。

1. 顶尖工程师痴迷于解决用户问题

爱上某种技术并到处寻找应用场景是非常诱人的。我做过，每个人都做过。但创造最大价值的工程师是「逆向工作」的：他们痴迷于深入理解用户问题，并让解决方案从这种理解中自然产生。

用户痴迷意味着花时间研究客服工单、与用户交谈、观察用户的操作困境，不断问「为什么」直到触及核心。真正理解问题的工程师通常会发现，优雅的解决方案往往比预想的更简单。 从解决方案出发的工程师，往往为了合理化自己的方案而增加了不必要的复杂性。

2. 「证明自己是对的」毫无价值，共同达成正确目标才是重点

你可以赢得每一场技术争论，却输掉整个项目。我见过聪明的工程师因为总是想当全场最聪明的人，而积累了无声的怨恨。这种代价随后会以「神秘的执行问题」或「莫名的阻力」显现。

技能不在于「正确」，而在于参与讨论以对齐问题、为他人创造空间，并对自己的确定性保持怀疑。 **强烈的主见，开放的心态 **——这不是因为你缺乏信念，而是因为在不确定情况下做出的决定，不应与你的自尊挂钩。

3. 偏向行动。上线吧！你可以修改烂页面，但无法修改空白页

追求完美会导致瘫痪。我见过工程师花好几周讨论他们从未构建过的东西的理想架构。完美的方案很少源于纯粹的思考——它源于与现实的碰撞。AI 在许多方面可以提供帮助。

先做到，再做对，最后做得更好。 把丑陋的原型推到用户面前。写下混乱的设计文档初稿。发布那个让你略感尴尬的 MVP。從一周的真实反馈中学到的东西，比一个月的理论争辩还要多。 冲劲带来清晰，分析瘫痪则一事无成。

4. 资深体现在清晰，聪明体现在负担

写出「聪明」程序码的本能几乎是工程师通用的，这感觉像是能力的证明。 但软件工程是「时间」加上「其他程序设计师」产生的化学反应。在这种环境下，清晰不是一种风格偏好，而是降低运营风险。

你的程序码是写给那些可能在凌晨两点维修故障的陌生人的战略备忘录。优化他们的理解力，而不是你的优雅感。我最敬佩的资深工程师每次都会选择用「聪明」换取「清晰」。

5. 「新奇」是向维修、招聘和认知负荷借的高利贷

将你的技术选择视为一家预算有限的「创新代币」公司。每当你采用实质上的非标准技术时，就花掉一枚。你付不起太多。 重点不是「永远不要创新」，而是「只在你获得独特报酬的地方创新」。

其他一切都应该预设为「无聊」，因为无聊意味着其失效模式是已知的。 「最适合该工作的工具」往往是「在多项工作中表现最不差的工具」——因为经营一个技术动物园会成为真正的负担。

6. 程序码不会为你发声，人会

职业生涯早期，我以为优秀的工作表现自会证明一切。我错了。程序码静静地待在仓库里。你的主管在会议中是否提到你，同事是否推荐你参与项目，这才是关键。

在大型组织中，决定是在你未受邀的会议中、由只有五分钟时间处理十二项优先事项的人，根据你没写过的摘要做出的。如果当你不在场时，没人能说清你的影响力，那你的影响力就是可有可无的。这不完全是自我推销，而是要让价值链对每个人（包括你自己）都清晰可见。

7. 最好的程序码是你从未写下的那行

工程文化庆祝创造。没人会因为删除程序码而升职，尽管删除通常比增加更能优化系统。你没写下的每一行程序码，都是你永远不需要调试、维护或解释的。

在构建之前，彻底问自己一个问题：「如果我们干脆不做，会发生什么？」有时答案是「没什么坏事」，那就是你的解决方案。 问题不在于工程师不会写代码或不会用 AI 写，而在于我们太擅长写了，以至于忘了问「应不应该写」。

8. 当规模够大时，连你的 Bug 都有用户

当用户足够多时，任何可观察的行为都会变成依赖项——无论你原本承诺了什么（海勒姆定律）。有人正在抓取你的 API，自动化你的奇特特性，缓存你的 Bug。

这产生了一个职业级的洞察：你不能把兼容性工作视为「维护」，把新功能视为「真实的工作」。兼容性就是产品本身。 设计弃用方案时，应将其视为带有时间、工具和同理心的迁移过程。大多数「API 设计」实际上是「API 退休」。

9. 大多数「缓慢」的团队实际上是「失焦」的团队

当项目停滞不前时，本能是归咎于执行力：人手不够、技术选型错误。通常这些都不是核心问题。 在大公司，团队是你的并发单元，但协调成本随团队增加呈几何级增长。大多数缓慢实际上是对齐失败——人们在构建错误的东西，或以不兼容的方式构建正确的东西。 资深工程师花更多时间厘清方向、接口和优先级，而不是「更快地写代码」，因为那是真正的瓶颈所在。

10. 专注于你能控制的事，忽略你不能控制的

在大型公司，无数变量是你无法控制的——组织架构调整、管理层决策、市场变化、产品转向。纠结于这些会产生焦虑却无济于事。 保持理智且高效的工程师会专注于他们的影响圈。

你无法控制重组，但你可以控制工作的质量、你的反应以及你学到的东西。面对不确定性时，将问题拆解并找出你可采取的具体行动。 这不是消极接受，而是战略专注。花在无法改变的事情上的精力，是从你能改变的事情上偷走的。

11. 抽象并不消除复杂性，只是将其转移

每一种抽象都是一场赌博，赌你不需要理解底层原理。有时你赢了，但抽象总会泄漏。当它失效时，你需要知道底层发生了什么。 资深工程师即使在技术栈越堆越高时，仍会持续学习「底层」知识。这不是出于怀旧，而是出于对抽象失败时刻的尊重。使用你的工具栈，但要掌握其底层失效模式的心智模型。

12. 写作强迫清晰，教学是学习最快的方法

写作强迫你思考。当我向他人解释一个概念时——无论是在文件、演讲、代码审查评论，甚至只是与 AI 聊天——我都会发现自己理解上的空白。

让内容对别人清晰的过程，也会让它对我更清晰。 这不只是慷慨分享知识，这是一个自私的学习技巧。如果你认为自己理解了某件事，试着简单地解释它。你卡住的地方，就是你理解浅薄的地方。 教学是在调试（debug）你自己的心智模型。

13. 让其他工作成为可能的工作是无价的，却也是隐形的

「胶水工作（Glue work）」——文档、入职引导、跨团队协调、流程改进——至关重要。但如果你无意识地去做，它会阻碍你的技术成长并让你筋疲力尽。陷阱在于把它当作「乐于助人」，而不是将其视为有意识的、有边界的、可见的贡献。 限制时间、轮流执行、将其转化为产出（文件、模板、自動化工具）。

让它被视为影响力，而非人格特质。

14. 如果你赢了每一场争论，你可能正在累积无声的阻力

我学会了怀疑自己的确定性。当我「赢」得太轻松时，通常有些不对劲。人们停止争论不是因为被你说服，而是因为他们放弃了尝试——他们会在执行中，而非会议中表达这种反对。 真正的对齐需要更长时间。

你必须真正理解他人的观点，纳入反馈，有时甚至公开改变主意。短期赢得争论的快感，远不如长期与心悦诚服的伙伴共事的价值。

15. 当指标变成目标时，它就不再是好指标了

你向管理层展示的每个指标最终都会被「操纵」。这不是因为恶意，而是因为人类会针对被测量的内容进行优化（古德哈特定律）。 如果你追踪程式码行数，你会得到更多行数。如果你追踪速率，你会得到膨胀的估算。

资深的做法：针对每个指标请求，提供一对指标。一个看速度，一个看质量或风险。坚持解读趋势，而不是崇拜阈值。目标是洞察力，而非监视。

16. 承认「我不知道」比装懂更能创造安全感

说「我不知道」的资深工程师并非展现弱点，而是在创造「许可」。当领导者承认不确定性时，这释放出一个信号：这个房间对其他人也是安全的。 我见过资深人员从不承认困惑的团队，那种伤害很大：问题没人问，假设没人挑战，初级工程师保持沉默，因为他们以为只有自己不懂。 示范好奇心，你就能得到一个真正会学习的团队。

17. 你的脉络比你做过的任何一份工作都长久

职业生涯早期，我专注于工作而忽视了人脉。回头看这是个错误。投资于关系（公司内外）的同事几十年来都受益匪浅。 他們最先听到机会，能更快建立桥梁，获得职位推荐，并与建立多年信任的人共同创业。 工作不是永远的，但人脉是。 以好奇和慷慨而非交易的心态去建立关系。

18. 大多数性能提升来自「移除工作」，而非「聪明的算法」

当系统变慢时，本能是增加：缓存层、并行处理、更聪明的算法。有时这没错，但我见过更多性能提升来自问一句：「我们计算了哪些不需要的东西？」 删除不必要的工作几乎总比更快地完成必要工作更有影响力。最快的代码是从不运行的代码。

19. 流程的存在是为了减少不确定性，而非创造文书记录

最好的流程让协调更容易，让失败成本更低。最糟的流程是「官僚主义戏剧」——它的存在不是为了帮忙，而是为了出事时推卸责任。 如果你无法解释一个流程如何降低风险或增加清晰度，那它可能只是负担。如果人们花在记录工作的时间比做工作还多，那就出大问题了。

20. 最终，时间会比金钱更值钱，请据此行动

职业生涯早期，你用时间换钱，这没问题。但在某个点，计算方式会反转。你会意识到时间是不可再生资源。 我见过资深工程师为了追逐下一个职等、优化那几个百分点的薪酬而精疲力竭。有人得到了，但大多数人事后都怀疑这是否值得他们所付出的代价。 答案不是「不要努力工作」，而是「知道你在交易什么，并有意识地进行交易」。

21. 没有捷径，但有复利效应

专业知识来自刻意练习——稍稍超出你目前的技能范围，反思，重复，持续多年。没有缩减版。 但希望在于：当学习创造新选择而非仅仅是零散知识时，它会产生复利。 写作（为了清晰）、构建可重用的原组、将惨痛教训收集成操作手册。 将职业生涯视为「复利」而非「彩票」的工程师，往往能走得远得多。

---

最后的一点想法

这 21 条听起来很多，但核心想法其实只有几个：保持好奇、保持谦逊，并记住工作始终关乎于人——包括你为之构建产品的用户，以及与你共同构建产品的队友。

工程师的职业生涯很长，长到足以让你犯下许多错误后依然能取得成功。我最钦佩的工程师不是那些从不犯错的人，而是那些从错误中学习、分享发现并坚持不懈的人。

如果你刚开启这段旅程，请知道它会随着时间变得越发精彩。如果你已深耕多年，希望其中几条能让你产生共鸣。