为何大公司的工程师总写出糟糕的代码

每隔几年，有人就会注意到，大型科技公司有时会产生令人惊讶的粗糙代码。如果你没有在大公司工作，可能很难理解这如何发生。大型科技公司的薪酬足够高，可以吸引许多有能力的工程师。他们的工作节奏足够慢，看起来他们有足够的时间来做扎实的工作。那么，糟糕的代码是如何产生的？

大多数代码更改是由相对初学者完成的

我认为主要原因是大公司里充满了在非专业领域工作的工程师。平均而言，大型科技公司的员工只会待一到两年。事实上，大型科技公司的薪酬包通常被设计为限制工程师的任职期限在四年内：在四年后，初始股票授予将完全生效，导致工程师可能会面临50%的工资削减。公司可能会提供临时的年度刷新，但这明显鼓励工程师去寻找其他工作，以避免每年都要担心是否能获得完整的薪酬。

如果我们考虑内部流动，情况会更加糟糕。我职业生涯中最长的时间是在一个团队或代码库中工作了三年，刚开始工作时就是这样。我预计自己会至少每年被重组一次，通常会更频繁。

然而，大型科技公司中的代码库的平均寿命远远长于此。许多我工作的服务都已经有十年或更长的历史，并且多年来已经更换了许多所有者。这意味着许多大型科技公司的工程师不断地“摸索”。**相当高比例的代码更改是由“初学者”完成的：**那些在过去六个月内刚刚入职公司、代码库，甚至是编程语言的人。

老手

在某种程度上，这个问题是通过“老手”来缓解的：那些恰好在一个特定系统中工作了足够长时间以发展出真正专业知识的工程师。这些工程师可以进行深入的代码审查，并可靠地捕捉到明显的问题。但是，依赖“老手”有两个问题。

首先，这个过程是完全非正式的。大型科技公司在开发个别系统的长期专业知识方面做得非常少，一旦他们拥有了这种专业知识，他们似乎几乎不关心保留它。通常，相关工程师会被转移到不同的服务，他们必须要么在基本上志愿的基础上继续履行“老手”的职责，要么放弃这些职责并成为一个全新的系统的相对初学者。

其次，经验丰富的工程师总是过载。作为拥有深入专业知识的少数工程师之一，这是一份非常忙碌的工作。你没有足够的时间来亲自审查每个软件更改，或积极参与每个决策过程。记住，你还有自己的工作要做：如果你把所有时间都花在审查更改和参与讨论上，你可能会被公司惩罚，因为你没有足够的个人产出。

中位数生产力工程师

将所有这些因素结合起来，大型科技公司的中位数生产力工程师是什么样的？他们通常是：

具备足够的能力，能够通过招聘标准并能够完成工作，但要么
在一个对他们来说基本上是新的代码库或语言上工作，或者
尽管他们自己的工作很忙，但仍试图跟上代码更改的洪流。

他们几乎肯定是在截止日期或一系列不同项目的重叠截止日期内工作。换句话说，他们正在尝试在一个不适合产生高质量代码的环境中做到最好。

这就是“明显”的糟糕代码如何产生的。例如，一个初级工程师接到一个关于他们几乎不熟悉的代码库中的一个烦人的bug的票。他们花了几天时间弄清楚并想出了一个临时的解决方案。一个更高级的“老手”（如果他们幸运的话）会在空闲的半小时内快速审查一下，否决它，并建议一个稍微好一点的解决方案，至少可以工作。初级工程师会尽力实现它，测试它是否有效，它会被简要审查并发布，所有参与人员都会立即转移到更高优先级的工作。五年后，有人会注意到这个问题并想：“哇，这太临时了——这样的糟糕代码怎么会在这样一家大型软件公司中被写出来？”

大型科技公司对此感到满意

我已经写了很多关于促成这一点的内部科技公司动态的内容。最直接的例子是，在像软件公司一样看待世界中，我认为大型科技公司始终优先考虑内部的可见性——即能够一眼看出谁在做什么并可以随意更改它——而不是生产力。大型公司知道，将工程师视为可互换的并将他们转移到不同项目上会摧毁他们在单个代码库中发展长期专业知识的能力。这是一个刻意的权衡。他们放弃了一定的专业知识和软件质量，以换取快速部署熟练工程师到每个月的新问题的能力。

我不知道这是一个好主意还是一个坏主意。它似乎对大型科技公司有效，特别是现在“如何快速转向与人工智能相关的东西”如此重要。但是，如果你这样做，那么你当然会产生一些真正糟糕的代码。当你要求工程师在他们不熟悉的系统上匆忙完成工作时，这就是会发生的事情。

