强工程师与弱工程师
原始链接: www.seangoedecke.com/weak-engine…
最近大家都在 Twitter 上热议美国是否需要从其他国家引进顶尖人才，以及这是否意味着本土工程师的能力太弱。上个月，一项研究也引发了轩然大波，该研究声称大约有 9.5% 的软件工程师实际上在“摸鱼”（几乎没有任何实质产出），简直是在诈骗公司。过去十年里，人们也一直在谈论传说中的“10 倍工程师”。
那么，到底什么是真正的“强”软件工程师呢？
强工程师
根据我的经验，衡量人才的真正标准不是看产出的速度或数量，而是具备完成其他工程师做不到的任务的能力。换句话说，强工程师能做到弱工程师无论花多少时间都做不到的事。因此，最强的工程师比大家想象的还要强：他们不是普通工程师的 10 倍或 100 倍，在某些问题上，他们是无限倍。而最弱的工程师也比大家想象的还要弱：他们的产出不是 0.1 倍，而是 0。大型软件团队中几乎所有的任务，他们都无法独立完成。
例如，在能够交付复杂项目的工程师和不能交付的工程师之间，有一道难以跨越的鸿沟。弱工程师并不是做得慢——而是他们根本做不出来。除非旁边有一位强工程师暗中主导，否则项目必然失败。类似的能力还包括：
- 解决极其棘手的 bug（例如跨多个服务的并发问题）
- 对老旧代码库中最错综复杂的部分进行实质性的优化
- 成功完成需要大规模架构重构的代码修改
对于最顶尖的强工程师来说，他们的能力可能体现在“提升大语言模型的最先进水平（SOTA）”和“实现自动驾驶”。
并非每个强工程师都能做所有这些事。有人可能擅长解难 bug 但不擅长推进项目；有人精通重构老代码但开发速度不快。然而，如果一个人擅长其中一项，他通常也擅长其他大部分。我不太确定原因：也许是纯粹的智商高，也许是一通百通，或者是这些能力本质上更相似，又或许是这类工程师对待所有事情都全力以赴。但在我看来，这绝对是事实。
需要明确的是，虽然“能不能完成某项任务”是黑白分明的，但“强/普通/弱”的分类却是一个渐变的光谱。可能会有一个“普通工程师”特别擅长解决复杂 bug，或者一个“弱工程师”很擅长维护开发环境。一个人完全可以处于两个类别之间的模糊地带。
普通工程师
强工程师之下是普通工程师，他们构成了大多数公司的中坚力量。这类工程师通常具备以下能力：
- 解决 95% 的 bug（即普通的、常规的 bug）
- 接手并完成大部分的 JIRA 任务
- 绝大多数时候能自行搞定开发环境的报错
我的一位老同事曾称这类工程师为“老黄牛”：他们速度不算特别快，但能在中等难度的工程任务上稳步推进。现在我觉得这个称呼有些不必要的贬义，因为随着经验的增长，我越来越喜欢这些同事。他们能帮忙，他们能干活。他们只是没有强烈的野心非要在下次晋升中拔得头筹，或者用惊人的产出惊艳同事。他们生活中大概还有其他更重要的事情！
关于这个群体我没什么太多可说的，只是想提醒大家：别把他们和最后一类——“弱工程师”搞混了。
弱工程师
另一类是真正的弱工程师。这些人几乎没有任何工程能力。换句话说，连常规或简单的软件任务的基准难度，都超出了他们的能力范围。我想这些人中有一小部分可能是身兼数职或在以某种方式划水，但我认为绝大多数确实是能力不足。我绝不是在夸大其词：弱工程师几乎无法完成任何工程任务。我曾在没有这种人的团队工作过，但只要在这个行业待得够久，你总会遇到他们。
讽刺的是，虽然这种人存在于几乎所有的资历级别中，但你更容易在“高级（Senior）”及以上的职位中遇到弱工程师。我认为原因主要有两个。第一，招聘初级工程师的标准直接挂钩实际写代码的能力，很难蒙混过关。而在面试高级工程师时，他们可以大谈特谈自己“擦边参与”过的工作，面试官很难区分哪些是他们亲手做的。第二，能力弱的初级工程师通常有更多学习机会，因为大家觉得新人不懂很正常。而能力弱的高级工程师必须隐藏自己的无知并在暗中学习，这难得多。
对于弱的初级工程师，没什么好苛责的。你应该帮助他们，给他们安排有挑战性的问题，看看他们能否迎难而上。然而，弱的高级工程师就“有趣”多了。
弱高级工程师是如何生存的？
弱工程师是如何在高级及以上级别混下去的？他们会进行大量“单向结对编程（Pairing）”。如果你曾和这种工程师结对过，体验会非常糟糕，因为无论谁在敲代码，所有的活儿都是你干的。通常这种结对很隐蔽——他们会通过私聊悄悄向团队里的另一个工程师求助，连每一个微小的任务都要找人帮忙。有时候团队里会有一个倒霉蛋的时间被这样榨干：比如一个有能力、乐于助人但由于经验不足而无法察觉异样的初级工程师。更狡猾的弱工程师会在团队里轮流“薅羊毛”，这样每个成员可能每周只需要帮他们一次。只有当大家互相对质时，才会发现这个弱工程师 100% 的任务都是靠别人结对完成的。
在与工作相关的讨论区中，弱工程师往往出奇地活跃。部分原因是他们很有空——除非能找到人“结对”，否则他们实际上并不干活。这也是一种有效的自我保护机制。如果有人质疑他们的个人产出，他们可以指着这些公开沟通记录说，自己是在提升团队整体水平，而不是只顾着埋头干具体的活。在问题讨论串中辨别弱工程师的一个方法是：看看谁在提供系统当前实际运行的具体细节，而谁在给出放到任何系统都适用的“正确的废话”。如果他们发的消息完全可以直接当成公开推文发出去，那他们大概率没提供什么实际价值。
与弱高级工程师共事的一些建议
第一点也是最重要的一点：要记住这只是一份工作。一个人工作能力差，并不代表他是个坏人。千万别做个混蛋！人可能因为懒惰或缺乏天赋而显得弱，但也可能是因为一些你根本不知道的私人原因。如果有一天你因为个人变故无法专注于工作，你也希望能得到别人的宽容，所以请以同等的善意对待他们。甚至缺乏天赋也可能与环境有关：比如，他们可能是个嵌入式系统专家，正在尝试新领域但不太顺利；或者是一个大厂员工，正在努力适应初创公司的节奏。
尽管如此，你还是应该设法保护好自己的时间。不要默默牺牲自己的工作时间来帮他们维持不被开除的假象。一个策略是避免时间不对等的帮助。不要为了帮他们而花掉比他们提问多得多的时间。例如，如果他们问“嘿，我遇到了这个问题，你会怎么处理？”，不要亲自花时间去算出确切的解决方案然后双手奉上。快速回复一句，指出下一步的方向即可（比如：“哦对，看起来像是计费代码里的报错，你去看看服务 X 是怎么处理的”）。这样他们就无法用他们每天区区几分钟的时间，去消耗掉你几个小时。
同样，你也应该尽力保护团队里初级成员的时间。不要让他们被弱高级工程师剥削（高级让初级解决问题，然后向管理层美其名曰在帮初级成长）。最好的办法就是（以职业的方式）确保你的经理了解真实情况。在某些公司，走流程淘汰一个人难如登天（而且可能有一些你不知道的内情），所以不要指望这个人会立刻被开除、吃绩效警告或被勒令整改。但你仍然有责任让你的经理知情。
结论
工程天赋不是指你敲代码有多快或产出有多大，而是具备完成其他工程师做不到的任务的能力。这就是为什么最弱的工程师产出如此之低，也是为什么科技公司 CEO 们如此痴迷于招聘最顶尖的工程师。
大多数工程师能完成绝大部分的常规工作任务，但只有少数人能解决极其困难的问题，也有些人几乎什么都做不了。你应该尽量去扩展你能胜任的任务范围。如果你正在和一个弱工程师共事，请保持友善，但要保护好自己的时间。
编者注：这篇文章曾在 Hacker News 上引发了大量讨论。
如果你喜欢这篇文章，考虑订阅邮件以获取我的新文章动态，或者[在 Hacker News 上分享它](news.ycombinator.com/submitlink?… can strong engineers do that weak engineers can't?)。以下是一篇与本文相关标签的文章预览：
为什么有些工程师会被委以重任
负责关键任务既有趣又有成就感。但核心的重要工作就那么多。更糟糕的是，参与这些项目的机会分布并不均匀，因为这些工作通常由内定好的团队来完成。我参加过不少这样的团队。工程师靠什么才能进入那个名单呢？
随着你在公司的管理者中获得越来越多的认可，你正在穿过一系列同心圆不断向上攀升。
继续阅读...
