Addy Osmani 是 Google Cloud AI 总监，在 Google 已有 14 年的工作经历。刚入职时，他认为工程师的核心任务就是写出漂亮的代码。这个想法没错，但只对了一半。随着时间推移，他发现那些真正表现出色的工程师，未必是编程技术最强的，而是那些懂得处理代码之外各种复杂事务的人。人际关系、组织协调、应对模糊需求，这些软技能往往才是决定成败的关键。
最近，他将这 14 年积累的洞察总结为 21 条经验教训并公开分享。他表示，有些教训若能早点知晓，足以省下数月的挫折；有些道理则花了数年才真正领悟。这些经验无关具体技术——因为技术迭代太快——它们揭示的是那些在不同项目、不同团队中反复出现的普遍规律。
下面，我们就来详细解读这 21 条经验。
关于解决问题的本质
第一条经验直指核心：最优秀的工程师，痴迷的是解决用户的问题，而非技术本身。
许多人容易陷入一个误区：先爱上某项技术，然后千方百计寻找应用场景。Addy 坦言自己也犯过类似错误。但真正创造价值的工程师，其路径恰恰相反。他们会投入大量精力去理解用户究竟遇到了什么麻烦，并从这个根本理解出发，让解决方案自然浮现。
这意味着什么？你需要去查看用户支持工单、与用户直接交流、观察他们的使用行为，并不断追问“为什么”，直至触及问题的根源。当你真正理解问题后，往往会发现最优雅的解决方案比预想的要简单得多。
反之，如果你先预设了一个解决方案，再为其寻找匹配的问题，就会不断叠加复杂度，只为证明这个方案的正确性。
这个道理放之四海而皆准。无论是市场营销还是产品设计，你是先决定使用某个新潮渠道或工具，还是先搞清楚用户的需求与场景？答案显而易见，但在实际工作中，我们却常常本末倒置。
第二条经验同样关键：正确本身很廉价，但引导团队共同达成正确才是真正的工作。
你或许能在每次技术争论中获胜，却可能因此输掉整个项目。Addy 见过太多聪明的工程师，总是试图成为房间里最聪明的人，结果却在无形中积累了怨恨。这些代价终将以执行障碍、莫名阻力等形式显现。
关键技能不在于“永远正确”，而在于进入讨论时对准问题本身，为他人留出表达空间，并对自己的判断保持适当的怀疑。
持有坚定的观点，但以开放的心态维护它们。 这不是缺乏信念，而是认识到在不确定情况下做出的决策，不应与自我认同捆绑在一起。
这让人联想到职场中的许多冲突。有些人辩论能力极强，总能说服他人，但项目推进却总是不顺。原因正在于此：你赢得了争论，却失去了合作者的真心支持。他们表面赞同，内心却已放弃。
真正的高手，懂得在讨论中让每个人感到被尊重，引导大家共同发现答案，而非单纯证明自己是对的。
关于行动和清晰度
第三条经验强调行动导向：倾向于采取行动，尽快发布。 你可以修改一个糟糕的页面，但无法编辑一张白纸。
追求完美往往导致瘫痪。Addy 见过工程师花数周时间辩论理想架构，结果连可运行的东西都没做出来。完美的解决方案很少源于纯粹的思考，它来自于与现实的碰撞。
先做出来，再做对，然后做得更好。将粗糙的原型展示给用户，撰写思路凌乱的设计稿初版，发布那个让你稍感尴尬的最小可行产品（MVP）。从一周的真实反馈中学到的，远胜于一个月的理论空谈。
动量创造清晰。 而过度分析则只会导致瘫痪，一无所成。
这条经验对每个人都适用。我们常因等待“完美条件”而拖延。想学技能，就要等最好的教材、最合适的时机、整块的时间……结果永远无法开始。
事实上，最好的方法就是立即开始，哪怕条件不完美。先每天背10个单词，先跟着应用练习，先看一集相关视频。行动本身会带来反馈，反馈指引你调整方向，逐步找到最适合自己的路径。
第四条经验关于清晰度：清晰就是资历，聪明反成负担。
工程师几乎都有一种本能：渴望编写“聪明”的代码，因为这像是能力的证明。但软件工程的现实是，你写的代码将在未来很长一段时间内由他人维护。在这种语境下，清晰不是风格偏好，而是降低运维风险的必要手段。
你的代码是留给陌生人的备忘录，他们可能在凌晨两点的告警中试图理解它。请优化他们的理解成本，而非你个人的优雅感。Addy 最为尊敬的资深工程师，都学会了每次都选择清晰而非聪明。
这个道理在日常沟通中同样重要。撰写邮件、报告或演示文稿时，许多人偏爱复杂词汇和专业术语堆砌，认为这样显得专业。实则不然，将复杂事物清晰明了地传达，让外行也能听懂，才是更高的本领。
尤其在团队协作中，如果你的文档或说明令人费解，就会徒增沟通成本，拖慢整体效率。简单、清晰、直接，永远是最高级的表达方式。
关于技术选择和复杂度
第五条经验探讨技术选择：新颖性是一笔贷款，你需用故障、招聘困难和认知负担来偿还。
将技术选择视为一个组织，它拥有一小笔“创新代币”预算。每次采用一项实质性非标准技术，就要消耗一枚代币。你的预算并不充裕。
重点绝非永不创新，而是只在组织独特付费让你创新的领域进行创新。其他一切，都应默认选择那些“无聊”但成熟的技术，因为它们拥有已知的失败模式。
所谓“最适合工作的工具”，往往是能跨越多项工作的“最不坏”工具，因为维护一个技术动物园会成为真正的负担。
这个观点非常深刻。我们总以为使用最新、最酷的技术才显得厉害。但实际上，每引入一项新事物，都意味着要付出学习成本、维护成本和潜在的排错成本。
这就像日常生活购物。有人喜欢尝试各种新奇产品，结果家中堆满只用过一次的闲置品。而懂得克制的人，只在真正必要处投资，生活反而更加从容高效。
工作也是如此。不要为了炫技而引入复杂工具或流程，而要自问：这东西真能解决我们独特的问题吗？还是仅仅因为它新鲜有趣？
关于影响力和可见性
第六条经验很现实：你的代码不会为你说话，但人可以。
Addy 职业生涯早期曾相信，优秀的工作成果自会发声。他错了。代码只是静静地躺在仓库里。是你的经理在会议上是否提及你，是同事是否推荐你负责某个项目。
在大型组织中，许多决策在你缺席的会议上做出，依据的是你未曾撰写的总结，由那些只有五分钟时间和一长串待办事项的人敲定。如果无人能在你不在场时清晰阐述你的贡献，那么你的影响力就变得可有可无。
这不仅仅是自我推销，而是让价值链条对每个人（包括你自己）都清晰可见。
这条经验戳中了许多勤恳工作者的痛点。我们从小被教育要埋头苦干，认为只要事情做好，自然会被看见。但现实是，如果你不主动、恰当地让他人了解你的工作与成果，很可能会被忽视。
这并非要求天天在领导面前刷存在感，而是要学会有效展示：在周报中补充关键细节，在会议上分享你的思考，在项目完成后进行简洁的总结汇报。这些都是让你的价值被“看见”的正当方式。
第七条经验更进一步：最好的代码，是你从未写出的代码。
工程师文化通常庆祝创造。没人会因删除代码而获得晋升，尽管删除往往比添加更能改善系统。你不写的每一行代码，都是未来永远无需调试、维护或解释的一行代码。
在动手构建之前，先彻底审视这个问题：如果我们什么都不做，会怎样？ 有时答案将是“不会有坏事发生”，而这本身就是你的解决方案。
问题不在于工程师不会写代码，或不会用AI辅助写代码，而在于我们太擅长写代码了，以至于忘了问自己：是否真的应该写？
这个思路颇为反直觉，但细想之下极富智慧。我们习惯了做加法，总想着多做点什么。但很多时候，最优解是减法，是克制地不去做某些事。
例如，一个产品功能，用户真的需要吗？一个流程环节，真的必要吗？当你开始提出这些问题，会发现许多工作其实可以省略，效果反而更好。
关于规模和兼容性
第八条经验关于规模：当规模足够大时，连你的Bug都会拥有用户。
当用户基数足够庞大，每一个可观测的行为都会成为他人的依赖，无论你是否承诺过它。总有人在爬取你的API，将你的特性（甚至怪癖）自动化，并缓存你的Bug。
这带来了一个职业级的洞见：你不能将兼容性工作视为“维护”，而将新功能视为“真正的工作”。兼容性本身就是产品。
用时间、工具和同理心去设计你的废弃（Deprecation）计划。大部分API设计工作，实质上是为API的平稳退休做准备。
这条经验对产品决策者极具启发。你认为的一个小改动，对依赖旧版本的用户而言可能是灾难。因此任何变更都需慎之又慎，必须为用户提供充足的过渡时间和清晰的替代方案。
这好比装修房屋，你不能因一时兴起就砸掉承重墙，必须考虑住户如何平稳过渡到新环境。
关于团队和对齐
第九条经验指出：大多数行动缓慢的团队，实质上是未能对齐的团队。
当项目进展迟缓时，本能反应是归咎于执行：人们不够努力、技术选型错误、工程师能力不足。但通常这些都不是根本问题。
在大公司里，团队是并发的执行单位。但随着团队数量增加，协调成本呈指数级上升。大多数缓慢其实源于对齐失败：人们要么在做错误的事，要么在用互不兼容的方式做正确的事。
资深工程师会花费更多时间厘清方向、界定接口和明确优先级，而非更快地编写代码，因为前者才是真正的瓶颈所在。
这个观察极为精准。很多时候团队效率低下，并非因为成员不努力，而是大家在朝不同方向使力。每个人都觉得自己在做正确的事，但合力却相互抵消。
因此，管理者的核心工作之一不是催促执行，而是确保团队对目标、优先级和协作方式达成共识。花时间讨论对齐，看似消耗时间，实则为后续执行节省了大量时间与纠错成本。
第十条经验关乎心态调整：专注于你能控制的事，忽略你无法控制的事。
在大公司中，有无数变量超出你的控制：组织重组、管理决策、市场变化、产品战略转向。纠结于这些只会产生焦虑且毫无益处。
保持理智且高效的工程师，会聚焦于他们的影响圈。你无法控制重组是否发生，但你可以控制工作质量、你的应对方式以及你从中学习到什么。面对不确定性时，将问题分解，找出你能采取的具体行动。
这不是消极接受，而是战略性的聚焦。耗费在你无法改变之事上的精力，正是从你能改变之事上偷走的精力。
这条建议普适性极强。生活与工作中有太多不可控因素：天气、他人看法、市场行情、公司政策。若将精力用于抱怨这些，只会加剧焦虑。
更聪明的做法是，将注意力转向自己能改变的范围。无法改变天气，但可决定衣着；无法改变公司政策，但可提升自身技能。如此思考，心态会更平和，也能产出更多实际成果。
关于学习和成长
第十一条经验谈论抽象：抽象不会消除复杂性，它只是将复杂性转移到了你值班的那个深夜。
每个抽象都是一场赌博，赌你无需理解底层原理。有时你赌赢了，但抽象总有“泄漏”的时候，当它泄漏时，你需要知道自己脚下是什么。
资深工程师即使技术栈越用越高，也会持续学习更底层的知识。这不是出于怀旧，而是出于对抽象失效时刻的尊重——当你在凌晨三点独自面对崩溃的系统时。使用你的技术栈，但对其底层的失败模式保持一个可工作的心智模型。
这个道理非常深刻。我们使用的许多现代工具便捷无比，点击几下就能完成复杂操作。但当问题出现时，如果你不懂基本原理，就会束手无策。
就像驾驶自动挡汽车很方便，但了解基本机械原理，就能在小故障时自行应对，而非只能等待救援。在学习任何技能时，多问一个“为什么”，多了解一点底层逻辑，关键时刻或许就能自救。
第十二条经验关于学习方法：写作迫使清晰。教授是学习某事的最快途径。
当 Addy 尝试向他人解释一个概念时——无论是在文档、演讲、代码评审意见中，甚至只是与AI对话——他总会发现自己理解中的空白。让某事对他人清晰的过程，会让它对自己变得更清晰。
这不仅是慷慨的知识分享，更是一种“自私”的学习技巧。如果你认为自己理解了某件事，尝试用简单的话解释它。你卡壳的地方，正是你理解肤浅之处。
教学，实质是在调试你自己的思维模型。
这个方法我深有体会。曾以为自己掌握了某个概念，但一旦要讲给别人听，就发现逻辑无法自洽。这说明理解并未真正深入。
因此，想要深度学习，可以尝试去教别人，或者将知识写出来。写作过程迫使你理顺思路，补全逻辑链条。当你能用平实的语言阐明复杂事物时，才算真正掌握了它。
第十三条经验关于隐形贡献：使他人工作成为可能的工作是无价的，但也是隐形的。
“胶水”类工作——文档编写、新人培训、跨团队协调、流程改进——都至关重要。但如果你无意识、无边界地承担这些，会拖慢个人技术成长并导致精力耗竭。陷阱在于将其视为“帮忙”而非一项深思熟虑、有界限、可见的影响力工作。
为这类工作设定时间限制，进行轮值，并将其转化为可展示的成果：完善的文档、可复用的模板、自动化脚本。同时，确保其作为影响力而非单纯的“性格特质”被看见。
无价且隐形，这对你的职业生涯而言是一个危险的组合。
这条道出了许多人的困境。有些人乐于助人，总在做那些没人愿做但必需的事务。这些事情很重要，却难以获得认可。
该怎么办？Addy 的建议是，让这些工作“可见化”，将其转化为可展示的产出。例如，整理出一套优秀的文档规范，设计一套高效的新人 onboarding 流程。同时，必须设定边界，不能无限制地投入，以免影响核心职责与个人成长。
关于决策和衡量
第十四条经验关于自我反思：如果你赢得了每一场辩论，你可能正在积累无声的抵抗。
Addy 学会了对自己的“确定性”保持怀疑。当他赢得过于轻松时，通常意味着有些地方不对劲。人们停止争论，不是因为你说服了他们，而是因为他们放弃了尝试，并将在执行阶段（而非会议中）表达分歧。
真正的共识对齐需要更长时间。你必须真正理解不同观点，采纳反馈，有时甚至需要公开改变主意。
短期内“正确”的感觉，其价值远不如长期与一群意愿相投的伙伴共同构建事物。
这点极易被忽视。有些人辩论能力超群，总能说服别人，却未意识到他人只是表面服从。这种虚假共识比公开分歧更危险，因为它将问题隐藏起来，直至执行阶段爆发。
真正的领导力，是让他人心甘情愿地追随，而非口服心不服。这需要耐心倾听、开放心态，以及敢于承认错误的勇气。
第十五条经验关于指标：当一个度量标准成为目标时，它就不再是一个好的度量标准了。
你向管理层暴露的每一个指标，最终都可能被操纵。 这不是出于恶意，而是因为人类会优化那些被衡量的东西。
如果你追踪代码行数，就会得到更多的代码行。如果你追踪开发速度，就会得到膨胀的工期预估。
更高级的做法是：面对每一个指标请求，用一组配对指标来回应。一个关乎速度或数量，另一个则关乎质量或风险。然后，坚持解读趋势，而非崇拜某个绝对阈值。目标是获得洞察，而非进行监控。
这个现象无处不在。你考核什么，人们就会优化什么，无论那是否真正重要。考核销售额，可能导致低价甩货；考核文章阅读量，容易催生标题党。
因此，设定考核标准需格外谨慎，最好用多个相互制衡的维度，而非单一指标。更重要的是，关注趋势与过程，而非仅仅盯住数字本身。
第十六条经验关于诚实：承认你不知道的事，比假装知道能创造更多的安全感。
敢于说“我不知道”的资深工程师，不是在展示弱点，而是在创造一种许可。当领导者承认不确定性时，意味着房间里的其他人也可以这样做。而另一种替代文化则是：每个人都假装理解，问题被隐藏，直至爆发。
Addy 见过从不承认困惑的团队所带来的危害：问题不被提出，假设不被挑战，初级工程师保持沉默，因为他们假定其他人都懂。
示范你的好奇心，你将得到一个真正在学习、在成长的团队。
这条经验适用于任何层级。很多时候我们不敢承认无知，是害怕显得无能。但实际上，不懂装懂更为危险。你假装明白，别人也不敢提问，问题便如滚雪球般积累。
真正的自信，是敢于承认知识的边界。当你说“这部分我不太懂，能否详细讲讲？”，不仅不会贬低你的地位，反而会赢得尊重。因为这展现了你的真诚、好学与务实。
关于长期视角
第十七条经验谈论人脉：你的人脉网络将比你做过的任何一份工作都更持久。
职业生涯早期，Addy 专注于工作本身，忽视了人际网络的经营。回顾往事，他认为这是一个失误。那些在关系建设上有所投入的同事，在几十年后仍在持续收获回报。
他们最先获悉机遇，能更快地搭建桥梁，获得角色推荐，并与多年建立的、互相信任的伙伴共同创业。
你的工作可能不是永恒的，但你的人脉网络可以。 请带着好奇心与慷慨之心去培育它，而非急功近利的交易心态。
当需要转变时，为你打开新大门的，往往是关系。
这条建议年轻时不易体会，工作数年后便会深有感触。许多机会并非来自招聘网站，而是源于相识之人。许多难题并非独自解决，而是得益于朋友相助。
因此，请真诚对待每一位合作者，保持联系，互相支持。不必功利性地“搭建人脉”，而是自然地建立真诚、互利的关系。这些关系会在你意想不到的时刻发挥作用。
第十八条经验回到技术优化：大多数性能提升来自于移除不必要的工作，而非增加更聪明的逻辑。
当系统变慢时，本能反应是增加：缓存层、并行处理、更精妙的算法。有时这确实是正解。但 Addy 见过更多案例中，性能提升源于一个简单提问：我们正在计算哪些本不需要的东西？
删除不必要的工作，几乎总是比更快地执行必要工作更有影响力。最快的代码，是那些从未被执行的代码。
在着手优化之前，先质疑这项工作是否应该存在。
这个思路可以推广至所有领域。当你感觉效率低下时，第一反应不应是“如何做得更快”，而应是“如何做得更少”。哪些会议可以取消？哪些报告无人阅读？哪些流程环节纯属冗余？
做减法往往比做加法更有效，但这需要更大的勇气与洞察力。
第十九条经验关于流程：流程的存在是为了降低不确定性，而非创建纸面路径。
最好的流程让协作更顺畅，让失败的成本更低廉。最糟糕的流程则是官僚主义的表演，其存在不是为了帮助工作，而是为了在出错时划分责任。
如果你无法解释一个流程如何降低风险或增加清晰度，那么它很可能只是一个负担。
如果人们花费在记录工作上的时间超过了实际工作的时间，那一定出了大问题。
这条说得非常在理。许多公司的流程日益繁琐，事事需要层层审批、填写无数表格、召开无数会议。美其名曰规范管理，实则是在制造效率黑洞。
好的流程应当简化工作，而非增加障碍；应当提供清晰指引，而非处处设限。如果一个流程的主要功能是“划清责任、规避风险”，那么就到了重新审视它的时候了。
第二十条经验是价值观的转变：最终，时间将变得比金钱更珍贵，请依此调整你的行动。
职业生涯初期，你用时间交换金钱与经验，这无可厚非。但在某个节点上，这个等式会发生反转。你开始意识到，时间是唯一的、不可再生的稀缺资源。
Addy 见过资深工程师为追求下一个职级或几个百分点的加薪而耗尽心力。有些人得到了，但许多人后来反思：这值得他们为此放弃的一切吗？
答案并非不要努力工作，而是要清楚你正在用时间交易什么，并有意识、深思熟虑地进行这场交易。
这个转变每个人或早或晚都会经历。年轻时觉得赚钱至上，不惜加班牺牲健康与生活。到了一定阶段，会发现健康、家庭、个人志趣远比额外的收入更重要。
关键在于尽早意识到这一点，而非在失去后才追悔莫及。工作重要，但它并非生活的全部。学会平衡，方能行稳致远。
最后一条经验
第二十一条经验关于长期主义：成长没有捷径，但复利效应真实存在。
专业知识源于刻意练习——持续挑战略高于当前能力的任务，进行反思，然后重复。这一过程需要经年累月的坚持，并无浓缩版本。
但这里有充满希望的部分：当学习能创造新的可能性，而不仅仅是新增琐事时，它就会产生复利。 写作，不是为了流量，而是为了理清思路。构建可复用的基础组件。将踩过的“坑”总结成可避开的“剧本”。
将职业生涯视为一场复利投资而非彩票的工程师，往往走得更远。
这最后一条，或许最为重要。当下时代充斥着“速成”的诱惑：三天学会XX，一月精通XX。但真正的成长从来无法速成，它依靠的是日积月累。
关键在于找到能产生复利的学习方式：不是机械重复，而是让每次学习都能在既有知识体系上叠加，形成独特的认知框架与方法论。
坚持写作总结，坚持将经验转化为可复用的模式。如此坚持十年，你与同龄人的差距将清晰可见。
一个最终思考
Addy 表示，这 21 条经验听起来不少，但归根结底围绕几个核心理念：保持好奇，保持谦逊，并始终记住，工作终究是关于人的——包括你为之构建产品的用户，以及与你并肩构建的队友。
工程职业生涯足够漫长，足以容纳许多错误，同时仍能走向成功。他最钦佩的工程师，并非那些从不犯错的人，而是那些能从错误中学习、乐于分享所知、并始终保持前行动力的人。
如果你刚刚启程，要知道这条路将随时间推移而愈发丰厚。如果你已行走多时，希望这些经验能引起你的共鸣。
读完这 21 条，最深的感受是：这些智慧不仅适用于软件工程师，也适用于任何领域的从业者。解决真实问题、保持清晰沟通、聚焦可控之事、持续学习与分享、建立真诚关系、平衡工作与生活……这些都是通用的人生与职业智慧。
技术终会过时，但这些关于如何有效工作、如何与人协作、如何持续成长的洞察，将历久弥新。
原文地址：https://addyosmani.com/blog/21-lessons/
这些关于软件工程本质与工程师成长的深度思考，非常适合在开发者广场与同行们进一步探讨。同时，深入理解计算机基础原理，是应对复杂抽象和系统故障的坚实根基。欢迎在云栈社区分享你的实践经验与见解。
发表于 4 天前
|
查看: 13|
回复: 0
