这不是一篇教你写更好代码的文章，而是告诉你：在大厂里，代码往往不是决定你走多远的关键因素。作者 Addy Osmani 是一位来自爱尔兰的资深工程领导者，现任 Google Cloud AI 总监，负责推动开发者与企业落地 Gemini、Vertex AI 和 Agent Development Kit（ADK）。在此之前，他在 Chrome 团队深耕近 14 年。如今他的工作横跨 Google DeepMind、工程、产品与开发者关系，专注把研究与工程落地连起来。
也正因为经历过一线开发、平台级产品、以及大型组织协作的完整周期，他回头复盘谷歌十四年职场才意识到：那些在谷歌“如鱼得水”的工程师，未必是最强程序员，而是更懂得驾驭 人际关系、政治博弈、目标对齐与组织灰度。技术会迅速迭代，但这些规律会在项目推进、团队更替中反复出现。
你将看到：
“最强工程师”并不等于“最会写代码的人”：真正拉开差距的，是对用户、目标、协作与组织运行逻辑的理解。
技术理想主义为何常常输给现实工程？：赢下技术争论很容易，推动事情落地却极难；立场坚定不如态度灵活。
为什么“清晰”比“精巧”更像资深工程师的标志？：代码是写给凌晨两点接手系统的陌生人的“战略备忘录”。
删代码，比写代码更高级：多数性能优化与稳定性提升，来自消除冗余，而不是不断叠加新功能。
在大厂，代码不会为你发声，只有人会：再好的实现，如果没人理解、没人转述、没人提及，就等于不存在。
抽象不是解药，只是延期付款：技术栈越高，越需要保留对底层故障模式的敬畏。
用户足够多时，连 bug 都会被当成“特性”依赖：真正难的不是修 bug，而是怎么不把用户一起“修没了”。
这不是成功学清单，而是一位长期身处 Google 核心工程体系，在反复碰壁与被点醒之后写下的“少走弯路说明书”。如果你正身处大厂、规模化团队，或正在思考 AI 时代工程师真正不可替代的能力是什么，这篇文章很可能会让你不断点头，也偶尔刺痛。
以下为原文翻译：
谷歌十四年，我学到的“二十一条军规”
十四年前刚加入谷歌那会，我以为自己的工作很简单——写出优秀代码。其实这种理解倒也没错，但待得越久我越意识到那些在谷歌如鱼得水的工程师未必就是最强程序员——相反，他们在代码之外更懂得驾驭其他：人际关系、政治博弈、目标对齐以及灰色地带。
我真希望自己能早点醒悟，这样我就能少遭受一点挫折、少辜负些许韶华。这些跟具体技术无关，毕竟技术迭代太快，根本没那么重要。最关键的是那些在项目持续推进、团队不断更新当中反复显现出的规律。
好在曾有前辈高人对我点拨，让我受益匪浅，所以我决定把这些整理出来。希望这份善意能给大家一点帮助、一点启发。
1. 最优秀的工程师，痴迷于解决用户痛点。
沉迷于某项技术，并四处寻找应用场景确实是种强烈的、难以抵抗的诱惑。曾经的我是这样，人人也都是这样。但那些善于创造最大价值的工程师会采取逆向思维：他们痴迷于深刻理解用户痛点，而解决方案会自然从洞察当中浮现。
这种用户至上的心态，让他们沉浸在支持工单当中、与用户对话、观察用户的挣扎，不断追问“为什么”直到触及核心。真正洞悉问题本质的工程师们常常发现：优雅的解决方案往往比任何高手的纯粹思想实验都更加简单。
而先有答案再去找问题的工程师，会永远在构建复杂性的过程中拼命为自己寻找合理化依据。
2. 坚持己见易如反掌，携手求真方为正途。
我们可以赢尽所有技术争论，却输掉整个项目。我见过太多才华横溢的工程师，他们永远是会议室里最聪明的参与者，却只能默默积攒怨气。问他们为什么结果总是不好，回答只有“执行不力”和“抵触太强、推动不了”。
真正的本事不在于坚持己见，而在于参与讨论时聚焦问题本质，同时注意为他人留出空间、对自身观点保持怀疑。
立场坚定、态度灵活绝不是缺乏信念，而是一种清醒的认识：在无数不确定性当中做出决策时，千万不要把对事的争论跟对人的反感混为一谈。
3. 行动为先，快速发布。糟糕的页面可以修改，空白的页面却无法优化。
追求完美只会让人动弹不得。我见过工程师们拿出几十天去讨论从来没能实现的理想架构。完美方案很少源自纯粹思考，更多诞生自与现实的碰撞。而 AI 在这方面将大有可为。
所以行动为先、再完善，最后优化。别害怕把丑陋的原型展示给用户，别害怕写出凌乱的设计初稿。勇于发布那些让自己难堪但至少已经可行的产品。拿出一周获取真实反馈，远胜过连续一个月的纯理性争论。
动能会让事实清晰，沉迷分析只会让人身心俱疲后无力作战。
4. 清晰即资历，精巧成负担。
工程师们都希望编写出精巧的代码，仿佛这就是对自身能力最直接的证明。
但软件工程本身就是时间与协作的产物。在此等开发场景之下，追求清晰绝非风格偏好，而是在切实降低运营风险。
这里我把话再得明白些：我们的代码，就是发给陌生人的战略备忘录，供他们在凌晨两点面对系统故障时参考以接手维护。所以优化的目标应该是更好地适应他们的理解力，而非代码本身是否精巧。我最敬重的资深工程师们，都明白当清晰与精巧对立时选择前者。
5. 不要为了新奇而新奇——这是一笔将用宕机、人才流失和认知负担偿还的债务。
在选择企业时，一定关注他们是否对技术选型是否敬畏，是否意识到自身能够消化的“新奇配额”极其有限。每次采用非标方案，就会消耗掉其中一部分额度，直至不堪重负。
关键并不在于“停止创新”，而在于“仅在被赋予独特创新价值时才追求新奇”。其余选择则应越中庸越好，这样才能保证潜在后果更可确定、可把控。
所谓“最佳工具”，更多是“在多种场景下最不差的工具”。与之对应，如果你的系统本身已经复杂得如同动物园，那管理的成本可想而知。
6. 代码不会为你发声，只有人会。
在职业生涯早期，我曾以为杰作自会证明价值。事实证明这是错的。代码只会静默躺在代码库里，而主管能在会上提到你、也可以只字不提；同事能推荐你参与项目，也可以提名他人。
在大型组织里，重大决策很可能发生在你未能参与的会议中、基于不由你撰写的摘要，由那些时间紧迫、任务繁重的决策者拍板。如果你不在声，如果无人阐明你的价值，你的存在必然沦为可有可无的选项。
这并非单纯的自我推销，而是让价值链更清晰地展现在所有人——包括我们自己——面前。
7. 不需要写出来的代码，才是最好的代码。
我们颂扬工程文化中的创造精神。删除代码不会获得晋升，但删除却往往比添加更能提升系统效率。每一行不必写出的代码，都代表着少了一份调试、维护或者解释的负担。
在构建之前，请务必认真思考：如果干脆不做，结果会怎样？如果答案是“其实差不多”，那就勇敢放弃。
问题并不在于工程师能不能把这部分代码交给 AI 生成。相反，很多工程师编写代码的本领太过精湛，以致于忘记审视“有没有必要编写”这个根本问题。
8. 只要规模够大，连 bug 都有受众。
当用户基数足够庞大，一切可观察行为都将转化为依赖关系。总有人会抓取你的 API、自动化你的特殊逻辑，甚至把 bug 也缓存起来。
这就是独属于专业人士的知觉：兼容性工作并不只是“维护”，新功能也不一定就更“正经”。相反，兼容性本身就代表着产品。
因此在设计弃用方案时，请尽可能倾注更多时间、工具和同理心。千万别让“API 设计”沦为“API 清退”。
9. 大多数“低效”团队的软肋，在于目标错位。
项目拖延时，人们习惯把问题照片于执行层：员工不够努力啦、技术选型失误啦、工程师人手不足啦。但这些往往并非真正的问题。
在大厂当中，团队是并行工作的基本单元。但随着团队数量的增加，协调成本也呈几何级增长。大部分效率低下实际是协同失败的体现——要么是开发了错误的功能，要么是实现的正确功能之间相互冲突。
资深工程师们花在厘清方向、接口和优先级上的时间，要远多于“加快编程速度”，而真正的区别也在于此。
10. 专注可控之事，忽略不可控之事。
在大型企业中，无数变量终将超出掌控范围——组织架构调整、管理决策、市场波动、产品转型等皆在此列。过度纠结只会徒增焦虑，却又无能为力。
要保持理智高效，工程师们需要专注于自身影响力范围。我们无法控制重组是否发生，但可以掌控工作质量、应对方式并学习收获。在面对不确定性时，应努力将问题拆分为可控的具体行动。
这并非消极妥协，而是强调战略聚焦。耗费在无法改变之事上的精力越多，本该投入可控之事的能量就越少。
11. 抽象化不会消除复杂性，只会推迟问题爆发的时间。
每一次抽象化，都是对“无需理解底层原理”的一次重复和豪赌。有时候我们会赢，但我们终归会办理——等到问题出现，大家最好想清楚自己该如何应对。
即使面对日益高耸的技术栈，资深工程师们仍然持续钻研“底层”知识。这不是在怀旧，而是对抽象失效时刻的敬畏——他们只是不想凌晨三点独自面对系统崩溃。
因此，请善用技术栈，同时务必保留对底层故障模式的深刻认知。
12. 写作让思路更清晰，学习新知识的最快途径就是向他人表达。
写作会迫使我们保持清醒。在向他人阐释概念时——无论是文档、演讲、代码审查评论还是跟 AI 对话等形式——我总能发现自身理解中的漏洞。帮助其他人理解的过程，恰恰也让我自己更好地认清本质。
这不只是在慷慨地分享知识，更是一种非常有益的学习捷径。如果你自认为弄懂了某事，请尝试简要概括——在哪里卡壳了，那里就是大家最需要巩固的部分。
表达和指导，是对自我思维模式的调试。
13. 支撑其他业务的幕后工作虽无价，但往往隐形。
粘合性质的工作——比如编写文档、带新人、跨团队协调、流程优化等——特别特别特别重要。但也千万别陷得太深，它会阻滞技术成长并耗尽精力。所以别把这事理解成“乐于助人”，而应有意识地创造可量化、有边界且有影响力的成果。
设定明确的时间框，轮换执行人员，并把努力转化为可复用的形式：文档、模板、自动化工具等，确保其价值以“影响”而非“善良”的形式呈现。
14. 如果每次都是你的意见胜出，反抗的力量可能正在积蓄。
我学会了对自身坚持的东西保持警惕。当“胜利”来得太轻松，背后往往藏有代价。对方停止争论并不是被说服，而是懒得继续——他们会把抗议体现在行动中，而非会议室里。
建立真正的共识需要更长时间。大家必须真正理解他的视角、采纳反馈意见，甚至甚至得公开改变自己的立场。
压倒他人的短期满足感，其价值远远不及与有意愿的合作者建立起长期而稳固的信任。
15. 当量化标准本身沦为目标，它就失去了衡量的功能。
能让上司们看到的每项指标，最终都会沦为空架子。这倒不一定出于恶意，而是人类天生就会刻意迎合这些量化标准。
如果以代码行数论英雄，那代码量必然膨胀；如果以开发速度为指标，时间表将不再可靠。
资深工程师们会把各项指标匹配起来，综合加以考量。如果其中一项衡量速度，就必须有另一项衡量质量或风险。借此解读趋势，而非盲目认可数据。毕竟这些绩效只是为了积累洞察，而非强加监控。
16. 开诚布公比不懂装懂更能创造安全感。
资深工程师在说“不知道”时并非示弱，而是在争取更大的空间。当领导者承认存在不确定性时，其实也在向团队传递安全信号，提醒大家可以积极质疑。若非如此，就会形成不懂装懂的集体文化，问题终将被掩盖直至集中爆发。
我接触过那种嘴巴特硬的资深从业者，也见证过因此造成的危害。无人敢于发问，因此企业误以为不存在问题。
勇敢展现好奇心，整个团队都将洋溢热烈的学习氛围。
17. 人脉网络比任何工作岗位都更持久。
在职业生涯早期，我专注工作而忽视了人脉积累。现在看来这肯定是个错误。那些注重维系人际关系的同事会持续收获回报：他们率先知晓机会、更多建立联系、获得职位推荐，甚至与多年来建立信任的共同创立企业。
岗位终有尽时，人脉却能永续。当然，请以好奇与慷慨之心经营，而非功利算计。
在迈入人生的新阶段时，人脉往往就是那块敲门砖。
18. 多数性能提升源自消除冗余，而非添加功能。
系统变慢时，人们总想添加缓存层、并行处理或者更智能的算法。当然这也不是错，但我见过的更多优化其实是“我们是不是塞了太多不必要的东西？”
删除冗余部分几乎总要引入加速机制更有效。不需要运行的代码，才是最快的代码。
因此在优化前，请认真考虑这部分代码是否应该存在。
19. 流程的本质是降低不确定性，而非“事过留痕”。
最好的流程应该简化协调并降低失败成本，而最差的流程则是官僚大舞台——其存在不是为了解决问题，而是为了出错时可以推卸责任。
如果没法解释一套流程如何降低风险或提升清晰度，那它很可能只是冗余和负担。
当人们耗费更多时间记录工作、而非真正解决问题时，系统肯定是出了大问题。
20. 终有一天，时间会比金钱更珍贵，请牢记这点。
在职业生涯早期，用时间换取金钱是没问题的。但转折点终将到来，大家会逐渐意识到：时间才是不可再生资源。
我见过资深工程师为了晋升而透支生命，只为争取微薄的薪酬提升。少数人如愿以偿，但事后往往会扪心自问“这值得吗？”
我并不是想否定“努力工作”，而是希望大家认清交易的本质、审慎做出权衡。
21. 没有捷径，只有复利效应。
专业能力源自努力练习，持续突破现有能力的边界、反思并不断重复，数十年如一日。没有速成之道，完全没有。
好消息是：学习和创造的新可能会产生复利效应。比如为了厘清思路而写作，构建可复用的基础模块，将教训转化为价值满满的实战宝典。
只有将职业生涯视为复利累积，工程师们才能获得更远大的成就。
写在最后
这二十一条心得看似繁多，但也可快速归纳为三条核心：保持好奇、保持谦逊，并谨记工作的本质——以人为本，以用户为本，以并肩作战的队友为本。
工程师的职业生涯足够漫长，容得下无数次错误。我最敬佩的工程师并非事事完美之人，而是那些善于从失败中汲取教训、分享成果并始终坚持前行的人，他们终将脱颖而出。
若诸位刚刚踏上征程，请相信岁月会让这份沉淀愈发丰盈；若大家早已深耕其中，也愿这些感情能与你产生共鸣。
原文链接：
