资深工程师的死亡螺旋
文章摘要
Sunil Pai 写于 2026 年 9 月 19 日的一篇短文，副标题是”关于证明自己、倦怠，以及做一个好队友”。起因是一位朋友刚拿到一份新工作：职级很高、薪水很高，和他之前的岗位差别很大。朋友来问他怎么扛住每周 60 到 80 小时的工作、怎么表现到足以升职。聊着聊着 Sunil 意识到对方有点冒名顶替综合征，特别想证明自己，于是他来了一段独白——这篇文章基本就是那段独白的原样整理，全文小写、口语化，一口一个 bro，这种文风后来成了 HN 上争论最多的话题之一。
什么是”资深工程师死亡螺旋”。 作者说这是他见过最常见的失败模式。通常发生在工程师入职新公司、刚升职，或者只是接了一个大项目的时候；也可能是他们主动去要大项目，因为心里想着”如果我更努力、做更大的事，就会得到升职之类的回报”。他们会告诉自己得”cosplay”一个比自己实际更资深的工程师，于是去设计某个野心大得多的东西。
接下来的剧情几乎是固定的：他们开始长时间消失，两三周听不到任何消息。偶尔在站会上给一个作者称之为”正面更新”的汇报：”挺顺利的，各位，很快就有东西给你们看了，有问题随时找我。”通常没人去找，而他们其实也拿不出东西。与此同时螺旋已经在他们脑子里转起来了：”天哪，我好久没交付任何东西了。我得更努力。只要够努力，我就能挽回，没人会发现。下周我就把一整个月的活干完，没人会知道。”然后开始失眠、情绪低落、不按时吃饭，工作和私人关系都受损，越陷越深。最坏的结局是：倦怠到要休一个月假、被列入绩效改进计划（PIP）、被解雇，或者自己觉得”这已经没法挽回了”而辞职。作者坦白这不只是他在别人身上看到的，他自己也经历过很多次，多到现在已经能在早期识别出来并及时退一步。
为什么现在更容易掉进去。 作者认为，过去五到十年发生的事情——新冠、远程办公、编码 Agent——让工程师不再像以前那样坐在别人旁边、领 Jira 任务干活。你的自主权大了很多，但也更孤立了。所以你绝不能让自己处于”别人不知道你在干嘛”的境地：同事不应该在说”我也不知道 Sunil 最近在干啥”并开始担心，因为他们可能等到太晚了才告诉你。你想要的状态是”Sunil 一天到晚嘴里都是他在做的东西”——不必惹人烦，但必须分享你的工作。
反直觉的解法：降一级。 作者说第一步是假设身边所有人都是善意的：他们雇的是现在的你，不是你以为自己六个月后会成为的那个人。所以正确的做法不是努力表现得更高一级，而是几乎主动”降一级”，暂时去当最好的队友。你依然对自己的工作负责，只是先让自己重新动起来：修 bug、接别人盘子里那些烦人的活或者一直没人顾得上的事、做脏活累活、做组织工作、写文档——总之就是帮大家的忙。
这样做的目的是从”结果导向”转向”惯性导向”（momentum-based）。你要建立日常节奏，因为惯性就是一切，而关系比惯性更重要。有了惯性、修复了与他人的关系，你就获得了耐力。这时你才会明白真正的教训：大项目不是靠大力气完成的，它是一场马拉松，靠的是缓慢、稳定、渐进的工作——别说按周了，要按天、按小时，直到变成肌肉记忆。你进入自动模式：起床、冲咖啡、开工、干活。30 天后回头一看，每天做一点累积起来的工作量惊人。你追求的是可靠性和修复关系，是替队友和经理减轻负担；一旦建立起信任，他们自然会给你更大的活。
结尾一句是全文的主旨：”记住，你做的是建立声誉的生意，软件其实是它的下游。”
HN 评论精华
146 条评论。需要先说明的是，相当一部分讨论并不在文章观点上，而是在吐槽文风：全文不大写句首、意识流式的口语独白、频繁的 “bro”。另外两条主线是”升职到底靠不靠干好活”的争论，以及对文章所描述现象的成因分析。
文风之争占据了评论区顶部。 最高楼的 ungreased0675 直接说”因为意识流的写法我没看懂”。Pannoniae 替大家做了 TL;DR：你升职了或想升职，于是决定做个大项目来展示野心，然后从大家视野里消失，最终卡住、落后，招致 PIP 或抑郁；作者的药方是每天保持沟通、展示些进展。他还补了一句自己的看法：”我不觉得这是资深工程师特有的问题，读起来更像是 ADHD 式的时间管理和兴趣问题。”nchmy 的态度最激烈：句首不大写的人不值得关注，再加上意识流，”可以肯定这篇文章毫无洞见”。hollerith 则指出作者其实大写了 “I” 和专有名词；jolmg 回忆自己少年时也有过不大写句首的阶段，理由是”句号已经在那儿了，为什么还要第二个信号”。aweb 从另一个角度提出请求：没有清晰的句子边界，对 ADHD 读者来说很难确认自己没有漏读，”作者们，请为我们神经多样性人群考虑一下，按一下 Shift 键”。shrikant 注意到作者其他文章格式都很规范，推测这是刻意为之，用来体现”意识流”的效果。alembic_fumes 则对 “bro” 表示很难相信这样说话的人有资格给资深者提建议，但也承认”这个信息虽然难读，却是有些人需要听的”——他亲眼见过有人靠拼命干活获得升职，越升越觉得必须更拼命地证明自己，最终倦怠。他希望这条建议更多面向经理和资深同事：当你发现某个同事陷得太深，找他友好地聊一聊。
“干好活、做好人，其余自然会来”是真的吗？ hsbalanxvxjsmab 说自己是 staff 工程师，从没花一天时间想过升职。Arainach 立刻反驳：”这在大多数地方从来不太成立，即便曾经有点道理，自 2023 年以来也已经不成立了。阶梯已经塌了。没有初级工程师可带（有些地方干脆停止了美国招聘），胡萝卜全换成了大棒。运气好的话，干好活、做好人的回报是’不被裁’，而升职预算没了。”他后来补充说，自己在 FAANG 和同档公司的朋友都反映”靠干好活升职”基本已经死了。cafebabbe 则说至少在欧洲，升职虽然更难了，但阶梯并没有塌。StevePrefontain 同为 staff，却说自己升 senior 和 staff 都是主动要来的，他的导师当了近 20 年 VP of Engineering，说”从来没拿到过一次自己没主动要的升职”。ytoawwhra92 一针见血：”这句话要成立，前提是你对’好活’和’做好人’的理解要和周围的人以及整个组织对齐。”
跳槽还是内部晋升。 slowin 认为最好的职业建议是别想着在当前公司升职，而是在职时去申请别家更好的职位，”这样你有最大的筹码”。gonzalohm 反对：面试太痛苦，而且如果找对了公司，根本不需要开口要升职。JeremyNT 认为那是零利率时代的玩法，如今连让简历被真人看到都越来越难，”在现有团队的好声誉会让你在内部晋升中排在外部候选人前面，别忽视这一点”。xdertz 提醒跳槽建议往往只盯着薪水，而工作氛围、同事、工作生活平衡、以及欧洲很多地方工龄越长越难被解雇等因素同样重要。
招聘方的视角。 swiftcoder 说他过去几年面试过好几位很棒的资深候选人，然后眼看着他们入职后正是这样把自己在 6 个月内”送出门外”，因此他明显更偏好内部提拔，”因为你有更长的时间提前拦住这种事”。他认为软件行业急需某种正式的职级标准或导师计划，因为资深者越来越难用日益缩小的同辈群体来校准自己。有人质疑是不是公司有问题，他回应说一年流失一个工程师在统计上并不显著，但创业公司薪水不如大厂、要求身兼数职、也没有大公司那种管理链隔离，很多从大厂过来的人直到在第一份创业公司工作里挣扎过才意识到这一点。对于”资深者怎么会消失”的疑问（rubzah 认为越资深越需要协调他人），swiftcoder 解释得很到位：”资深层级的很多工作更难追踪。初级工程师不再从队列里拿工单，马上会有人注意到；而资深者在新项目开始时花几周参加跨职能会议、写文档，没人会眨眼。有时候经理没能及时发现他们再也没从那个阶段走出来……”
成因分析：彼得原理还是信任缺失。 wickedOne 和 jacobgold 都提到了彼得原理。knollimar 的说法更妙：”这是自己给自己加速通关的彼得原理——连’他们最终能不能胜任’都不管了，而是试图立刻变得不胜任。”jacobgold 自称有 20 多年工程和管理经验，认为行业存在大量头衔通胀，”我们现在能看到工作三年的人拿到 Principal Engineer 头衔”，而”光是学会有效地管理自己就需要十年经验”。这条评论被 hluska 批评为”一边说不想冒犯谁，一边否定了一大批人的职业”。
msteffen 的长评是本帖最有深度的一条。他说对自己而言，逃避状态汇报、需要”证明自己”，都源于更深层的信任缺失。他总结了几点：信任由能力和沟通各占一半，信任的丧失是因为你期望 X 却没得到，所以一半问题在于没得到，另一半在于一开始就这么期望；清晰的沟通需要反方向的信任，一个彻底失调的公司里工程团队不信任管理层所以不对其说实话，很快管理层也不再信任工程团队；如果你不敢说出某件真实的事（比如”我昨天什么都没做成，因为我还没真正理解要解决的问题”），就说明你不信任对方——这正是导致跳过状态汇报、不经讨论就闷头开发的根源。他认为文章给出的”做脏活换取正反馈”是在帮自己重建信任，同时也提醒：如果你不经讨论就闷头做东西，可能是公司对你缺乏信任，正在反过来造成你对公司缺乏信任。
对文章的反驳与补充。 godelski 指出”cosplay 一个更资深的工程师”其实被明文写进了每份升职指南——几乎所有指南都要求你在某个级别上工作若干个月之后才会被提升到该级别，”这不是妄想，这是制度化的”（随后被人调侃这句话”一看就是 Claude 腔”，他回应”我保证我是人类”）。他也认为整个行业太过仓促，”创新不是靠拿头撞墙，而是发生在大量撞墙之后的安静时刻”。atom_arranger 从另一面为消失的工程师辩护：在 Scrum 团队里，人们被期望每个 sprint 都交付东西，但有些重要的大工作其实验和构建根本塞不进一个 sprint，硬要增量交付只会交付垃圾，”螺旋其实是与一个不鼓励雄心目标的体制之间的摩擦”。derf_ 认为这建议在一定程度上没问题，但更大的成就不是靠更努力甚至更勤勉，而是靠杠杆：你需要了解别人在做什么、能做什么、应该做什么；”当你发现自己被拉去写路线图、估排期、给年度预算写段落时，你就走对路了”。malux85 则直言：消失很久再给出”一切顺利”这种含糊更新，不是资深者（哪怕是平庸的资深者）的行为，而是管理不善的初级工程师的行为。ab_io 把话题接到 AI 上：AI 编程工具让”下周我就干完一个月的活，没人会知道”显得格外诱人，但结果可能是”打了类固醇的布鲁克斯定律”；正确做法是尽早与利益相关方沟通，他们多半早就知道项目有风险，也乐意砍范围或推迟截止日期。
关于倦怠与离开。 sajithdilshan 说越资深越会意识到”努力工作的唯一回报就是更多工作”，于是学会说不、设边界。coldpie 分享自己的做法：每周只工作 35 到 40 小时，不在个人设备上装工作的东西，回家不开工作电脑，没人对他的产出有异议，每年照样涨薪。Dizcorded 说自己正处在文中描述的处境，因为一个大项目倦怠后在休长假，而回去后的期望是再带一个大项目。justonceokay 的回复引来不少共鸣：他在不同公司和岗位坚持了十多年后辞职，先当了一年调酒师，考了按摩执照，又在蜡烛工厂干了几年，现在是一栋公寓楼的维修主管。”我依然整天在调试和维护，只不过是在物理世界而不是虚拟世界……我不再觉得自己的大脑被那些只会让人生活更糟的软件琐事占据。”被问到是否夺回了脑子的空间，他说：”清晰了无数倍。我低估了自己需要多大的脑容量去跟上公司自己的软件，更别提跟上 AI、源代码管理、IaaS、AWS 服务、Linux 补丁的最新进展。现在我知道的什么场景用什么密封胶，30 年后依然有用；而我以前知道的团队专有排序算法几乎每天都会失效。”rDr4g0n 说他认识的三位 principal 工程师都已经或正在这样离开软件行业，他自己也在计划，”我忍不住觉得大型软件公司会出现一次小规模出走”。