Google 工程师 14 年经验总结：21 条职场生存法则

Addy Osmani 在 Google 待了 14 年。当他刚入职时，他以为工程师的工作就是写出漂亮的代码。他确实没想错，但只对了一半。随着时间推移，他发现那些真正做得好的工程师，未必是编程技术最强的，反倒是那些懂得处理代码之外各种事情的人。人际关系、组织政治、团队协调、模糊情况的应对，这些才是关键。最近，他把这 14 年的经验整理成了 21 条教训，公开分享出来。他说，有些教训如果早点知道，能省下好几个月的挫折。有些道理花了好几年才真正理解。这些经验跟具体技术无关，因为技术变化太快。它们讲的是那些反复出现的规律，不管在哪个项目、哪个团队都适用。下面，我们就来看看这 21 条经验到底说了什么。

一、关于解决问题的本质

第一条经验就很扎心：最优秀的工程师，痴迷的是解决用户的问题，而不是技术本身。很多人容易掉进一个坑，就是先爱上某个技术，然后拼命找地方用它。Addy 说他自己也犯过这个错。但真正创造价值的工程师，做法正好相反。他们会花大量时间去理解用户到底遇到了什么麻烦，然后从这个理解出发，让解决方案自然浮现。这意味着什么呢？就是要去看用户的支持工单，跟用户聊天，观察用户怎么使用产品，不停地问为什么，直到挖到问题的根源。当你真正理解了问题，往往会发现，最优雅的解决方案比你想象的要简单得多。反过来，如果你先有了一个方案，再去找问题来匹配，就会不断增加复杂度，只为了证明这个方案是对的。这个道理放在任何工作里都适用。比如做市场营销，你是先想好要用某个新渠道，然后硬凑理由，还是先搞清楚用户在哪里、他们需要什么信息，然后选择最合适的方式？答案很明显，但实际工作中，我们常常本末倒置。第二条经验同样重要：正确很便宜，但一起达成正确才是真正的工作。你可以在每次技术讨论中都赢，但最后把整个项目输掉。Addy 见过很多聪明的工程师，总是做房间里最聪明的那个人，结果积累了一堆无声的怨恨。这些代价后来会以执行问题、莫名其妙的阻力等形式显现出来。关键技能不是对，而是进入讨论时对准问题，给别人留出空间，并且对自己的确定性保持怀疑。强烈的观点，弱弱地持有。不是因为你缺乏信念，而是因为在不确定的情况下做出的决定，不应该跟自我认同焊接在一起。这让我想起职场里很多冲突。有些人特别擅长辩论，每次开会都能把别人说服，但奇怪的是，项目推进总是不顺利。原因就在这里，你赢了争论，但失去了合作者的意愿。他们表面上同意你，但心里已经不再支持这件事了。真正的高手，会在讨论中让别人感到被尊重，让大家一起找到答案，而不是证明自己是对的。

二、关于行动和清晰度

第三条经验是行动导向：倾向于采取行动，去发布。你可以编辑一个糟糕的页面，但你无法编辑一张白纸。追求完美会让人瘫痪。Addy 见过工程师花几周时间辩论理想的架构，结果连东西都没做出来。完美的解决方案很少从纯粹的思考中诞生，它来自与现实的接触。先做出来，然后做对，然后做得更好。把丑陋的原型给用户看，写出混乱的设计文档初稿，发布让你稍微尴尬的最小可行产品。从一周的真实反馈中学到的，比一个月的理论辩论要多。动量创造清晰。分析瘫痪什么都创造不了。这条经验对所有人都有用。很多时候我们拖延，是因为想等条件完美了再开始。想学英语，就要等买了最好的教材、找到最合适的老师、有了整块的时间。结果永远等不到那一天。其实最好的办法就是先开始，哪怕条件不完美。先每天背 10 个单词，先跟着 app 练发音，先看一集美剧。行动本身会带来反馈，反馈会让你调整方向，慢慢就找到了最适合自己的方法。第四条经验关于清晰度：清晰就是资历，聪明是负担。工程师几乎都有一个本能，就是想写聪明的代码，因为这感觉像是能力的证明。但软件工程的现实是，你写的代码会被其他人在未来很长时间里维护。在这种环境下，清晰不是风格偏好，而是降低运营风险。你的代码是一份给陌生人的备忘录，他们可能在凌晨两点的故障中维护它。优化他们的理解，而不是你的优雅。Addy 最尊敬的资深工程师，都学会了每次都选择清晰而不是聪明。这个道理在日常工作中同样重要。写邮件、写报告、做 PPT，很多人喜欢用复杂的词汇、堆砌专业术语，觉得这样显得专业。但其实，能把复杂的事情说清楚，让外行都能听懂，才是真本事。尤其在团队协作中，如果你的文档、你的说明谁都看不懂，就会增加沟通成本，拖慢整体效率。简单、清晰、直接，永远是最高级的表达方式。

三、关于技术选择和复杂度

第五条经验讲技术选择：新颖性是一笔贷款，你要用故障、招聘和认知负担来偿还。把技术选择当作一个组织，它有一个小的创新代币预算。每次采用一些实质性的非标准技术，就要花掉一个代币。你花不起太多。重点不是永远不创新，而是只在你独特地被付费去创新的地方创新。其他一切都应该默认为无聊的技术，因为无聊的技术有已知的失败模式。所谓最适合工作的工具，往往是跨多个工作的最不坏工具，因为运营一个动物园会成为真正的负担。这个观点特别有意思。我们总觉得用最新的技术、最酷的工具才显得厉害。但实际上，每采用一个新东西，就要付出学习成本、维护成本、出错成本。这就像生活中买东西。有些人喜欢尝试各种新产品，结果家里堆满了用过一次就闲置的东西。而有些人懂得克制，只在真正需要的地方花钱，反而过得更从容。在工作中也一样。不要为了炫技而引入复杂的工具或流程，而要问自己，这个东西真的能解决我们独特的问题吗？还是只是我们觉得新鲜好玩？

