给还在大厂工作的朋友21条忠告

本文来自微信公众号： MacTalk ，作者：池建强，原文标题：《给还在大厂工作的朋友 21 条忠告》

当我14年前加入谷歌时，我以为这份工作就是写出优秀的代码。我只说对了一部分。但待得越久，我越意识到能真正成长的工程师未必是代码写得最好的那批人——而是那些懂得如何在代码之外游刃有余的人：在人与人之间、政治、一致性以及不确定性里找到路径。

这些教训我希望自己能更早知道。有些能让我减少几个月的挫败感；有些花了我几年时间才彻底理解。它们不涉及具体技术——技术变化太快而不值得押重注——它们讲的是一个又一个项目、一个又一个团队里不断重复的模式。

我分享这些，是因为我曾经得到许多工程师的慷慨相助并获益良多。把篇文章看做我力所能及的一次回馈吧。

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

专业能力来自刻意练习——略微超出当前技能、反思、重复。历年累月。没有简单的路径。

令人振奋的是：当学习带来新的选择，而不只是新增一点点“知识碎片”，它就会产生复利。写作——不是为了互动量，而是为了厘清思路；构建可复用的场景；把一路走来的经验教训沉淀成作战手册。

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

最后的想法

二十一条听起来很多，但归根到底是几条核心理念：保持好奇，保持谦逊，并记住工作最终的关系人——你为之构建（产品）的用户，以及与你一起构建的队友。

工程师的职业足够长，足以让你犯很多错误最后仍然能走得更好。我最欣赏的工程师不是那些把每件事都做对的人，而是那些从错误中学习、分享他们的发现、并持续进步的人。