在 Google 的 14 年:我希望更早懂得的 21 条职场与工程经验
我大约 14 年前加入 Google 时,以为这份工作的核心就是写出漂亮的代码。我只说对了一半。待得越久,我越清楚:真正能持续做出成果、走得更远的工程师,未必是最会写代码的人,而是那些懂得如何在“代码之外的世界”里前行的人——人、组织的博弈、共识、对齐、以及不确定性。
这些经验,是我更希望自己早点知道的事。有些能让我少走几个月弯路,有些则花了好几年才真正体会。它们基本不涉及具体技术——技术迭代太快,不值得写进“人生经验”。它们更像一组反复出现的规律:一段段项目、一个个团队里,总会再遇见。
我愿意分享出来,是因为一路上我也受益于前辈们的“传灯”。你可以把它当作我对这种善意的回礼。
1. 最好的工程师,痴迷于解决用户问题
迷恋技术很容易:喜欢某个新工具,于是到处找场景套上去。我也做过,几乎人人都做过。但真正创造巨大价值的工程师往往反着来:先深挖用户问题,等你把问题看得足够清楚,解决方案会自然长出来。
所谓“用户视角”,不是口号。它意味着你会去看工单、去听客服录音、去和用户聊、去观察用户卡在哪里,然后不断追问“为什么”,直到挖到最底层的原因。真正理解问题的人,常常会发现:最优雅的解法,反而比大家想象得更简单。
相反,从“我有个解法”出发的人,往往会在“找理由”这件事上越做越复杂。
2. “我说得对”不重要;“大家一起做对”才是难点
你可以在技术争论里次次赢,但项目依然会输。我见过很多极聪明的工程师,因为总在会议里当“最聪明的人”,慢慢积累了看不见的怨气。代价会在后面以各种方式浮现:莫名其妙的推进困难、奇怪的阻力、执行上的“各种不配合”。
真正的能力不是“证明自己对”。而是把讨论带回“问题本身”,让他人也能参与其中,同时对自己的确定性保持怀疑。
“强观点,弱持有”并不是没立场,而是承认:在不确定性里做决策,不该把观点焊死在身份上。
3. 行动优先:做出来、发出去。烂页面能改,空白页改不了
追求完美最容易把人困住。我见过工程师为了一个还没做出来的东西,花几周争论“最理想的架构”。但所谓“完美方案”很少靠思考就能得出,它来自现实的反馈——你必须先把东西放进现实里碰一碰。AI 在很多时候也能帮助你更快完成“先做出来”这一步。
先做出来,再做对,再做得更好。把难看但可用的原型给用户看;把乱一点的设计稿先写出来;把让自己略微尴尬的 MVP 发出去。你从一周真实反馈里学到的,往往比一个月的纸上推演更有价值。
动起来才会有清晰;一直分析只会什么都没有。
4. 清晰就是资深;聪明往往是成本
写“很巧妙”的代码,是工程师几乎都会经历的冲动,因为那像是在证明自己很厉害。
但软件工程的本质,是“时间 + 其他人”共同作用后的结果。放进这个环境里,清晰不是风格偏好,而是降低运行风险的手段。你的代码,本质上是一份写给陌生人的“策略备忘录”——他们可能在凌晨两点系统故障时接手维护。请为他们的理解而优化,而不是为自己的优雅而优化。真正厉害的资深工程师,往往每次都愿意用清晰换掉聪明。
5. 新奇技术是一笔贷款,要用宕机、招人难、认知负担来还
把技术选型想象成有“创新代币预算”的组织:每用一次明显非主流的东西,就花掉一枚代币。你花不起太多。
这并不是说“永远别创新”,而是“只在你真正需要、且值得你承担代价的地方创新”。其他地方尽量“无聊”,因为无聊的技术有成熟的故障模式。
“最适合当前场景的工具”常常不是最优选;真正的最优解往往是“在很多场景里都不算完美,但综合最不差的那个”,否则你最后要运营的是一个技术动物园——那才是最大的税。
6. 代码不会替你说话,只有人会
早年我也相信“好作品会自己发声”。事实证明,我错了。代码安静地躺在仓库里;你能否被看见,取决于:你的经理是否在会议里提到你,你的同事是否愿意推荐你,关键项目是否有人想起你的贡献。
在大组织里,很多决策发生在你不在场的会议里,依据的是你没写过的总结;做决定的人可能只有五分钟,手头还有十二件更急的事。如果当你不在场时,没有人能清楚地讲出你的价值,你的影响力就等于“可有可无”。这不只是“自我宣传”。它更像是:让价值链对所有人可读——包括你自己。
7. 最好的代码,是你根本不需要写的那段
工程文化喜欢“创造”,却很少奖励“删掉”。但删代码往往比加代码更能改善系统。每一行你不写的代码,都意味着:少一行要调试、要维护、要解释的负担。
在动手之前,先把这个问题问到极致:“如果我们就……不做,会怎样?”很多时候答案是“也没什么严重后果”,那就是你的解决方案。
问题不在于工程师写不出代码、或 AI 不能帮你写;问题在于我们太擅长写,以至于忘了先问:我们到底该不该写。
8. 当规模足够大,你的 bug 也会有用户
用户足够多时,每一个可观察的行为都会变成依赖——不管你承诺过没有。总有人在抓你的 API、自动化你的“奇怪特性”、缓存你的 bug。
这带来一个职业级洞见:你不能把兼容性当作“维护”,把新功能当作“正事”。兼容性本身就是产品。
所以弃用(deprecation)要按“迁移”来设计:给时间、给工具、给同理心。很多所谓“API 设计”,其实是“API 退休”。9. 多数“慢团队”,其实是“没对齐的团队”
项目拖延时,人们第一反应是怪执行:不够努力、技术不行、人手不够。通常这些都不是根因。
在大公司里,团队是并发的单位,但团队一多,协调成本会几何级增长。很多“慢”,其实是对齐失败:大家在做错的事,或做对的事却接口不兼容。资深工程师把大量时间花在澄清方向、定义接口、统一优先级上,而不是“把代码写得更快”,因为真正的瓶颈往往就在那里。
10. 专注可控之事,忽略不可控之物
大组织里,有太多变量你控制不了:重组、管理决策、市场变化、产品转向。沉溺于这些只会带来焦虑,却没有行动。
能长期保持有效的人,会把注意力收回到自己的影响范围。你控制不了是否重组,但你能控制自己的输出质量、自己的应对方式、以及你从中学到什么。面对不确定,把问题拆小,找出你能采取的具体动作。
这不是消极接受,而是一种策略性聚焦:把精力花在你改变得了的地方。
11. 抽象不会消除复杂度,只是把复杂度推迟到你值班那天
每一个抽象都是一次赌:你赌自己不需要理解底层。你有时会赢,但总会有东西泄漏;一旦泄漏,你可能在凌晨三点独自面对系统。
资深工程师会在栈越来越高的同时,持续学习“更底层”的东西。不是怀旧,而是敬畏:当抽象崩溃时,你得知道自己站在什么上面。用好你的技术栈。
但也要对它的失效模式有一个可工作的心智模型。
12. 写作带来清晰;教别人,是最快的自我学习
写作迫使你把模糊的理解变清晰。当我试图向别人解释一个概念——写文档、做分享、在 code review 里留言,甚至只是和 AI 聊一聊——我会立刻发现自己理解中的漏洞。把东西讲到别人能懂,也就让自己更懂。
这并不意味着你能靠“教”学会当外科医生,但在软件工程领域,这条规律大体成立。
这不只是慷慨分享,更是一种自利的学习捷径:如果你觉得自己懂了,试着用最简单的话讲一遍;你卡住的地方,就是你理解最浅的地方。教学,其实是在调试你的心智模型。
13. 让其他工作得以发生的“底层劳动”,无价但隐形
“胶水工作”——文档、入职培训、跨团队协调、流程改进——非常关键。但如果你不自觉地一直做,它会拖慢你的技术成长路径,也会让你耗尽精力。陷阱在于:你把它当成“人好”,而不是把它当作“有边界、可见的影响力”。
给它设时间盒;轮换承担;把它沉淀成产物:文档、模板、自动化。并且让它能被清楚地看见:这是贡献,不是性格标签。
“无价且隐形”,对职业发展很危险。
14. 如果你每次争论都赢,你很可能在积累沉默的阻力
我学会对自己的确定性保持警惕:当我“赢”得太容易,往往哪里不对。别人不再反驳你,未必是被说服了,也可能是放弃了——他们会在执行里表达不同意,而不是在会议里。
真正的对齐需要更久:你要理解别人的视角、吸收反馈,有时甚至要公开改口。
短期“我对了”的快感,远不如长期“我们愿意一起做”的现实重要。
15. 当指标变成目标,它就不再衡量真实情况
你暴露给管理层的每一个指标,迟早都会被“优化”。不一定出于恶意,而是人类会本能地对被衡量的东西做局部最优。
你看代码行数,就会得到更多代码行;你看 velocity,就会得到更膨胀的估算。
更资深的做法是:每次有人要指标,就给一对——一个衡量速度,一个衡量质量或风险;然后坚持看趋势,不迷信阈值。指标的目的应该是洞察,而不是监控。
16. 承认“不知道”,比装懂更能带来安全感
会说“我不知道”的资深工程师,不是在示弱,而是在创造空间。当领导承认不确定性,等于告诉大家:这里是安全的,你们也可以坦诚。
相反,如果最资深的人从不承认困惑,团队会变成“人人假装懂”。问题不被问出,假设不被挑战,初级工程师更不敢开口,因为他们以为“只有我不懂”。
示范好奇心,你就会得到一个真正学习的团队。
17. 你的人脉,会比任何一份工作更长久
早年我只顾把事做好,忽视了经营关系。现在回看,这是个错误。那些投入关系的人——公司内外都算——往往能在很长的时间跨度里获益:他们更早听到机会、能更快搭桥、容易被推荐、甚至与信任的人一起创业。
工作不会永远属于你,但关系会。用好奇心与慷慨去建立它,而不是用交易式的“社交技巧”。
当你需要转身时,往往是关系帮你打开门。
18. 多数性能提升,来自删工作,而不是加聪明
系统变慢时,人们下意识想“加”:加缓存、加并行、换更聪明的算法。有时这确实对。但我见过更多性能提升,来自一个简单问题:“我们是不是在算一些根本没必要算的东西?”
删掉不必要的工作,几乎总比把必要工作做得更快更有效。最快的代码,是根本不运行的代码。
优化前,先质疑:这段工作是否应该存在?
19. 流程的意义是降低不确定性,不是制造“留痕”
好流程让协作更轻、失败成本更低。坏流程是官僚表演——不是为了帮助,而是为了出事时能追责。
如果你讲不清一个流程如何降低风险、或如何提升清晰度,它多半就是纯开销。
如果大家花在记录工作的时间比做工作的时间还多,那就说明哪里已经很不对劲了。
20. 终有一天,时间会比钱更贵:按这个原则做决策
职业早期,你用时间换钱,这很正常。但某个阶段开始,计算会翻转:你会意识到时间是不可再生的资源。
我见过资深工程师为了再上一档职级而燃尽自己,把所有选择都优化为“多一点点总包”。有的人得到了,但更多人事后会怀疑:值得吗?
答案不是“别努力”,而是“清楚你在用什么换什么,并且有意识地做这笔交易”。
21. 没有捷径,但有复利
专业能力来自刻意练习:持续把自己推到略高于现有水平的地方,反思,重复。年复一年。没有浓缩版。
但这里有个好消息:学习的复利不在“懂了更多冷知识”,而在“获得了更多选择”。写作——不是为了流量,而是为了清晰。构建可复用的基础能力。把踩坑变成可用的 playbook。
把职业当作复利,而不是买彩票的人,通常会走得更远。
最后一点
21 条看起来很多,但归根结底是几件事:保持好奇,保持谦逊,别忘了工作最终都是关于人——你在服务的用户,以及你一起共事的同伴。
工程职业足够长,足够你犯很多错,也足够你最终仍然走得很好。我最敬佩的工程师不是从不犯错的人,而是那些从错误里学到东西、把发现分享出来、然后继续前行的人。
如果你刚开始走这条路,后面会越来越丰富;如果你已走得很深,希望其中有些能与你产生共鸣。