个别工程师完全无法改变这种动态。这在2025年尤其如此，当时权力平衡已经转向科技公司领导层，而不是工程师。作为个别工程师，你能做的最多就是尝试成为一个“老手”：在至少一个领域发展专业知识，并利用它来阻止最糟糕的更改，并引导人们朝着至少在技术上合理的决策方向发展。但即使这样，经常会与组织的潮流相反，如果处理不当，也可能会导致你被PIP或更糟糕的结果。

纯粹和不纯粹的工程

我认为这大部分归结于纯粹和不纯粹的软件工程之间的区别。对于纯粹的工程师——那些从事自包含技术项目的工程师，例如编程语言——糟糕代码的唯一解释是无能。但是，不纯粹的工程师则更像水管工或电工。他们在相对新鲜的项目上工作，面临截止日期，即使他们的技术基础知识无可挑剔，也总会有某些事情使得这种情况变得笨拙或令人惊讶。对于不纯粹的工程师来说，糟糕的代码是不可避免的。只要整个系统的工作效果足够好，项目就是成功的。

在大型科技公司中，工程师无法决定他们是否正在从事纯粹或不纯粹的工程工作。这不是他们的代码库！如果公司想把你从数据库基础设施的工作转移到构建新的支付系统，他们完全有权这样做。这样做可能会导致你在不熟悉的系统中犯一些错误，或者你的旧同事在数据库基础设施团队中可能会因缺乏你的专业知识而受到影响，这是一个公司正在做出的刻意权衡，而不是工程师。

指出大型科技公司中糟糕代码的例子是可以的。如果没有其他作用，这也可以成为一种有效的方式来修复这些特定的例子，因为高管通常会抓住机会将糟糕的公关转变为良好的公关。但是我认为将主要责任归咎于这些公司的工程师是一个错误。如果你可以挥舞魔杖让每个工程师变得更强两倍，你仍然会有糟糕的代码，因为几乎没有人可以进入一个全新的代码库并快速地在没有任何错误的情况下进行更改。根本原因是大多数大型公司的工程师被迫在不熟悉的代码库中完成大部分工作。

编辑：这篇文章在Hacker News和lobste.rs上收到了很多评论。

令我惊讶的是，许多评论者认为这种观点令人不愉快地虚无主义。我认为自己对工作相当乐观。事实上，我把这篇文章当作是对大型科技软件工程师的辩护，反对他们的批评者！然而，我发现这篇回应博客文章是对“这太过愤世嫉俗”的观点的优秀阐述，我很可能会很快写一篇后续文章来讨论它（编辑：软件工程师应该有点愤世嫉俗)。

令我惊讶的是，许多评论者认为这种观点过于虚无主义。我认为自己对工作还是比较乐观的。事实上，我本意是要为大型科技公司的软件工程师辩护，反驳他们的批评者！然而，我发现这篇回应博客文章对“太过愤世嫉俗”的立场进行了极好的阐述，我可能很快会就此写一篇后续文章（编辑：软件工程师应该有点愤世嫉俗)。

一些 Hacker News 评论者提出了其他关于为什么会产生糟糕代码的理论：缺乏动力、故意使工程师士气低落以防止他们成立工会，或者只是纯粹为了优化速度。我不认为这些理论有说服力，基于我的个人经验。我的许多同事都非常有动力，我根本不相信任何科技公司会故意让其工程师士气低落和不快。

一些读者不同意我的观点，认为 RSU（限制性股票单位）提供了离开公司的激励，因为他们的公司提供股票刷新。关于这一点，我不太清楚。我也会收到刷新，但如果它们不在合同中，那么我认为这并不重要——公司可以决定不给你 50% 的薪酬，仅需暂停刷新，这就成为你跳槽并锁定四年薪酬的激励。

如果你喜欢这篇文章，可以考虑订阅我的新文章的电子邮件更新，或者在 Hacker News 上分享。以下是与本文相关的另一篇文章的预览：

作为员工软件工程师，我如何影响科技公司的政治许多软件工程师对公司政治持悲观态度。他们认为参与其中是没有意义的，因为：一般的想法是，软件工程师根本不具备与真正的政治操作者同等水平的能力。这种说法是正确的！软件工程师认为自己应该开始策划和阴谋，就像在《权力的游戏》中一样，这将是一个严重的错误。你的阴谋会立即被揭露并被利用来对你不利和他人有利。策划需要练习和权力，而软件工程师两者都没有。继续阅读...