在技术世界里，编写优秀代码固然重要，但真正让工程师脱颖而出的，往往是那些看似“代码之外”的能力：理解用户、协调团队、应对不确定性、做出明智选择。
Addy Osmani，在 Google 工作近 25 年、曾在 Chrome 团队主导 DevTools、Lighthouse 和 Core Web Vitals 的资深工程师，如今是 Google Cloud AI 总监。近日，他将自己多年的深度实践总结为《21 Lessons From 14 Years at Google》（在 Google 工作 14 年的 21 条经验教训）。
在这篇经验分享中，他不仅谈技术，更分享了职业成长、团队协作和工程文化中那些鲜为人知却至关重要的洞察，为开发者提供了一份既实际又耐人寻味的指南。
原文链接：https://addyosmani.com/blog/21-lessons/
作者 | Addy Osmani 责编 | 苏宓
出品 | CSDN（ID：CSDNnews）
大约 14 年前我加入谷歌时，以为这份工作的核心就是写出优秀的代码。
这个判断并不算错，但也只对了一半。待得越久，我越意识到，那些真正发展得好的工程师，未必是编程能力最强的人，而是更早学会如何应对“代码之外的一切”：人、组织政治、目标对齐，以及无处不在的不确定性。
这些都是我希望自己能更早明白的经验。有些经验教训本可以让我少走好几个月的弯路；有些则花了我好几年才真正想通。它们几乎都和具体技术无关——技术变化太快，不值得执着。反而是关于一些反复出现的模式：一个项目接一个项目，一个团队换一个团队，总是会重演。
我之所以把这些写出来，是因为自己曾经从前辈工程师那里获益良多。就当这是一次“传递善意”的尝试吧。
最好的工程师，对解决用户问题近乎偏执
人很容易迷上某种技术，然后再去寻找适合它的应用场景。我也这么做过，几乎所有人都做过。但真正创造最大价值的工程师，思路恰恰相反：他们从问题出发，先把用户的问题理解到位，解决方案自然会从中浮现。
所谓“以用户为中心”，意味着要花时间去看工单、和用户交流、观察用户是如何卡住的，不断追问“为什么”，直到触及问题的根本。真正理解问题的工程师，往往会发现，那个优雅的解法比所有人想象的都要简单。
而从一开始就带着“解法”的工程师，常常会为了证明自己是对的，不断往系统里堆复杂度。
对不对不值钱，一起走到“对”才是真本事
你可以在每一次技术争论中都获胜，但项目依然可能会失败。我见过不少非常聪明的工程师，总是房间里最“对”的那个人，却一点点积累起看不见的怨气。结果往往在后期爆发，表现为各种“莫名其妙的执行问题”和“说不清楚的阻力”。
真正重要的能力不是“我是不是对的”，而是能不能在讨论中先对齐问题本身，给别人留出空间，同时也对自己的判断保持一点怀疑。
要有强观点，但别死抱不放。不是因为你没有立场，而是因为在不确定性下做出的决策，本来就不该和个人身份绑死在一起。
行动优先，先交付再说。空白页是没法修改的
对完美的执念，往往是行动的最大阻力。我见过工程师为了一个从没真正做过的东西，花上好几周反复争论“最理想的架构”。但现实是，完美方案几乎不会只靠想出来，它一定是在和现实碰撞之后才慢慢成形的——AI 在这件事上，其实能帮不少忙。
先做出来，再把它做对，然后再做得更好。把那个丑陋的原型丢到用户面前，写下那份略显凌乱的设计初稿，发布一个让你自己都有点不好意思的 MVP。你从一周真实反馈里学到的东西，往往比一个月的纸上谈兵还多。
节奏感会带来清晰度，过度分析只会什么都做不出来。
清晰的表达能力是资历，耍巧就是负担
工程师几乎都有一个本能：想写点“聪明”的代码。那感觉很像是在证明自己有多厉害。
但软件工程从来不是“一个人写完就结束”的事，而是代码要经得起时间，也要经得起一波又一波后来者的接手。在这种现实环境里，清晰不是风格选择，而是在降低系统运行风险。
你的代码，其实是一份写给陌生人的“策略备忘录”——那些人可能会在凌晨两点、系统出故障时，顶着压力来维护它。请为他们能不能看懂而优化，而不是为你自己的优雅感受服务。我最敬重的那些资深工程师，几乎每一次都会用清晰换掉“巧妙”。
创新就像是“贷款”，迟早要用故障、招聘成本和认知负担来偿还
对技术选型，不妨把自己当成一家只有少量“创新代币”的组织。每引入一种明显非主流的技术，就消耗一枚。你其实用不起太多。
重点不是“永远别创新”，而是“只在你确实被付钱要求创新的地方创新”。其他地方，默认选择无聊一点的方案更安全，因为“无聊”意味着失败模式是已知的。
很多时候，“最适合当前问题的工具”，并不如“在很多问题上都不算最差的工具”。毕竟，真正昂贵的，是把一个动物园长期运转下去。
代码不会替你说话，只有人会
职业早期，我一度相信：只要把事情做好，价值自然会被看到。后来发现这是个误解。代码安静地躺在仓库里，但你的经理会不会在会上提到你，同事会不会把你推荐进一个关键项目，完全是另一回事。
在大型组织里，很多决定是在你不在场的会议上做出的，用的是你没写过的总结，由那些只有五分钟时间、同时背着十二个优先级的人拍板。如果当你不在房间里时，没人能清楚说出你的价值，那你的影响力本质上就是“可有可无”。
这不完全是自我推销，而是让价值链对所有人都足够清晰——包括你自己。
最好的代码，是你根本没写过的代码
工程文化里总是赞美“创造”。几乎没人会因为删代码而升职，尽管删代码往往比加代码更能改善系统。你每少写一行代码，就少了一行需要调试、维护和解释的负担。
在动手之前，先把这个问题问到尽头：“如果我们干脆什么都不做，会怎样？”有时候答案是“其实也不会出什么事”，那就是你的解决方案。
问题从来不是工程师不会写代码，或者不能用 AI 来写。恰恰相反，我们太擅长写代码了，以至于常常忘了先问一句：这东西真的有必要写吗？
规模一上来，连你的 Bug 都会有用户
一旦用户足够多，任何“看得见的行为”都会变成依赖——不管你当初是怎么承诺的。总会有人在爬你的 API、自动化你的小毛病，甚至把你的 Bug 当成特性缓存下来。
这会带来一个影响整个职业判断的认知：你不能把兼容性工作当成“维护”，把新功能当成“正事”。兼容性本身就是产品的一部分。
所以，弃用设计要当成一次迁移来做：给时间、给工具，也要给同理心。很多所谓的“API 设计”，其实真正考验的是“API 如何体面退休”。
大多数“慢团队”，本质上是没对齐的团队
项目一拖再拖时，第一反应往往是怪执行力：人不够拼、技术选错了、工程师不够多。但多数情况下，这些都不是根因。
在大公司里，团队是并发执行的基本单元，而随着团队数量增加，协作成本会呈几何级数上涨。所谓“慢”，往往是对齐失败：要么大家在做错的事情，要么在用彼此不兼容的方式做对的事情。
资深工程师花更多时间在澄清方向、接口和优先级上，而不是“把代码写得更快”，因为真正的瓶颈就卡在这里。
专注你能控制的，放下你控制不了的
在大公司里，有太多变量不在你掌控之中：组织调整、管理决策、市场变化、产品转向。反复纠结这些，只会制造焦虑，却带不来行动空间。
那些能长期保持清醒和高效的工程师，都会把注意力收缩到自己的影响圈内。你无法决定会不会重组，但你可以决定工作的质量、自己的回应方式，以及从中学到什么。面对不确定性，把问题拆小，找出你此刻“确实能做的动作”。
这不是消极接受，而是策略性的聚焦。把精力花在无法改变的事情上，本质上是在偷走你改变得了的那部分。
抽象不会消除复杂度，只是把它推迟到你值班的那天
每一层抽象，都是一次赌博：赌你永远不需要理解底层发生了什么。有时候你会赢，但总会有东西“漏出来”。而当它真的漏出来时，你必须知道自己踩在什么之上。
资深工程师会在技术栈不断变高的同时，持续学习“更底层”的东西。这不是情怀，而是对那个凌晨三点、抽象失效、你独自面对系统的时刻保持敬畏。放心使用你的技术栈，
但一定要对它底层的失败模式有一个可用的心智模型。
写作会逼迫你变清楚，最快的学习方式之一是试着教别人
写下来，本身就会迫使思路变清晰。每当我试图向别人解释一个概念——不管是文档、分享、代码评审评论，还是跟 AI 聊天——我都会发现自己理解里的空洞。把事情讲清楚给别人，本身就会让它在我脑子里更清楚。
当然，这不意味着你靠教别人就能学会当外科医生，但在软件工程这个领域，这个前提大体是成立的。
这不仅仅是“乐于分享”，更是一种利己的学习技巧。如果你觉得自己已经懂了某个东西，试着用最简单的话讲一遍。你卡住的地方，往往就是理解最浅的地方。
教学，其实是在给自己的认知模型做调试。
让其他工作得以进行的工作，最珍贵，却常常看不见
“胶水工作”——文档、入职培训、跨团队协调、流程改进——都很重要。但如果你下意识地去做，可能会拖慢技术发展轨迹，甚至把自己累垮。陷阱在于把它当成“乐于助人”，而不是当成有边界、可衡量、可见的影响力来管理。
给它定时间框架。轮换着做。把它转化为产物：文档、模板、自动化工具。并让别人能看到这是价值贡献，而不是性格特质。
珍贵又隐形，对职业生涯来说是一种危险组合。
如果你赢得每一次争论，可能在积累无声的抵抗
我学会了怀疑自己的“确定性”。当我轻而易举地“赢”得太多时，通常就有问题。别人不再反对你，并不是因为被说服，而是放弃尝试——而这种不同意见会体现在执行上，而不是会议上。
真正的对齐需要时间。你必须理解别人的视角，吸纳反馈，有时候还得当众改变主意。
短期的“我对”感觉，比不上长期和心甘情愿的协作者一起做事的价值。
当一个指标变成目标，它就停止衡量了
你呈现给管理层的每个指标，迟早都会被“优化”。不是出于恶意，而是因为人类会去优化被测量的东西。
你跟踪代码行数，就会出现更多行。你跟踪开发速度，就会出现夸大的估算。
资深做法是：对每个指标请求，用一对指标回应——一个衡量速度，一个衡量质量或风险。然后强调趋势分析，而不是盲目追求阈值。目标是洞察，而不是监控。
承认自己不知道的，比假装知道更安全
那些说“我不知道”的资深工程师，并不是在示弱——他们在创造安全空间。当领导者承认不确定性时，信号是：其他人也可以安全地承认。否则，团队就会形成“假装懂”的文化，问题被隐藏，直到爆炸。
我见过最资深的人从不承认困惑的团队，结果是：没人敢提问，假设不被质疑，初级工程师保持沉默，因为他们以为大家都懂。
以好奇心为榜样，你就会得到一个真正会学习的团队。
你的关系网，比你做的每份工作都要持久
职业早期，我专注于工作而忽略了建立人脉。事后看，这是个错误。那些花时间经营关系的同事——无论公司内外——几十年都能受益。
他们最先听到机会，能更快搭建桥梁，获得推荐，甚至与长期信任的人共同创业。
你的工作不是永远的，但关系网是。用好奇心和慷慨心去经营，而不是只为了交易式的功利。
需要跳槽时，往往是关系帮你打开门。
大多数性能提升，来自减少工作量，而不是耍聪明
系统变慢时，本能反应是加东西：缓存层、并行处理、更聪明的算法。有时候这是对的，但我见过更多性能提升，来自问一句：“哪些计算其实没必要做？”
删除不必要的工作，几乎总比把必要工作做快更有效。最快的代码，是永远不运行的代码。
在优化之前，先问问自己：这份工作真的有存在的必要吗？
流程是为降低不确定性，而不是为了留下纸面记录
最好的流程让协调更容易，让失败成本更低。最糟的流程是官僚秀——不是为了帮忙，而是为了出错时有人背锅。
如果你无法解释一个流程如何降低风险或增加清晰度，它很可能只是负担。
如果团队花在写文档上的时间比实际做事还多，那问题就严重了。
到头来，时间比钱更值钱。按此行事
职业早期，你用时间换钱——没问题。但到某个阶段，这个逻辑会反过来。你会意识到，时间才是不可再生的资源。
我看过资深工程师为追求下一次升职、优化几个百分点的薪酬而烧尽自己。有的人得到了目标，大多数人事后都会想：值不值？
答案不是“不用努力”，而是“知道你在交易什么，并且有意识地做出选择”。
没有捷径，但有复利效应
专业能力来自刻意练习——稍微超出当前能力、反思、重复。几年如一日。没有速成版。
但好消息是：当学习产生新选择，而不仅仅是新知识碎片时，它会复利。写作——不是为了吸引眼球，而是为了清晰。构建可复用的原语。把经验累积成操作手册。
把职业当成复利，而不是买彩票的人，通常最终会走得更远。
最后一点感想
二十一条经验看起来很多，但归根结底只有几个核心：保持好奇，保持谦逊，记住工作始终关乎人——你为谁构建（用户），你和谁一起构建（团队）。
工程师的职业足够长，允许你犯不少错误，还能最终走得更远。我最佩服的工程师，不是事事正确的人，而是那些从错误中学习、分享发现、持续坚持的人。如果你刚起步，请相信时间会让经验更丰富；如果你已深入其中，希望这些经验对你有所共鸣。
