原文：https://addyosmani.com/blog/21-lessons/
谷歌14年，我学到的21条经验
大约 14 年前初入谷歌时，我天真地以为，工作的核心无非是写出漂亮的代码。
这话只对了一半。入行久了，我逐渐意识到，那些真正如鱼得水的工程师，未必拥有最顶尖的编程技术，但一定懂得在代码之外的世界游刃有余：他们搞得定人际关系，玩得转职场政治，既善于“对齐”（Alignment）目标，也能在局势不明时找准方向。
如果早点明白这些道理就好了。有些教训本可以帮我省去数月的挫败感，而另一些，我更是花了数年才彻底参透。
这些经验与具体技术无关——技术更迭太快，细枝末节并不重要。它们关乎那些在每一个项目、每一个团队中反复出现的模式。
我把它们写出来，是因为曾受惠于那些为我指点迷津的前辈。前人栽树，后人乘凉，现在，我希望把这份薪火传递下去。
1. 最优秀的工程师都痴迷于解决用户痛点
手持锤子，看什么都像钉子——沉迷于某项技术，然后到处找场景生搬硬套，这种诱惑极难抗拒。我也干过，谁没干过呢？
但是，那些创造最大价值的工程师，往往具备逆向思维：他们痴迷于深度理解用户痛点，让解决方案从对问题的理解中自然生长出来。
所谓“用户至上”，意味着你要花时间泡在客服工单里，和用户聊天，观察他们在哪里卡壳。哪怕“打破砂锅问到底”，也要挖出病根。真正理解问题的工程师往往发现，最优雅的解法其实比任何人预想的都要简单。
反观那些先定方案再找问题的工程师，往往为了证明方案合理，反倒把系统搞得复杂无比。
2. “你是对的”不值钱，大家达成共识才是真本事
哪怕你赢了每一次技术争论，最后仍可能输掉整个项目。我见过许多才华横溢的工程师，因为总要在屋子里当“最聪明的那个人”，结果招致了同事无声的怨恨。这些代价最终会化作“莫名其妙的执行障碍”和“不知从何而来的阻力”找上门来。
真本事不在于证明自己正确，而在于引导讨论以对齐问题，给他人留有余地，并对自己所谓的“确定性”保持审慎。
观点鲜明，心态开放（Strong opinions, weakly held）——这不代表你缺乏信念，而是说在不确定的环境下做决策，不应将你的自尊心与观点焊死在一起。
3. 崇尚行动。赶紧上线（Ship）。烂文章可以改，白纸没法改
追求完美往往是行动的绊脚石。我见过工程师为了一个架构的理想形态争论数周，而这东西连一行代码都还没写。完美的方案极少诞生于真空的思考，它诞生于与现实的碰撞。这一点上，AI 往往能帮大忙。
先做出来，再做正确，最后再做更好。
把你那个简陋的原型推到用户面前；写出那份略显粗糙的设计文档初稿；发布（Ship）那个让你有点尴尬的 MVP（最小可行性产品）。从一周真实反馈中学到的东西，远胜过闭门造车讨论一个月。
行动带来清晰，光想不做（Analysis paralysis）产不出任何成果。
4. 清晰即资深。炫技是负担
写出“聪明”的代码几乎是所有工程师的本能，仿佛这样才能证明能力。
但软件工程是一门关于“时间”和“协作”的学问。在这种环境下，清晰不仅仅是风格偏好，更是降低运营风险的必要手段。
你的代码就是写给陌生人的战略备忘录，特别是当他们在凌晨两点处理宕机事故时。请为了他们的理解而优化，而不是为了展示你的优雅。我最敬佩的资深工程师，无一例外都懂得为了清晰而克制炫技的冲动。
5. “新奇特”是一笔贷款，还款方式是宕机、招聘困难和认知负担
把选择技术的过程想象成管理一家公司，你手中的“创新代币”预算极少。每引入一种非主流的新技术，就消耗一枚代币。
关键不在于“永远不要创新”，而是“只在真正能获得独特回报的地方创新”。至于其他部分？默认选择那些无聊的技术就好，因为无聊意味着即使出问题，坑在哪里大家都心知肚明。
所谓“最适合该工作的工具”，往往其实是“在所有工作中坏处最少的工具”——因为维护一个五花八门的“技术动物园”，才是真正的昂贵代价。
6. 代码不会替你说话，人才会
职业生涯早期，我笃信“酒香不怕巷子深”，以为只要活儿干得漂亮，自然会被人看见。
大错特错。代码静静地躺在代码仓库（Repository） 里，它是哑巴。而在会议室里提到你名字（或者没提）的，是你的经理；推荐你去负责核心项目（或者推荐别人）的，是你的同事。
在大厂里，决定你命运的关键时刻，往往发生在你无权列席的会议上；决策者手里拿的摘要不是你写的；而且他们只有五分钟，却要处理十二件优先级事项。如果你不在场时没人能清晰复述你的贡献，那么你的贡献就约等于零。
这不叫“自我推销”，这叫让价值链路对所有人——包括你自己——都清晰可见。
7. 最好的代码，是那些你压根没写的代码
工程师文化通常崇尚“创造”。尽管“删代码”往往比“写代码”更能优化系统，但从来没人因为删减了代码而升职。然而，每一行你不写的代码，就是一行你永远不需要调试（Debug）、维护或解释的代码。
在动手构建之前，哪怕把这个问题问烂了也要问：“如果我们干脆……不做这功能会怎样？”
有时候答案是“没啥坏处”，恭喜你，这就是最佳方案。问题不在于工程师不会写代码（或者不会用 AI 写代码），而在于我们太擅长写代码，以至于忘了问“该不该写”。
8. 规模大了，连你的 Bug 都有人用
当用户基数足够大时，系统里任何可见的行为都会变成用户的依赖项——不管你原本是否承诺过。总会有人写脚本爬你的 API，利用你的系统怪癖实现自动化，甚至把你的 Bug 当作特性（Feature）来用。
这会带给你一个职业级的洞察：别再把兼容性工作当成“打杂”，把做新功能当成“正事”。兼容性本身就是产品。
在设计废弃（Deprecation）方案时，请把它当作一次数据迁移来做：留足时间，提供工具，并保持同理心。绝大多数所谓的“API 设计”，其实本质上是“API 退休计划”。
9. 大多数“慢”团队，其实是“没对齐”的团队
当项目进度拖沓时，人们的本能反应是怪罪执行力：大家不够努力，技术选型错了，或者人手不足。但通常，这些都不是核心症结。
在大公司里，团队是并发单元，但协作成本随着团队数量呈几何级数增长。大多数时候，“慢”的本质是对齐（Alignment） 失败——大家在做错误的东西，或者用不兼容的方式做正确的东西。
资深工程师花在理清方向、定义接口和确认优先级上的时间，远多于“把代码写得更快”的时间，因为那才是真正的瓶颈所在。
10. 关注你能控制的，忽略你不能控制的
在大厂打工，有无数变量是你控制不了的——组织架构调整（Reorg）、管理层拍板、市场风向突变、产品方向转型（Pivot）。纠结于这些，只会带来无能为力的焦虑。
那些能够保持清醒且高效的工程师，只会死磕自己的“影响圈”。你控制不了公司会不会重组，但你能控制代码的质量、你应对变化的态度，以及你能从中学到什么。
面对不确定性，把大问题拆解成小块，找出你可以执行的具体动作。这不叫被动躺平，这叫战略聚焦。花在不可控事物上的每一分精力，都是从可控事物那里偷来的。
11. 抽象层不会消除复杂性，只会把它推迟到你值班（On-call）那天爆发
每一层抽象都是在打赌：赌你不需要懂底层原理也能干活。有时候你赢了，但这层抽象总会有“泄漏”的一天。一旦泄漏，你必须得知道你脚底下踩的到底是什么。
资深工程师哪怕技术栈（Stack） 堆得再高，也会坚持学习“底层”知识。这不仅是为了怀旧，而是出于对某种时刻的敬畏——当抽象失效，凌晨 3 点你独自面对系统故障的那一刻。
请尽情使用你的技术栈，但要在脑子里始终保留一份底层的故障模型。
12. 写作倒逼清晰。学得最快的方法，是试着教别人
写作能强迫你理清思路。每当我试图向他人解释某个概念——无论是在文档、演讲、代码评审（Code Review），还是在与 AI 对话中——我总能发现自己理解上的盲区。让内容对他人变得“易读”，也能让我自己理解得更透彻。
当然，你不能靠“教别人做手术”来学会拿手术刀，但在软件工程领域，这个逻辑大体成立。
这不仅是慷慨分享知识，更是一条“自私”的学习捷径。如果你觉得自己懂了，试着简单地把它讲清楚。你在哪里卡壳，就说明你对哪里的理解还流于表面。
教人，其实就是在给自己的思维模型 Debug。
13. 那些成就他人的工作是无价的——但也往往是隐形的
所谓胶水工作（Glue Work）——写文档、新人入职引导（Onboarding）、跨团队协调、流程改进——至关重要。但如果你只是凭本能去做这些事，它很可能会拖累你的技术成长轨迹，甚至导致职业倦怠。陷阱在于，你往往把它视作“热心帮忙”，而非一种刻意为之、有边界且可见的产出。
给它设定时间盒（Timebox）；轮流分担；并将其转化为资产（Artifacts）：文档、模板或自动化工具。要让这一切成为可见的“影响力”，而非仅仅被贴上“性格好”的标签。
在职场中，“无价”却“隐形”，是个危险的组合。
14. 如果你赢了每一次辩论，你可能正在积累无声的抵抗
我学会了警惕自己的“绝对正确”。赢得太轻松，往往意味着有问题。人们不再反驳，并非因为被你说服，而是因为他们放弃了沟通——这种分歧不会在会议室里显露，却会在执行（Execution） 环节爆发。
真正的对齐（Alignment） 需要时间打磨。你必须真正理解其他视角，吸纳反馈，甚至有时需要公开改变主意。
做那个“正确的人”虽有一时的快感，但远不如拥有一群心甘情愿的伙伴长期共建来得有价值。
15. 当一个指标变成目标，它就不再是一个好指标（古德哈特定律）
任何呈报给管理层的指标，最终都会被“玩坏（Gamed）”。这并非恶意，而是人性使然——人们总会针对考核标准去优化。
考核代码行数，就会得到冗余代码；考核敏捷开发的速率（Velocity），就会得到注水的工时估算。
资深的做法是：面对每一个指标要求，都拿出“成对指标”作为回应。测速度，就必须配上测质量或风险的指标。重点在于解读趋势，而非盲目崇拜数值门槛。我们要的是洞察，不是监控。
16. 承认“我不知道”，比假装懂更有安全感
资深工程师说“我不知道”，展示的不是软弱，而是一种授权。当领导者承认不确定性，便向全场释放了一个信号：这里很安全，你们也可以不懂。
反之，若人人都假装听懂，问题就会被掩盖，直至最后暴雷。
我见过那种资深人士从不承认困惑的团队，也目睹过其带来的破坏。没人提问，既定假设无人质疑。初级工程师不敢作声，以为“原来大家都懂，唯独我不懂”。
以身作则展现好奇心，才能带出一个真正会学习的团队
17.你的工作会有尽头，但你的人脉没有
职业生涯早期，我只顾埋头苦干，却忽略了人脉建设。回过头看，大错特错。
那些在公司内外用心经营关系的同事，在之后的几十年里都吃到了红利。他们总能最先听到机会的风声，更快地搭桥铺路，被推荐到关键岗位，甚至能和多年建立起信任的伙伴联合创业。
工作并非永恒，人脉却能长存。经营人脉请怀抱好奇与慷慨，切莫将其视作一种功利性的交换（Transactional hustle）。
当你准备迈向新台阶时，最后帮你推开那扇门的，往往就是这些人际关系。
18. 大多数性能提升来自“少做”，而不是“巧做”
当系统变慢时，工程师的本能反应往往是做加法：加缓存层、加并行处理、引入更精妙的算法。有些时候这没错。但我见过的性能飞跃，更多源于一个反问：“我们是不是在算一些压根不需要算的东西？”
砍掉不必要的工作，几乎总是比给必要的工作提速更有效。
跑得最快的代码，是那些压根无需运行的代码。
在动手优化之前，先拷问一番：这任务真有存在的必要吗？
19. 流程是为了减少不确定性，而不是为了留痕
最好的流程能简化协作，降低试错成本。最差的流程则是官僚主义的作秀（Bureaucratic theater）——它的存在不是为了解决问题，而是为了出事时方便甩锅（Assign blame）。
如果一个流程不能解释它如何降低了风险或提升了清晰度，那它大概率只是徒增内耗（Overhead）。
若有一天大家写文档的时间多过干实事，那一定是哪里出了大问题。
20. 最终，时间会比金钱更值钱。请据此行事
入行之初，你用时间换钱——这无可厚非。但行至某处，这套算法会发生逆转。你会开始痛感，时间才是不可再生资源。
我见过资深工程师为了追逐下一个职级（Promo level），为了薪水涨那几个百分点，把自己彻底耗尽（Burn out）。有些人确实做到了。但大多数人在事后都会怀疑，为了这点回报放弃的生活到底值不值。
答案并非“拒绝奋斗”，而是“清醒地知道交易的筹码，并审慎地进行交换”。
21. 世上没有捷径，但有复利
专业造诣来自于刻意练习（Deliberate practice）——把自己推向能力极限，反思，重复。坚持数年。这事儿没有速成班。
但希望在于：学习具有复利效应。这种复利不来自琐碎知识点的堆砌，而源于那些能为你创造新选项的能力。
写作——不为流量，只为厘清思路；构建可复用的基建（Primitives）；将过往教训留下的伤疤，编纂成实战手册（Playbooks）。
那些把职业生涯当作复利投资而非彩票赌博的工程师，最终往往能走得更远。
写在最后
21条经验看似繁多，归根结底不过几条核心：保持好奇，保持谦逊，并记住工作永远是关于“人”的——为你服务的用户，以及和你并肩作战的队友。
工程生涯漫长，长到足以包容你犯下一堆错误，却依然让你笑到最后。我最钦佩的工程师不是那些从未犯错的人，而是那些从错误中汲取教训、分享心得，并且坚持在场（Kept showing up） 的人。
若你刚刚起步，请相信沿途风景会随时间愈发丰满；若你已深耕多年，愿这些文字能让你心有戚戚。