在 Google 的 14 年里学到的 21 条经验
本文信息来源：addyosmani
大约 14 年前我加入 Google 时，我以为这份工作就是写出很棒的代码。我只对了一半。但待得越久，我越意识到，真正发展得好的工程师未必是最优秀的程序员——而是那些学会如何应对代码之外一切的人：人、政治、对齐、以及不确定性。
这些经验是我希望自己能更早知道的。有些本可以让我少走几个月的弯路；有些则花了数年时间才真正理解。它们都不关于具体技术——那些变化得太快，不足以长期重要。它们讲的是一些反复出现的模式，一次又一次地出现在不同项目中、不同团队里。
我分享这些内容，是因为曾经有一些工程师也这样无私地分享过经验，而我从中受益良多。可以把这看作是我对这份善意的传递。
1. 最优秀的工程师都会痴迷于解决用户问题。
人很容易爱上某项技术，然后再去寻找可以应用它的场景。我自己也这样做过。几乎每个人都经历过。但真正创造最大价值的工程师是反向思考的：他们会全力投入去深入理解用户的问题，并让解决方案从这种理解中自然浮现。
以用户为中心，意味着要花时间查看支持工单，与用户交谈，观察用户如何受挫，不断追问“为什么”，直到触及问题的根源。真正理解问题的工程师往往会发现，优雅的解决方案其实比任何人预想的都要简单。
一开始就从解决方案出发的工程师，往往会为了寻找合理性而不断堆砌复杂性。
2. 做对本身并不值钱。一起把事情做对，才是真正的工作。
你可以赢下每一场技术争论，却输掉整个项目。我见过一些才华横溢的工程师，因为总是做房间里最聪明的人，而积累了无声的怨气。这种代价会在之后以“神秘的执行问题”和“奇怪的阻力”形式显现出来。
真正的技能不在于你是否正确，而在于带着对问题达成一致的目标进入讨论，为他人创造空间，并且持续质疑自己的确定性。
坚持强烈的观点，但保持随时可调整——不是因为你缺乏信念，而是因为在不确定性下做出的决策不应与身份认同牢牢焊死。
3. 行动优先。Ship。你可以编辑一页糟糕的页面，但你无法编辑一页空白的页面。
对完美的追求会让人停滞不前。我见过工程师们花上数周时间，争论一个他们从未真正构建过的系统的理想架构。完美的解决方案很少仅靠思考得出——它源于与现实的接触。AI 在很多方面都能在这里提供帮助。
先把它做出来，再把它做对，然后把它做得更好。把丑陋的原型尽早摆到用户面前。写下凌乱的第一版设计文档。Ship 一个让你略感尴尬的 MVP。你从一周真实的反馈中学到的东西，会比一个月的理论争论多得多。
势能会带来清晰度。分析瘫痪不会创造任何东西。
4. 清晰就是资深。聪明反被聪明误，是一种负担。
想写“聪明”代码的冲动几乎存在于所有工程师身上。这感觉像是在证明自己的能力。
但软件工程是在加入时间和其他程序员之后才真正发生的事情。在那样的环境中，清晰并不是风格偏好——而是降低运营风险的手段。
你的代码是一份写给陌生人的策略备忘录，他们会在凌晨 2 点系统宕机时维护它。优化应以他们的理解为先，而不是你的优雅。我最尊敬的资深工程师，每一次都选择用清晰替代聪明。
5. 新颖性是一笔贷款，你会在系统宕机、招聘以及认知开销上偿还。
把你的技术选型当作一个拥有少量“创新 Token”预算的组织来对待。每当你采用一种实质上非标准的东西时，就花掉一个。你负担不起太多。
重点不是“永远不要创新”，而是“只在你被独特付费去创新的地方才去创新”。其他一切都应该默认选择无聊的方案，因为无聊有已知的失败模式。
“最适合这项工作的工具”往往是“在许多工作中不那么糟的工具”——因为真正的成本在于运维一个动物园。
6. 你的代码不会为你发声。人会。
在我职业生涯早期，我相信出色的工作会自己说话。我错了。代码静静地躺在代码仓库里。你的经理要么在会议上提到你，要么不会。要么是一位同事推荐你参与某个项目，要么是别人。
在大型组织中，很多关键决策是在你没有被邀请的会议里做出的，依赖的摘要不是你写的，参与决策的人只有五分钟时间，却有十二个优先事项。如果在你不在场时，没有人能清楚地说明你的影响力，那么你的影响力实际上就是可有可无的。
这并不完全是关于自我推销。而是让价值链对所有人都清晰可见——包括你自己。
7. 最好的代码，是你从未需要写出来的代码。
工程文化里推崇“创造”。没有人会因为删除代码而获得晋升，尽管删除往往比增加功能更能改善一个系统。你不写的每一行代码，都是一行你永远不需要调试、维护或解释的代码。
在开始构建之前，先把这个问题彻底想清楚：“如果我们干脆……什么都不做，会发生什么？”有时候答案是“什么坏事都不会发生”，那就是你的解决方案。
问题不在于工程师不会写代码，或无法使用 AI 来写代码；而在于我们太擅长写代码了，以至于忘记先问一句：我们是否真的应该这么做。
8. 在规模化之后，连你的 BUG 都会有用户。
当用户数量足够多时，任何可被观察到的行为都会成为一种依赖——无论你当初承诺了什么。有人在抓取你的 API、自动化你的怪癖、缓存你的 BUG。
这会带来一个关乎职业发展的洞见：你无法把兼容性工作当成“维护”，而把新功能当成“真正的工作”。兼容性本身就是产品。
把废弃设计成迁移过程，给时间、工具和同理心留出空间。大多数“API 设计”实际上都是“API 退役”。
9. 大多数“慢”的团队，其实是对齐出了问题的团队。
当一个项目拖延时，本能反应往往是怪执行不到位：人不够努力、技术选错了、工程师不够多。通常这些都不是真正的问题。
在大型公司里，团队是并发的基本单元，但随着团队数量增加，协调成本会呈几何级增长。多数进展缓慢，其实是对齐失败——人们在构建错误的东西，或者用彼此不兼容的方式构建正确的东西。
资深工程师花在澄清方向、接口和优先级上的时间，比“更快地写代码”要多得多，因为真正的瓶颈就在这些方面。
10. 专注于你能控制的事情。忽略你无法控制的事情。
在一家大型公司中，无数变量都不在你的控制范围内——组织调整、管理决策、市场变化、产品方向的转变。执着于这些只会带来焦虑，却无法带来改变的能力。
那些能够保持理智且高效的工程师，会专注于自己的影响范围。你无法控制是否会发生重组，但你可以控制工作的质量、你的应对方式以及你从中学习到的东西。面对不确定性时，将问题拆解开来，找出你能够采取的具体行动。
这不是消极的接受，而是战略性的专注。把精力花在你无法改变的事情上，就是从你能够改变的事情中偷走了精力。
11. 抽象并不会消除复杂性，它只是把复杂性推迟到你值班的那一天。
每一层抽象，都是在赌你不需要理解底层在做什么。有时你会赌赢。但总会有东西泄漏，一旦发生，你必须清楚自己脚下踩的是什么。
资深工程师会在技术栈不断变高的同时，持续学习“更底层”的东西。这并非出于怀旧，而是出于对抽象失效、并在凌晨 3 点独自面对系统那一刻的敬畏。善用你的技术栈。
但要始终保有一个关于其底层失败模式的可运行心智模型。
12. 写作迫使你变得清晰。更好地学习一件事的最快方式，是试着去教它。
写作迫使你变得清晰。当我向他人解释一个概念时——无论是在文档中、演讲中、代码审查评论里，甚至只是与 AI 聊天——我都会发现自己理解中的空白。把某件事说明白给别人听的过程，也会让它在我自己心中变得更加清楚。
这并不意味着你会通过教学来学会成为一名外科医生，但这一前提在软件工程领域仍然在很大程度上成立。
这不仅仅是慷慨地分享知识。这是一种利己的学习技巧。如果你认为自己已经理解了某件事，试着用简单的方式把它讲清楚。你卡壳的地方，正是你理解不够深入的地方。
教学就是在调试你自己的心智模型。
13. 让其他工作成为可能的工作是无价的——也是看不见的。
“粘合性工作”——文档、入职指导、跨团队协作、流程改进——至关重要。但如果你是在无意识中承担这些工作，它可能会拖慢你的技术发展轨迹，并让你精疲力竭。陷阱在于把它当作“乐于助人”去做，而不是将其视为有意识、有边界、且可被看见的影响力。
给它设定时间边界。轮换它。把它转化为成果物：文档、模板、自动化流程。并且让它以“影响力”的形式被清楚看见，而不是被当作一种人格特质。
“无价却不可见”是对你职业生涯来说非常危险的组合。
14. 如果你赢下了每一场争论，你很可能正在积累无声的阻力。
我学会了对自己的确定性保持警惕。当我“赢”得太容易时，往往意味着哪里出了问题。人们停止和你争辩，并不是因为你说服了他们，而是因为他们放弃了尝试——而这些分歧会体现在实际执行中，而不是会议上。
真正的共识需要更长时间。你必须真正理解其他人的视角，吸收反馈，有时还要在公开场合改变自己的想法。
短期内“我是对的”的感觉，远不如与愿意合作的伙伴共同构建事物所带来的长期现实有价值。
15. 当一个衡量指标变成目标时，它就不再具备衡量作用了。
你向管理层公开的每一个指标，最终都会被“博弈”。不是出于恶意，而是因为人类会针对被衡量的东西进行优化。
如果你跟踪代码行数，你就会得到更多代码行。如果你跟踪开发速度，你就会得到被夸大的估算。
高级工程师的做法是：对每一个指标请求，都给出一对指标。一个衡量速度，一个衡量质量或风险。然后坚持解读趋势，而不是崇拜阈值。目标是获得洞察，而不是进行监控。
16. 承认自己不知道，比假装自己知道更能带来安全感。
敢于说“我不知道”的高级工程师并不是在示弱——他们是在创造一种允许。当领导承认不确定性时，这会传达出一个信号：这个空间是安全的，其他人也可以这样做。相反的情况是一种文化：人人都假装自己懂，问题被隐藏起来，直到最终爆发。
我见过一些团队，最资深的人从不承认困惑，我也见过由此造成的伤害。问题没人提。假设没人挑战。初级工程师保持沉默，因为他们以为其他人都懂。
以好奇心为示范，你将获得一个真正学习的团队。
17. 你的人际网络会比你此生拥有的任何一份工作都更持久。
我职业生涯早期只专注于工作，忽视了人脉建设。现在回头看，这是一个错误。那些在公司内外投入时间经营关系的同事，几十年来都持续收获回报。
他们最早听到机会，能更快搭建合作桥梁，获得岗位推荐，并与多年建立信任的人共同创办事业。
工作不是永久的，但你的人脉是。以好奇心和慷慨的态度去对待它，而不是功利性的交易思维。
当你准备向前迈步时，往往正是这些关系为你打开了大门。
18. 大多数性能提升来自于减少工作量，而不是增加聪明的技巧。
当系统变慢时，本能反应是去增加：缓存层、并行处理、更智能的算法。有时这是正确的。但我看到更多的性能提升来自于问一句：“我们在计算哪些其实并不需要的东西？”
删除不必要的工作几乎总是比把必要的工作做得更快更有影响力。最快的代码，是根本不运行的代码。
在你着手优化之前，先质疑这些工作是否一开始就应该存在。
19. 流程的存在是为了降低不确定性，而不是制造文书负担。
最好的流程能让协作更容易、失败的代价更低。最糟糕的流程是一场官僚主义表演——它的存在不是为了提供帮助，而是在事情出错时追责。
如果你无法解释一个流程是如何降低风险或提升清晰度的，那它很可能只是额外的负担。
而如果人们花在记录工作上的时间比真正做事的时间还多，那就说明出了严重的问题。
20. 最终，时间会变得比金钱更有价值。相应地行事。
在职业生涯早期，你用时间换取金钱——这没问题。但在某个阶段，这种权衡会发生逆转。你开始意识到，时间才是不可再生的资源。
我见过高级工程师为了追逐下一个晋升等级而筋疲力尽，只是为了把薪酬再优化几个百分点。他们中有些人确实得到了，但更多的人随后会反思，这是否值得他们所付出的代价。
答案不是“不要努力工作”，而是“清楚你在交换什么，并且有意识地去做这个选择”。
21. 没有捷径，但有复利效应。
专业能力来自刻意练习——稍微逼近并超出你当前的技能水平，反思，再重复。持续多年。不存在压缩版。
但也有令人充满希望的一点：学习会在创造新选择时产生复利效应，而不仅仅是增加新的零碎知识。写作——不是为了互动，而是为了清晰。构建可复用的基础组件。将累积的伤疤经验整理成作战手册。
把职业生涯当作复利而不是买彩票的工程师，往往最终会走得更远。
最后的一个想法
二十一条经验听起来很多，但实际上都可以归结为几个核心理念：保持好奇，保持谦逊，并记住，工作的本质始终关乎人——你为之构建的用户，以及与你并肩构建的队友。
工程师的职业生涯足够漫长，即使犯下许多错误，最终依然能够走在前面。我最钦佩的工程师并不是那些把每件事都做对的人，而是那些从失败中学习、分享他们的发现，并且始终坚持投入其中的人。
如果你正处在职业生涯的早期阶段，要知道随着时间推移，这段旅程会愈发丰盈。如果你已经深耕其中，希望其中一些内容能与你产生共鸣。