四、关于影响力和可见性

第六条经验很现实：你的代码不会为你说话，人会。 Addy 职业生涯早期相信，好的工作会自己说话。他错了。代码静静地躺在仓库里。是你的经理在会议上提到你，或者没提到你。是同事推荐你做某个项目，或者推荐了别人。在大型组织里，决策是在你不在场的会议上做出的，用的是你没写的总结，由那些只有五分钟时间和十二个优先事项的人做出。如果没人能在你不在场时说清楚你的影响，你的影响就等于可选的。这不仅仅是自我推销，而是让价值链对每个人都清晰，包括你自己。这条经验戳中了很多老实人的痛点。我们从小被教育要埋头苦干，觉得只要把事情做好，自然会有人看见。但现实是，如果你不主动让别人知道你在做什么、做得有多好，很可能就会被忽视。这不是说要天天在领导面前刷存在感，而是要学会恰当地展示自己的工作成果。写周报时多一点细节，开会时主动分享你的思考，完成项目后做个简单的总结汇报。这些都是让你的价值被看见的方式。第七条经验更进一步：最好的代码是你从来不需要写的代码。工程文化里我们庆祝创造。没人因为删除代码而升职，尽管删除往往比添加更能改善系统。你不写的每一行代码，都是你永远不需要调试、维护或解释的一行代码。在你构建之前，先穷尽这个问题：如果我们就是不做会怎样？有时答案是不会有坏事发生，那就是你的解决方案。问题不是工程师不会写代码或不会用 AI 写代码，而是我们太擅长写代码了，以至于忘了问自己是否应该写。这个思路特别反直觉，但细想确实有道理。我们习惯了做加法，总想着多做点什么。但很多时候，最好的解决方案是减法，是不做某些事。比如一个产品功能，用户真的需要吗？还是我们自己觉得酷？一个流程环节，真的必要吗？还是只是历史遗留？当你开始问这些问题，会发现很多工作其实可以省掉，效果还更好。

五、关于规模和兼容性

第八条经验讲规模：在规模化时，连你的 bug 都有用户。当用户数量足够多，每一个可观察的行为都会成为依赖，不管你承诺了什么。有人在爬你的 API，自动化你的怪癖，缓存你的 bug。这创造了一个职业级的洞察：你不能把兼容性工作当作维护，把新功能当作真正的工作。兼容性就是产品。用时间、工具和同理心来设计你的废弃计划。大部分 API 设计其实是 API 退休。这条对做产品的人特别有启发。你以为一个小改动没什么，但对于已经依赖旧版本的用户来说，可能是灾难。所以任何改变都要慎重，要给用户足够的过渡时间和替代方案。这就像装修房子，你不能说今天心情好就把墙砸了，得考虑住在里面的人怎么办，怎么让他们平稳地过渡到新环境。

六、关于团队和对齐

第九条经验指出：大部分慢的团队，其实是不对齐的团队。当项目拖延时，本能反应是责怪执行：人们不够努力，技术不对，工程师不够。通常这些都不是真正的问题。在大公司里，团队是你的并发单位，但随着团队增多，协调成本呈几何级数增长。大部分缓慢其实是对齐失败，人们在做错误的事情，或者用不兼容的方式做正确的事情。资深工程师花更多时间澄清方向、接口和优先级，而不是更快地写代码，因为那才是真正的瓶颈所在。这个观察太准确了。很多时候团队效率低，不是因为大家不努力，而是因为大家在往不同的方向用力。每个人都觉得自己在做对的事，但放在一起就乱套了。所以管理者最重要的工作，不是催促大家干活，而是确保大家对目标、对优先级、对做事方式有共识。花时间开会讨论方向，看起来是在浪费时间，实际上是在省时间。第十条经验是心态调整：专注于你能控制的，忽略你不能控制的。在大公司里，无数变量是你控制不了的，组织变动、管理决策、市场变化、产品转向。纠结这些只会产生焦虑而没有作用。保持理智和有效的工程师，会专注于他们的影响范围。你控制不了重组是否发生，但你可以控制工作质量、你的反应方式、你学到了什么。面对不确定性时，把问题分解成碎片，找出你能采取的具体行动。这不是消极接受，而是战略聚焦。花在你无法改变的事情上的精力，是从你能改变的事情上偷走的精力。这条建议对所有人都管用。生活中有太多我们控制不了的事，天气、别人的看法、市场行情、公司政策。如果把精力都花在抱怨这些上，只会让自己更焦虑。聪明的做法是，把注意力放在自己能改变的事情上。不能改变天气，但可以决定今天穿什么衣服。不能改变公司政策，但可以提升自己的能力。这样想，心态会平和很多，也能做出更多实际成果。

总结

文章太长，微博不支持，超过字数限制了。这篇文章整理了 Addy Osmani 在 Google 14 年的工作经验，涵盖了从解决问题的本质、行动和清晰度、技术选择、影响力可见性、规模和兼容性，到团队协作等多个方面的深刻洞察。这些经验不仅适用于工程师，对所有职场人士都有很强的参考价值。核心思想是：专注于解决真正的问题，保持清晰的沟通，做好团队协作，关注自己能控制的事情。 --- 标签: #科技先锋官# #AI创造营# #微博年度新知博主# 来源: 默庵·超级个体微博 发布时间: 2026-01-19