原文：https://addyosmani.com/blog/21-lessons/

大约 14 年前我加入 Google 时，我以为这份工作的核心是写出优秀的代码——这个想法部分正确。待得越久，我越清楚地意识到：真正发展得好的工程师，未必是最强的程序员，而是那些学会如何应对代码之外一切的人——人、组织政治、目标对齐，以及不确定性。

这些经验都是我希望自己更早知道的。有些本可以让我少走几个月弯路，有些则花了好几年才真正想明白。它们几乎都不涉及具体技术，因为技术变化太快，不值得执着。真正重要的是那些一再出现的模式，在一个又一个项目、一个又一个团队中反复上演。

我把它们分享出来，是因为我自己也从前辈工程师的分享中受益良多。这算是一次“传递善意”。

1. 最好的工程师，对解决用户问题近乎执念

迷恋某种技术、再去寻找应用场景，很容易让人沉溺其中。我也做过，几乎所有人都做过。但真正创造巨大价值的工程师，会反向思考：先深入理解用户问题，再让解决方案自然浮现。

这种对用户的执念，意味着花时间看工单、和用户交流、观察用户受挫的过程，不断追问“为什么”，直到触及根本。真正理解问题的工程师，往往会发现，优雅的解法比任何人预想的都要简单。

工程师如果一开始就想着如何解决问题，往往会为了寻找理由而人为地增加复杂性。

2. 争论技术正确与否很廉价，共同达成目标才是真正的工作

你可以在每一次技术争论中获胜，却输掉整个项目。我曾亲眼目睹一些才华横溢的工程师，因为总是自诩为房间里最聪明的人，而默默地积攒怨气。这种怨气最终会在后期以“莫名其妙的执行问题”和“莫名其妙的阻力”的形式显现出来。

真正的能力不在于证明自己永远正确，而在于进入讨论时先对齐问题，为他人留出空间，并对自己的确定性保持怀疑。

要有强烈的观点，同时保持可修正性。原因不在于缺乏信念，而在于不确定条件下做出的决定，不该和个人身份牢牢绑定。

3. 行动优先，先发布再说

完美主义会让人停滞不前。我见过工程师为一个从未实现过的系统，争论数周“最理想的架构”。完美方案很少靠纯思考诞生，它来自现实的反馈。AI 在这里也能提供帮助。

先做出来，再做对，最后再优化。把丑陋的原型交到用户手中，写下杂乱的设计初稿，发布一个让自己略感尴尬的 MVP。来自真实反馈的一周学习，胜过一个月的纸上谈兵。

动能会带来清晰感，分析瘫痪只会留下空白。

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. 没有捷径，但有复利

专业能力来自刻意练习：略微超出当前水平、反思、重复，多年如一日，没有速成版。

乐观的一面在于：当学习带来新选择，而非零散知识时，它会产生复利效应。写作追求清晰而非流量，构建可复用的基础模块，把踩过的坑整理成手册。

把职业当作复利而非彩票的人，往往能走得更远。

最后的想法

二十一条看似很多，实则归结为几点：保持好奇、保持谦逊，记住工程工作的核心始终是人——你服务的用户，以及与你并肩的同事。

工程师的职业生涯足够长，可以犯下许多错误，依然取得不错的结果。我最敬佩的工程师，并非从未犯错的人，而是那些从错误中学习、分享所得、持续投入的人。

如果你正处在早期阶段，请相信它会随时间变得愈发丰厚；如果你已经走了很远，希望其中一些能与你产生共鸣。