21 Lessons From 14 Years at Google
转发分享
2026年1月3日
大约 14 年前加入谷歌时，我以为这份工作就是写出优秀的代码。我只对了一部分。随着待的时间越长，我越发意识到：那些茁壮成长的工程师未必是编程技术最好的，而是那些懂得如何驾驭代码之外一切事物的人——包括人、政治、目标对齐以及模糊性。
这些是我希望自己能早点知道的经验教训。有些本来可以帮我省去几个月的挫折，有些则花了我好几年才完全领悟。这里没有关于具体技术的建议——技术变化太快，并不重要。这些经验关于那些在不同项目、不同团队中反复出现的模式。
我分享这些是因为我曾从那些为我指路的前辈工程师那里受益良多。就把这当作我的一次薪火相传吧。
1. 最优秀的工程师痴迷于解决用户问题。
爱上一项技术并到处寻找它的应用场景，这种做法很诱人。我干过，大家都干过。但那些创造最大价值的工程师是逆向工作的：他们痴迷于深度理解用户的问题，让解决方案从这种理解中自然浮现。
“用户痴迷”意味着花时间处理客服工单，与用户交谈，观察用户在使用中的挣扎，不断追问“为什么”，直到触及问题的本质。真正理解问题的工程师往往会发现，优雅的解决方案比任何人预期的都要简单。
而那些从解决方案出发的工程师，往往为了证明方案的合理性而制造复杂性。
2. 单纯的“正确”很廉价，共同达成“正确”才是真本事。
你可能赢了每一次技术争论，却输掉了整个项目。我见过才华横溢的工程师因为总是做房间里最聪明的人而招致沉默的怨恨。这种代价日后会以“神秘的执行问题”和“奇怪的阻力”显现出来。
关键技能不在于你是对的，而在于进入讨论以对齐问题，给他人留出空间，并对自己确信的事情保持怀疑。
观点鲜明，但心态开放（Strong opinions, weakly held）——这并非因为你缺乏信念，而是因为在不确定性下做出的决策不应与个人身份绑定。
3. 行动至上。发布产品。你可以修改糟糕的页面，但无法修改空白的页面。
追求完美会导致瘫痪。我见过工程师花了数周时间争论他们从未构建过的东西的理想架构。完美的解决方案很少来自纯粹的思考——它来自与现实的碰撞。人工智能在很多方面对此都有帮助。
先做出来，再做对，最后做更好。把丑陋的原型放到用户面前。写下设计文档那凌乱的初稿。发布那个让你感到有点尴尬的 MVP（最小可行性产品）。你从一周的真实反馈中学到的东西，比一个月的理论辩论还要多。
动能创造清晰度。分析瘫痪一无所获。
4. 清晰度代表资历。炫技是累赘。
写出“聪明”代码的本能在工程师中几乎是普遍存在的。这感觉像是能力的证明。
但软件工程是当你加上“时间”和“其他程序员”这两个变量后发生的事情。在那种环境下，清晰不是一种风格偏好——它是降低运维风险的手段。
你的代码是写给那些在凌晨 2 点故障期间维护它的陌生人的战略备忘录。请优化他们的理解成本，而不是你的优雅程度。我最尊敬的资深工程师都学会了永远用清晰去交换炫技。
5. 新奇技术是一笔贷款，你将用故障、招聘难度和认知负担来偿还。
把你对技术的选择看作是一个只有少量“创新筹码”预算的组织。每当你采用某种非标准技术时，就花掉一个筹码。你负担不起太多。
重点不是“永远不要创新”，而是“只在你能获得独特回报的地方创新”。其他一切都应默认为无聊的技术，因为无聊的技术有已知的故障模式。
“最适合工作的工具”往往是“在许多工作中表现最不坏的工具”——因为维护一个像动物园样复杂的环境才是真正的重税。
6. 代码不会为你代言，人会。
在职业生涯早期，我相信优秀的作品会为自己说话。我错了。代码只是静静地躺在仓库里。你的经理要在会议上提及你，或者不提及。同事会推荐你参与项目，或者推荐别人。
在大型组织中，决策是在你没被邀请的会议上做出的，使用的是你没写的摘要，由那些只有五分钟时间和十二个优先事项的人决定的。如果当你不在场时没有人能阐述你的影响力，那么你的影响力实际上就是可有可无的。
这不仅是关于自我推销。这是为了让价值链对每个人——包括你自己——都清晰可见。
7. 最好的代码是你没写的代码。
我们在工程文化中推崇创造。没人会因为删代码而升职，尽管删除往往比增加更能改善系统。你没写的每一行代码，都是你永远不需要调试、维护或解释的一行。
在构建之前，先穷尽这个问题：“私如果我们干脆……不做会怎样？”有时答案是“没什么坏处”，那就是你的解决方案。
问题不在于工程师不会写代码或不会用 AI 写代码。问题在于我们太擅长写代码，以至于忘记了问自己是否应该写。
8. 规模化之后，即便是你的 Bug 也有用户依赖。
当用户足够多时，每一个可观察到的行为都会变成依赖项——不管你是怎么承诺的。有人在抓取你的 API，自动化你的怪癖，缓存你的 Bug。
这产生了一个职业层面的洞察：你不能把兼容性工作视为“维护”，而把新功能视为“真正的工作”。兼容性就是产品。
把你对旧功能的弃用设计成带有时间缓冲、工具支持和同理心的迁移过程。大多数“API 设计”实际上是“API 退休设计”。
9. 大多数“慢”团队其实是目标未对齐的团队。
当项目拖延时，本能反应是责怪执行力：大家工作不够努力，技术选型错了，工程师不够。通常这些都不是真正的问题。
在大公司里，团队是并发单元，但随着团队数量的增加，协调成本呈几何级数增长。大多数缓慢实际上是对齐失败——大家在做错误的事情，或者用不兼容的方式做正确的事情。
资深工程师花更多时间在澄清方向、接口和优先级上，而不是“更快地写代码”，因为那才是真正的瓶颈所在。
10. 关注你能控制的，忽略你不能控制的。
在大公司里，无数变量都在你的控制之外——组织变革、管理层决策、市场转变、产品转型。纠结于这些只会产生焦虑，却无法采取行动。
那些保持理智和高效的工程师专注于他们的影响圈。你无法控制重组是否发生。你可以控制你的工作质量、你的反应以及你学到了什么。面对不确定性时，把问题拆解，找出你可以采取的具体行动。
这不是被动接受，而是战略聚焦。花在无法改变之事上的精力，是从你可以改变之事上偷走的。
11. 抽象层不会消除复杂性，只会把它推迟到你值班的那一天。
每一个抽象层都是一个赌注，赌你不需要理解底层是什么。有时你赌赢了。但总有东西会泄漏，当泄漏发生时，你需要知道你站在什么之上。
资深工程师即使在技术栈越来越高层时，也会坚持学习“底层”知识。不是出于怀旧，而是出于对那个抽象层失效、凌晨 3 点你独自面对系统时刻的尊重。使用你的技术栈。
但要保持对其底层故障模式的理解模型。
12. 写作倒逼清晰。最好的学习方式是试着教别人。
写作强迫你理清思路。当我想向别人解释一个概念时——无论是在文档中、演讲中、代码审查评论中，甚至只是与 AI 聊天——我会发现自己理解上的漏洞。把东西向别人解释清楚的过程，也让我自己看得更清楚。
这并不意味着你能通过教别人做手术来学会做手术，但在软件工程领域，这个前提在很大程度上是成立的。
这不仅是对知识的慷慨。这是一种自私的学习黑客技巧。如果你认为你理解了某件事，试着简单地解释它。你卡住的地方，就是你理解浅薄的地方。
教学是在调试你自己的思维模型。
13. 成就他人的工作是无价的——也是隐形的。
胶水工作（Glue work）——文档、入职培训、跨团队协调、流程改进——至关重要。但如果你无意识地做这些，它可能会阻碍你的技术发展轨迹并让你精疲力竭。陷阱在于把它当作“乐于助人”来做，而不是把它当作经过深思熟虑、有边界、可见的影响力。
给它设定时间限制（Timebox）。轮流做。把它转化为产出物：文档、模板、自动化工具。并让它作为影响力被看到，而不是作为性格特征。
“无价”且“隐形”对你的职业生涯来说是一个危险的组合。
14. 如果你赢了每一场辩论，你可能正在积累沉默的抵触情绪。
我学会了对自己确信的事情保持怀疑。当我“赢”得太容易时，通常是有问题的。人们停止反驳你并不是因为你通过说服了他们，而是因为他们放弃了尝试——他们会在执行中而不是会议上表达这种分歧。
真正的对齐需要更长时间。你必须真正理解其他观点，整合反馈，有时甚至要公开改变主意。
短期内“我是对的”这种感觉，远不如长期建立与有意愿的合作者共事的现实更有价值。
15. 当度量指标成为目标时，它就失去了度量的意义。
你向管理层展示的每一个指标最终都会被利用（Gamed）。并非出于恶意，而是因为人类会针对被度量的东西进行优化。
如果你追踪代码行数，你会得到更多代码行。如果你追踪开发速度（velocity），你会得到虚高的估算。
资深的做法：用成对指标来回应每一个指标要求。一个针对速度，一个针对质量或风险。然后坚持解读趋势，而不是盲目崇拜阈值。目的是获得洞察，而不是监控。
16. 承认自己不知道比假装知道更能带来安全感。
说“我不知道”的资深工程师不是在示弱——他们是在给予许可。当领导者承认不确定性时，它向房间里的其他人发出信号：这样做是安全的。另一种选择是一种大家都假装理解的文化，问题被掩盖直到它们爆炸。
我见过最资深的人从不承认困惑的团队，也见过其造成的损害。问题没人问。假设没人挑战。初级工程师保持沉默，因为他们以为其他人都懂。
树立好奇心的榜样，你会得到一个真正学习的团队。
17. 你的人脉比你任何一份工作都长久。
在职业生涯早期，我专注于工作而忽视了人脉。事后看来，这是个错误。那些投资于关系——公司内部和外部——的同事获得了长达几十年的回报。
他们最先听到机会，能更快地建立桥梁，被推荐担任职位，并与多年来建立信任的人共同创立企业。
你的工作不是永远的，但你的人脉是。带着好奇心和慷慨去经营它，而不是交易性的投机。
当需要离开的时候，往往是人际关系为你打开大门。
18. 大多数性能提升来自减少工作量，而不是增加技巧。
当系统变慢时，本能反应是做加法：缓存层、并行处理、更智能的算法。有时这是对的。但我见过更多的性能胜利来自问这个问题：“我们在计算什么不需要计算的东西？”
删除不必要的工作几乎总是比更快地做必要的工作更有效。最快的代码是永远不运行的代码。
在你优化之前，先质疑这项工作是否应该存在。
19. 流程的存在是为了减少不确定性，而不是为了留存书面证据。
最好的流程让协作更容易，让失败的代价更低。最坏的流程是官僚主义的表演——它的存在不是为了提供帮助，而是在出问题时用来推卸责任。
如果你不能解释一个流程如何降低风险或增加清晰度，它可能只是累赘。
如果人们花在记录工作上的时间比做工作本身还多，那就说明出了大问题。
20. 最终，时间比金钱更宝贵。请据此行事。
在职业生涯早期，你用时间换金钱——这没问题。但在某个时刻，计算公式会反转。你开始意识到时间是不可再生资源。
我见过资深工程师为了追求下一个晋升等级而透支自己，只为优化那几个百分点的薪酬涨幅。有些人得到了。大多数人在那之后都在想，这是否值得他们放弃的东西。
答案不是“不要努力工作”。而是“知道你在交换什么，并深思熟虑地进行交换。”
21. 没有捷径，但有复利。
专业技能来自刻意练习——稍微超出你目前的能力范围，反思，重复。持续数年。没有浓缩版。
但这里有充满希望的部分：当学习创造新选项而不仅仅是新琐事时，它会产生复利。写作——不是为了流量，而是为了清晰。构建可复用的原语。将“伤疤组织”收集成剧本（Playbooks）。
那些将职业生涯视为复利而非彩票的工程师，往往最终会走得更远。
最后的想法
21条经验听起来很多，但它们实际上归结为几个核心思想：保持好奇，保持谦逊，并记住工作永远是关于人的——你为之构建产品的用户，以及与你一起构建产品的队友。
工程职业生涯足够长，足以让你犯很多错误并依然能脱颖而出。我最钦佩的工程师不是那些做对了一切的人——而是那些从错误中学习、分享他们发现的东西并坚持在场的人。
如果你正处于旅程的早期，要知道随着时间的推移，它会变得更加丰富。如果你已经深耕其中，我希望这些能引起你的一些共鸣。