Story: Leaving LinkedIn - Choosing Engineering Excellence Over Expediency
47:35 Share

What if your dedication to doing things right clashed with your company’s fast pace? Chris Krycho faced this very question at LinkedIn. His journey was marked by challenges: from the nuances of remote work to the struggle of influencing company culture, and a critical incident that put his principles to the test against the company’s push for speed. Chris’s story highlights the tension between the need for innovation and the importance of project health. This all led Chris to a pivotal decision: to stay and compromise his beliefs or to leave in pursuit of work that aligned with his principles. He chose the latter. Join us as we dive into Chris’s compelling story, exploring the challenges of advocating for principled engineering in a world that often prioritizes quick wins over long-term value. Episode Page Support The Show Subscribe To The Podcast Join The Newsletter Chris's Personal Website  </context> <raw_text>0 您好，欢迎收听 Co-Recursive。我是 Adam Gordon-Bell。想象一下，您正处于塑造全球最大职业社交网络（拥有约十亿用户，LinkedIn）前端的最前沿，却发现自己的核心价值观与工作的要求发生了冲突。今天，我们将深入探讨一位 LinkedIn 高级员工工程师面临的真实困境。

如果您是忠实的听众，您可能会认出这位嘉宾。好了，这些现在正在运行。糟糕，我的听力功能是不是出问题了？你好，你好，你好。是的，我弄坏了。该死。等等。你好，你好。是的，是的，现在好了。好的，我们再试一次。那是 Chris Kreicho，他之前曾在播客中谈论过 TypeScript。然而，今天他谈论的是他在 LinkedIn 的经历。我喜欢我在 LinkedIn 的时光。

很棒。而且我真的很期待它将把我带向何方，因为如果没有它，包括那些坎坷的部分，还有那些非常光明的部分，我都无法做到接下来要做的事情。你知道，你可能会从这个故事艰难的结局中得出这样的结论：哇，LinkedIn 对 Chris 来说真的很糟糕。但实际上，总的来说，它真的很好。我真的很高兴。即使是那个坎坷的结局，我也很高兴我从中吸取的教训，并期待它将把我带向何方。

所以，是的，关于那个坎坷的结局。Chris 在 LinkedIn 担任非常重要的高级职位近五年。他负责管理桌面应用程序中许多重要的项目，也就是你在访问 LinkedIn.com 和非移动浏览器时看到的内容。他领导了诸如现代化大量 JavaScript 等项目。但让我们直奔主题。Chris 辞去了 LinkedIn 的工作，他因为沮丧而辞职。

这就是我们今天要剖析的故事。在一个拥有数千名开发人员的地方担任高级技术职务是什么感觉？你如何协调跨多个团队的大型计划？你如何完成这些事情？你如何领导大型项目？你如何改进庞大的代码库？此外，你如何平衡可持续的开发实践与业务对速度的需求？

如果这种对速度和迭代速度的渴望与你的方法、价值观以及你认为事情应该如何做的方式相冲突会怎样？你如何处理这种冲突？剧透警告，最终 Chris 离开了这份工作。这就是我们今天要讨论的内容。但是的，这一切都始于阳光谷。

大约五年前，也就是 2019 年 1 月的最后几天，这感觉比五年前要久远得多。感谢 COVID。但是当我第一次到达那里时，当你加入一家大公司或良好、健康的公司时，通常会有一些入职培训。所以我花了很多时间参加入职培训课程，学习堆栈的不同层次是如何工作的等等。

Chris 在开始工作后将远程工作在科罗拉多州，但前两周是入职培训。这两周中的第二周是与他的团队一起度过的时间。你知道，坐在我的团队成员、我的经理和我一起工作的一些人旁边，和他们聊天。即使在那时，那个团队也比大多数团队分布得更广。所以我们有几个人在阳光谷办公室的隔间区域工作。我们有几个人在旧金山办公室的隔间区域工作。然后我们有一个人在阿拉斯加工作。然后我实际上是在科罗拉多州远程工作，这在当时对 LinkedIn 来说非常不寻常。当我加入时，我们只有不到 100 名远程工程师，而总共有数千名工程师。

对 Chris 来说，在一个这样的地方工作是一个很大的改变。我之前所在的创业公司有一个相对标准的、相对良好结构的单体后端，然后，你知道，数据库和一些服务。我到了 LinkedIn，发现，首先，从事前端客户端应用程序工作的人数比我之前雇主雇佣的人数还要多。

这个客户端应用程序中的代码行数比我之前雇主总共拥有的代码行数还要多。

后端运行着数千个服务和这些庞大的 API 服务器，它们绝对超过了我之前雇主拥有的任何东西。但这只是一个 API 服务器。这只是你认为是 LinkedIn.com 的客户端。哦，顺便说一下，我们还有我们的广告销售平台。哦，顺便说一下，我们还有 LinkedIn 学习。哦，顺便说一下，我们还有……名单还在继续。所以……

其中一个非常强烈的体验就是反复地说：“对不起，你说的是插入数字吗？”我之前的公司拥有一个我认为当时规模相当大的应用程序，大约 150,000 行代码。

而当我到达 LinkedIn 时，LinkedIn 的前端有 200 万行。我只是想，你说的是百万吗？太多了。几乎是我……的 20 倍……你怎么构建它？构建需要多长时间？哦，新版本需要 17 分钟。还不错。我们应该改进它。但这还不错。

Chris 的团队被称为基础设施团队，但这并不意味着要搭建服务器。更像是工程赋能或开发者体验。Chris 的工作是让 LinkedIn 庞大的桌面应用程序前端更容易使用。好吧，好吧，这太多了。为某些人服务并帮助领导 LinkedIn 是什么意思？

每个季度都有 150 到 200 名工程师提交到这个应用程序中，发布越来越多的代码行。你如何在如此规模的项目中做任何事情，几十个团队，数百名工程师试图发布一个具有凝聚力的产品？

一开始有点不知所措，所有这些的规模。当然也很令人兴奋。这不像我当时那样：“哦，不”，更像是：“这很酷，但是，我的天哪，我们怎么做？”然后，你知道，你会考虑技术债务或技术成功，无论哪一个，但在这种规模下，所有这些成功和问题都会被放大。所以你会想：“哦，我们有 200 万行技术债务。”是的。

就像你的技术债务问题一样，它被乘以那个数字，而不是，你知道，你的基线是多少。这太多了。Chris 帮助做的第一个重大改变是引入 JavaScript 类。JavaScript 引入了类，但他们使用的是 Ember 框架，他们的代码需要仔细更新。那么，我们如何让

200 万行代码改变它们编写类的方式，从将对象文字传递给函数到，好的，现在我们将使用 class foo extends subclass bar 或 superclass bar。所以这种事情就像，好的，我们有代码修改器，但它们并非 100% 正确。而且有一些复杂的事情，比如，好的，如果你从 JavaScript 中获取一个原生类，

并将其用作旧式 Ember 类的子类

然后它又是原生类的子类。所以它有点条纹状。我们为此想出了一个有趣的名称“斑马条纹”。如果你的类看起来像一系列斑马条纹，其中一些是白色的，一些是黑色的，那么将其视为旧式类与现代 JavaScript 类一直向下延伸。由于旧系统的设计初衷并非与之配合使用，因此存在中断错误。这可能是我在那里学到的最重要的一点之一，那就是

对于这种规模的迁移来说，它必须尽可能自动化，否则它永远不会完成，因为手动重写 200 万行代码所需的工作量

即使你可以全职工作，也需要数月甚至数年的时间。要求产品团队停止全职工作以获得 JavaScript 的一些新语法，即使它带来了性能优势，即使它来自最终用户体验优势，也是完全不合理的。哦，对了。产品团队，对吧？Chris 的团队致力于改进开发者体验，但他们需要其他所有人参与。他们需要忙于发布功能的产品团队的帮助。

LinkedIn 有许多相对完善的流程，这些流程始终处于某种程度的修订中。但是

许多完善的流程用于处理大型技术投资。这可以追溯到 LinkedIn 在 2010 年代初期在其单体架构上遇到扩展瓶颈时，并且不得不转向面向服务的架构，早期的微服务模式，因为它无法再扩展到当时的单体架构。而那时的用户规模只是现在的十分之一，等等。所以他们基本上不得不停工一年。他们研究了这个问题，你知道，我说的是停止工作，停止产品工作。他们说，我们再也不会这样做。作为一项业务，停止所有工作一年成本太高。因此，我们有了一个用于此类横向计划的系统。这就是它们被称为横向计划的原因。意思是横跨大量团队。对。

你必须向他们推销。有一个委员会审查整个公司的这些计划，并将参与度保持在，你知道，这些团队承诺的 10% 或更低，这样你就可以说，我们不会，我们不会让所有产品团队的 100% 都致力于你的技术计划。将它控制在 10% 以内是很困难的。因此，计划是使用大量的自动化工具来加快速度。但首先，他们需要获得一位高级副总裁的批准。所以他们精心策划了一个提案。

所以尝试将所有优势和权衡以及它如何具有商业价值以及实际的技术成果是什么以及这些技术成果的业务成果是什么都放在一页纸上。顺便说一句，LinkedIn 有一个非常滑稽的一页纸文化，这些一页纸长达三到六页。你是说你制作了一个工具，然后特定的团队使用人工参与来运行这个工具，并确保……是的，就是这样。现在。

我们还从这些早期阶段了解到，如果我们不必让这些特定团队去做，而我们可以为他们去做，那也更好。

因为对于一个团队来说，说“是的，我将审查你的 PR 并进行冒烟测试以确保一切正常”比让他们报名说“我将占用我产品发布时间的一半或一周来进行这些代码修改”要容易得多。如果我可以说：“嘿，我有这个自动化工具。我将把它运行在你的代码库上。这里有一些培训，这样你就知道输出会是什么样子以及如何使用它。你能合并我的 PR 吗？”

更容易获得他们的认可，尤其是他们的管理层的认可，而不是说：“嘿，你能为我们做一些工作吗？”我们花了 18 个月的时间来完成 Ember 的工作。大部分工作是在六个月内完成的，但你总会有很多团队拖后腿。

啊，对不起，我们必须将此推迟两个季度。另一个团队受到打击，好吧，我们想资助这个项目，但实际上首席执行官本人刚刚否决了我们尝试推出的新产品设计，我们必须从头开始重建它。对不起，当你对抗首席执行官时，你就会输。所以你的技术计划很重要，我们同意，但是，不，你不能拥有它。首席执行官获胜。

在该项目成功之后，Chris 和他的团队有了明确的下一个目标。那就是前端生成的错误泛滥。与大多数公司一样，LinkedIn 也为这类事情进行了错误记录。大多数，你知道，你的创业公司可能使用 Ray gun 或类似的东西来接收这些错误。LinkedIn 有自己的内部基础设施，因为我们每小时提交的错误数量的价格将是天文数字。

这太疯狂了。我想这意味着可能有许多只是损坏的次要代码路径。这让我很惊讶。我的意思是，我想我的尖刻说法是，不应该这样。真的不应该这样。就像，我的意思是，为了让它不那么尖刻，并真正认真地谈论这个问题。

当我查看软件时，许多软件都是以这种方式损坏的。这通常不是由于工程师缺乏关心。它通常归因于至少两种结构因素的组合。第一种是许多我们都熟悉的，只是以业务压力的形式出现，看，我们必须发布这个东西。在很多方面，这是一个非常好的强制性功能。而且

有动机的工程师往往倾向于过度抛光。有时我们只需要将东西发布到世界上。这同样不一定不好，但这可能意味着我们走捷径，并且在质量上妥协。如果没有一个非常强大和健全的工程文化来理解，是的，这是一个有价值的权衡，但是，不，我们不能一直这样做，否则最终我们会得到最终糟糕的

损坏的、笨拙的用户体验，从短期来看可能不会伤害我们，但从长期来看，实际上会损害我们的业务。即使你尽了最大努力，你最终也会得到经常细微损坏的代码。因此，你的冒烟测试可能无法捕捉到它。你的 QA 尝试可能无法捕捉到它。它可能位于一条模糊的路径中。但是当 LinkedIn 在去年某个时候超过十亿会员时，

好吧，十亿会员接触到在我离开时是 320 万行代码的单体存储库，其中一半是测试代码，一半是生产代码。但是，无论你在 QA 方面多么努力，总有一些人会想到一些没有人想到的特定路径和内容组合来进行测试。

因此，你最终会得到一些损坏的东西，也许页面挂起了，也许它在你面前白屏了，你知道，有人重新加载它，或者在移动设备上的应用程序中，他们只是关闭应用程序并重新启动它，然后再次尝试。好吧，我们都知道关闭并重新打开它可以解决很多问题，因为你可以摆脱那些奇怪的状态错误。但是有一个解决方案。如果你逐一处理这些问题，并想象一下，如果你一直在使用 TypeScript。

所以我们做的一件事是去查看，好的，我们实际有多少 JavaScript 错误是我们知道会被此捕获的？有些错误你永远无法捕获。TypeScript 很复杂。JavaScript 很复杂。但是有一些类型的错误我们可以说，看，如果我们真正进行完整的迁移，

这些事情中有多少会停止进入我们的日志记录基础设施？当你看到每天数百万的数字时，你开始能够真正谈论到，嘿，我们可以将应用程序的日志记录量减少至少四分之一。只需去掉 25%。这个数字可能高于此。这是一个下限。

因此，Chris 开始编写一份关于迁移到 TypeScript 的一页纸文档。好消息是，迁移到 TypeScript 可以逐步进行。许多代码库之前都这样做过。坏消息是，它无法适应 10% 的时间预算。这任务太大了。

但 Chris 的文档很有说服力。TypeScript 曾经有一个口号：“可扩展的 JavaScript”。有了数百万行代码，有了所有这些错误并经历了这些错误，很明显 LinkedIn 需要这些可扩展性优势。因此，Chris 跳过了横向计划。他采取了基层自下而上的方式。

工程经理会问他们团队的工程师，好的，你提倡我们成为这项技术的早期采用者，或者我们在这里进行重大投资。为什么？这份文件将直接交给他们。因此，它成为一个非常有用的工具，可以以相对简洁的格式提供信息，说明：

它解决了哪些问题。它给我们带来了哪些优势。即使在我们招聘能力方面，它与试图招聘我们的同行相比如何。然后人们可以将其融入到他们的思维框架中：这是该工具是什么。它给我们带来了什么。这与其他优先事项相比如何。好的，是的，这是有道理的。而且

有了这个，关于它与其他事物的优先级排序的讨论就变得容易多了。我认为对于任何人来说，说“不，这是值得的”都容易多了。好的。我明白了。是的。这很强大。就像你一样，哦，我只是告诉他们一些显然正确的事情，然后人们不得不去做。是的。是的，就是这样。

因此，TypeScript 开始流行，Chris 成为解决棘手类型问题的专家。需要帮助解决棘手的 TypeScript 问题，那就找 Chris。但是随着这个新项目的进行，下一个大问题摆在了他的办公桌上。这就是事情开始螺旋式下降的地方。LinkedIn 是全球最大的 Ember.js 用户。

但他们并不太喜欢它。这是一个冲突。Chris 也感受到了。他是一位开源 Ember 团队成员，一位贡献者。但在 LinkedIn，作为 DX 负责人，他看到了很多不匹配之处。但长话短说，我们最终发现，我一年半前的工作是制定一个计划，让我们摆脱 Ember 并转向 React。与此同时，我们的高级领导表示，

LinkedIn 的迁移成本太高。即使你一直在尝试做所有这些事情，我们谈论的所有关于降低迁移成本的事情，让基础设施平台类型的团队尽可能多地自己做。它仍然太高了。我们觉得这对我们的产品速度来说成本太高了。

现在，我认为产品速度下降的一些原因是，你有一个 300 万行代码的应用程序，已经有七年的历史了，它积累了相当多的技术债务和产品债务。这只会随着时间的推移而减慢速度。很难永久保持这种速度。你不能仅仅因为你要破坏用户的东西而改变它们。因此，即使是产品设计工作也更难，因为如何在产品中适应它以及在哪里适应它在那种规模下更难。

但无论如何，我们从领导层那里得到的讯息是，我们希望看到迁移成本降低。那么，你如何以低成本的方式将 300 万行 Ember 代码迁移到 React 代码？想想看。这是一个难题。进行大规模迁移，但在迁移过程中不要减慢任何人的速度。

我们想出了一个我们认为能够解决他们所说问题的策略。它大约是，我们预计需要三到五年，三年非常乐观。我们的想法只是在自动化方面加倍努力。让这成为产品团队基本上

永远不必做很多工作的事情。这个想法是按顺序排列和分割它，分解它的线程，以便你可以处理一部分，端到端地完成它，然后继续下一个。其中一些可以并行化，一些则不能。因此，确定顺序，确定分割，并行化你所能做的，更改构建管道，更改数据层，更改路由层，

为反应系统找到一个桥梁，该桥梁了解如何处理路由和视图层。然后最后将视图层和反应系统从 Ember 渲染和反应系统切换到 React 系统，但在你已经编写了可以执行此操作的自动化的方式下。这就是我们的提案。正如我所说，三到五年将会有很多工作要做，但我们的想法是产品团队将永远不必停止

这是一项巨大的工作，就像在长途旅行中不断驾驶汽车的同时，逐个更换汽车零件一样。这将令人印象深刻，但三到五年，这是一个很长的时间。与此同时，当 Chris 的团队正在为工程主管准备他们的计划时，另一个团队联系了他们。我们将这个团队称为“Fingerguns”团队，顺便说一下，这不是他们的真实名称，但他们也有一个计划，他们也在解决类似的问题。

包括他们以不同方式（在我看来是正确的方式）定义的东西，在我看来，工程领导层和其他人真正想要的东西，那就是速度这个词。我们如何更快地发布功能和想法？我们如何更快地迭代？我们如何将一个想法从想法变成 A/B 测试

我们能否将其缩短到几周而不是几个月？因为，你知道，已经好几个月了。他们确定，好的，我们的堆栈中存在这种分裂。我们有这个大型桌面堆栈。我们有一个不同的移动网络堆栈。我们的 iOS 和 Android 应用程序的周期时间很长。我们能否缩短这些时间？

我认为回想起来，他们正确地确定了当我们的领导告诉我们迁移疲劳时，迁移疲劳是一种症状。他们真正关心的实际问题是，我们能否专注于更快的迭代，尝试想法，如果想法不好或不起作用，则更快地放弃想法？

迁移会妨碍这样做，因为我们的工程师将 10%、20% 或 25% 的时间花在了迁移上，而不是能够迭代这些事情。我们提出的计划根本没有解决这个问题。而另一个团队提出了一个有点像要颠覆世界一样的计划。它就像，如果我们从头开始重新思考这一切会怎样？

这完全是我的一位同事曾经描述的“指枪模式”，意思是，是的，是的，是的，这将非常棒，伙计，互相指枪，却没有回答任何关于当我们试图支持数百名工程师时，它看起来像什么的问题。

我认为如果他们以“这是一个想法，但我们认识到我们会错过一些东西，因为我们习惯于支持十几个，而不是 180 个，并且有 30 倍的工程师来重塑事物”的态度出现，我不会那么生气。有时，这种新的视角可以让你走进来，说：

是的，我听到了。我们确实需要确保解决这个问题。如果我们尝试一下呢？也许它不会奏效，但如果我们尝试一下呢？有一种方法可以做到这一点。出现的团队并没有这样做。他们就像，不，这根本不会成为问题，伙计。我说，不，会的。也许我们可以解决这个问题。我很乐意你告诉我，让我们尝试这种解决问题的方法。但是，不，它实际上会成为一个问题。我们有很多经验可以告诉你，因为……

在战壕里。这是一个真正的问题。所以这非常像试图找到合作的方式，同时实际上只是持续地感到非常沮丧，因为我们的信息似乎没有传达给这个团队。他们就像，不，有一些你确实需要关心的问题。我们很乐意帮助你关心它们。但是

我们根本不相信你试图销售的东西，因为从我们的角度来看，你没有向我们展示你对问题空间以及你试图做的事情的实际困难的认真态度。我们认为也许值得这样做，但是 X、Y 和 Z 怎么办？只是得到根本性的敷衍了事的回应。这让我想起了两位投资顾问，一位说：

标普 500 指数基金，而另一位说：你见过比特币吗？NFT？他们真的很兴奋，对吧？这种热情令人兴奋。也许这种二分法过于极端。我的意思是，无论如何，这与我们的感受完全吻合。

所以 Chris 很生气。他很生气这个计划。他不知道他可以提出一个像停止一切并从一个巨大的项目开始，并承诺以后会加快速度的大想法。如果他知道这一点，你可以打赌他会制定一个计划，对吧？也许是一个不那么疯狂的计划，也许考虑得更多，但它肯定会有比三到五年更激进的时间表。但他甚至不知道停止世界是一个选择。

这里也存在某种文化冲突。Jim，Fingerguns 团队中一位非常资深的高级工程师，和 Chris，他们在很多事情上都意见不合。他们对软件工程的看法根本不同。因此，Chris 的团队向工程领导层提出了他们，你知道，经过深思熟虑的、非常周到的、尽管有点枯燥和长期的计划。领导层讨厌它。

他们可能很难理解五年计划。就是这样。是的。是的。我认为这是其中很大一部分。我们对这个计划并不兴奋，这使得它很难推销。让一群高管和领导对工程师提出的计划真正感到兴奋非常困难，而这个计划是，嗯，它会完成这项工作。有点喜欢，它解决了我们认为你让我们解决的所有问题。我们认为它很糟糕，但它比我们能找到的任何其他选择都要好。

所以大概所有这些都在高管层面沸沸扬扬。人们对一个模糊的问题抛出解决方案，这个问题最初是如何从Ember切换到React？但真正核心的事情可能是关于如何改变事情以便我们能够加快速度？我们如何在LinkedIn上更快地进行更改？而且，我想高管们也有自己的担忧，对吧？他们有数字要达到。他们面临市场压力。他们可能面临来自微软的压力，对吧？

一个计划是放弃所有随着时间推移积累起来的废料，以及一个计划是提高速度，提高速度，这听起来不错。然后克里斯休假过圣诞节。我回来后发现我们一直在出现网站故障问题，LinkedIn的用户群的一部分最多会持续大约20分钟，最终会看到一条消息，“对不起，出现了一些问题”，根本看不到LinkedIn.com页面。

好吧，我会告诉你两件事。第一，我讨厌值班和运维工作。第二，我是团队中最资深的工程师，被选中来做这件事。在我们试图找出这些问题的原因时，这完全是值班和运维工作。所以我基本上，我在圣诞节假期感到沮丧，然后回来想，好吧，我已经深吸了一口气。我可以做到。我们将弄清楚与其他团队的动态。

而发生的事情却是，情况很糟糕。而且另一件事仍在后台进行。现在你得花三个月的时间做你最讨厌的工作，试图找出那里出了什么问题。

关于这个事件，LinkedIn有一些预渲染服务。他们使用Node.js运行客户端代码，并从后端聚合所有数据，然后他们可以将其打包在一个大的请求中发送给客户端，将所有内容捆绑起来以便从数据中心快速交付给用户。但这存在内存泄漏，服务也宕机了。

所以我们到了这些盒子开始内存不足的地步，我们设计了一个系统来说，啊，你在内存使用方面超过了限制。我们将重新启动盒子。合理。但是我们缺少两件事。第一，没有对此发出警报。所以没有人特别收到警报，比如，“嘿，你有很多内存被杀死”。我不应该说没有警报。对此的警报不足。第二，有一个设置可以说明，这些容器可以同时重新启动多少个？

该设置是配置文件中YAML文件中的一个键，并且该键是键入的。但在某些时候，有人在那里设置了一个合法可能的数值，但这可能是该系统不应具有的数值。也许，我的意思是绝对的。

具体来说，这个数字大约是正在运行的这些服务的总数。它们都大约在同一时间启动。它们都获得大致相同数量的请求。因此它们的内存都以大致相同的速率增长，这听起来很糟糕。有人可能会注意到内存的增长，除了是的，警报不足。所以这种情况越来越严重。

情况已经变得非常糟糕，我们开始看到的是，每当有长周末或其他原因导致部署暂停足够长的时间时，我的意思是，这个错误配置的

切换意味着，哎呀，我们可以同时重新启动所有这些服务。你知道同时重新启动所有服务器会发生什么吗？突然它们不再响应用户请求。我们最终会遇到这种“惊群效应”问题，你会将其中一部分下线，这会增加对其余部分的压力。因此它们会开始更快地增加内存使用量，因为它们获得了更多流量。所以观察运行重复。我们最终会关闭整个数据中心范围内的这些服务器

在后台，还进行了一个调整大小的过程，其想法是我们将减少整个集群的CPU和内存使用量，以避免过度配置，我们认为我们有足够大的裕量，一切都会很好，如果我们实际上不需要新硬件，我们可以节省购买新硬件的费用。考虑这些事情的交集的一种方法是

这个调整大小的过程降低了上限。与此同时，内存泄漏正在提高房间里的水位。突然之间，水位到达了天花板。这与一个错误配置相结合意味着我们彻底完蛋了。所以我和其他一些工程师四处查看，说我们需要更好的警报，对这方面的更好可观察性。我们需要更高的弹性。没有理由

一个失控的节点服务器应该杀死正在管理这些节点进程的主进程。相反，我们应该杀死节点进程，并针对该条件发出警报，然后重新启动节点进程，因为这样我们就永远不需要关闭容器。我们永远不会陷入这种情况。就像这里有五个机会我们可以改进事情。没错。没错。失败是不可避免的，对吧？人类会犯错。

系统会遇到断电，世界上会发生一些事情。所以我认为软件工程与编程或黑客攻击，或者也许是这些的超集，是关于设计支持工程师完成其工作以获得这些产品成果的系统。我们是否有多个层次的弹性，我们可以在这里捕捉到某些东西出错的地方，以安全的方式修复错误，并发出警报，并说，“顺便说一句，某些东西发生了变化，现在出错了”。所以当它发生时，我们如何使系统（技术方面和人员方面）能够很好地响应？如果你有兴趣，你可以从这样的事件中学到很多东西。解决问题，是的，还要改进系统，防止问题再次发生。

克里斯探索的一个故障安全措施是，如果这些服务宕机，则只是回退到客户端获取。克里斯的方法很好地说明了他作为一名工程师的特点。他完全关注的不仅仅是软件，还有围绕它的系统，以及我们如何改进这些东西，对吧？他甚至还有一个名为“缓慢获胜”的播客，完全是关于稳定增长和持续改进的。

但是，是的，高层只是想让这个事件结束。也许这再次与速度有关。但无论原因是什么，事故会议开始变得有点紧张。所以我们每周多次为此进行站会。状态如何？我们在哪些方面取得了进展？让我们向外报告。向高管发送有关我们取得的进展的信息等。如果我们需要帮助，请寻求更多帮助。在其中一个周末，我们在运行一个实验并发现了一个新问题之后，

这是一个发现新问题的糟糕时机，因为Fingerguns团队的经理，让我们称他为Dave，刚刚接管了事故响应。他进来并拉了一堆其他人，这些人很好，但这很明显是一个案例，我不相信你能解决这个问题，我不相信你的任何答案。所以我将拉入这些人来取代你，这本身就令人沮丧。

这就是吉姆参与事故电话会议的原因。从那时起，情况只会越来越糟。为什么代码审查不能解决这个问题？这是吉姆的直接引述。我的回答是，好吧，它没有。

而且将来也不会再发生，因为人们会犯错，只会变得更好。同样，这不是一个答案，因为当轮换中的某个初级工程师认为，是的，这似乎是合理的时会发生什么。这个PR是由一位非常资深的SRE创建的。为什么我要质疑这个值是否合理？就像，是的，有很多盒子。这似乎很好。这类事情会发生。而且

关于工程系统的问题，我经常思考的一件事是，我们的系统是否仅能工作？或者这个过程是否仅能工作？或者这个工具是否只有在我像一位在其最佳状态下的资深工程师一样行事时才能成功？

或者如果我是一个正在度过糟糕一天的超级初级工程师，而我们真的希望我们的系统能够适用于后一种情况呢？这有助于我们所有人，因为有时，即使我是一位非常资深的工程师，有时我也会度过糟糕的一天。有时我的大脑感觉根本无法工作。系统在那些日子里仍然支持我，还是惩罚我？我真的不想受到惩罚。

事件正在向前推进，但压力越来越大。克里斯觉得这个团队根本不了解问题的范围，也不欣赏他深思熟虑的方法。为什么这还没解决？高管们对进展速度不满意。这就像，因为你积累了七年的技术债务和缺乏弹性，我们正在努力解决。而且

如果我们花三个月的时间来修复七年的疏忽，我认为这实际上还不错，这是我的看法。我记得告诉我的老经理，那是我在

任何工作中都感到最生气的时候，当Fingergun经理进来告诉我我没有做得足够好，因为修复这些根深蒂固的问题需要很长时间。这确实加剧了我对他们其他建议的感受，即对这种规模的工程缺乏认真态度，不，这些……

这些事情不容易解决。我们有无限数量的内存泄漏需要修复，并且由于这种特定内存泄漏的形状，它们都是对同一核心对象的引用。所以你可以修复其中一个，它不会改变系统的行为。我非常沮丧。

与此同时，这还启动了替代计划的实验，每个人都接受了这个计划，并表示，是的，这将奏效。许多工程师都表示，但是，不，你不应该问，但是怎么样？大约在同一时间，他的团队在一个重组敌意收购中接管了我的团队。这是一件……这是一件事。哦，他现在是你的经理。

是的，他是我的老板的老板，这种情况。不是我的直接经理，这很好，因为我可能会当场辞职。我们正处于一种，让我们拭目以待的状态。你知道，有时人们会担任不同的角色，他们最终会学习很多新东西。也许这一切最终都会好起来，对吧？克里斯是一个善于反思、考虑周到的家伙。他可以自问自答，也许我可以从这位新的跳级经理的业务重点中学到一些东西。他知道这是他需要改进的领域。

我谈论的事情是真正的问题，它们确实以我认为LinkedIn的一些人真正欣赏的方式使事情变得更好，我认为这确实对使用LinkedIn的人产生了影响。但它们从来都不是业务领导层在任何特定时刻最关心的问题。我认为这种脱节是

为什么我们最终处于非常不同的位置，以及为什么很难沟通这些事情的价值的原因。当克里斯进入这种更具反思性的状态时，反思他的挫败感，他注意到他在建立关系方面有一些弱点。我的许多同事与我甚至难以联系或弄清楚如何与之合作的人有私人关系，因为他们会在自助餐厅看到他们。

具体来说，克里斯正在考虑吉姆。我与之交谈的其他一些人遇到的挑战较少。其中一部分只是，你知道，这位特定工程师与我们工程领域的联系方式。伙计，那里有一些挑战。

但有些人与他有着非常良好的工作关系，因为他们最终会坐在自助餐厅里和他一起吃饭，因为那里会有很多人。当你处于某种激烈的技术争论之中时，这确实很有帮助，因为你已经和某人一起吃过午饭，或者以其他方式建立了这种关系。但是当你拥有非常强大的面对面文化，并且你的员工中有很高比例的人都是面对面工作时，

这会在这些事情中体现出来，因为作为一种公司文化，作为一种工程文化，你的规范都是围绕着。是的，我们会在咖啡馆里见面，我们会在走廊里偶遇。人们会讲述关于最终在首席执行官旁边的浴室里相遇的故事，对吧？这是一个有趣的动态和一个有趣的地方，你可以看看，你正在洗手，而首席执行官也在洗手。我可以看出这会产生什么影响

与最终成为工程高级副总裁或首席工程师的人进行持续的物理互动，你只是认识这些人。这提出了另一个观点。我们一直关注这种技术冲突，速度与可持续性，但也许它更多的是一种社会问题。压力下的人们听不懂彼此。我的意思是，我们只有克里斯的故事，但是……

也许这是一个社会问题。Charity Majors在最近的一篇文章中有一句很棒的引言，她说，在足够高的级别，工程师或经理，没有纯粹的社会问题或纯粹的技术问题。它们都是社会技术的。你必须能够识别出这是什么障碍。是社会方面还是技术方面，或者通常是两者的某种混合，比例是多少，我需要做什么来解决这个问题？是的。

所以也许两者都是。无论如何，从事件中退一步，克里斯发现Fingergun的计划正在取得进展。它正在获得关注，并且它的范围越来越大。现在它涉及到重写移动应用程序和桌面应用程序。我们将重新思考我们在LinkedIn上构建所有产品的方式，这令人兴奋。其中有一些非常有趣的部分。还有一种说法是，你可以说我和我的经理和我的团队输了。

这不会是描述它的错误方式。好吧，我的计划失败了，无论如何。我并不太喜欢它。我们可以让你的版本更好吗？哦，你甚至不想听到那些读起来对你来说除了对这件事的热情之外什么都不是的问题。我说，我想让它变得更好，但我们必须解决这些问题才能做到，哦，你甚至不想听到。好吧，我可以继续撞墙。

我和那位经理进行过谈话，他用字面上的话告诉我，你太理想化了。你对底线不够关心。你应该改变你的价值观。我说，不，事情不会这样发展，伙计。外面，我做了政治。

我理解这种观点。我知道你的意思。在内心深处，我头脑中的一个小开关正在翻转，说，不，不，不，警告警报，警报器在我周围响起。克里斯认为他们对速度的需求使他们对真正的问题视而不见。我们在代码库中遇到的许多问题都是直接由过分重视速度和拒绝停下来说，好吧，

那边的那个东西，那条次要路径不起作用。让我们修复它，或者让我们摆脱它。这两个都是不错的选择，但拒绝这样做，并不断地知道我们必须发布下一个功能，以及我们能多快发布它，以及我们必须发布下一个功能，以及我们能多快发布它，当速度成为主要或驱动价值时，其他一切都是从属于它的，它会让你处于一个也许你最初速度很快的位置，

但你无法长期维持它。这实际上是代码库随着时间的推移而老化的经典模式，如果你不不断地投资于它们，但你不断地扩展它们，你最终会到达我们所在的位置。我看到提出的所有内容都是关于最大化速度的，甚至没有暗示你将如何处理这些

这些其他事情。我一直在思考这个问题，我尽力给了它一个公平的机会，这里有一些有趣的想法。这里有一些有趣的技术方向。但我也在回忆我为什么离开我以前的工作，这最终是一个非常糟糕的倦怠案例

我得了可怕的偏头痛，我一生中从未有过如此严重的胃痛，无法运动，在随机时间随机爆发哭泣，恐慌发作。那是一段糟糕的时光。我不推荐倦怠。这不好玩。如果我继续走这条路，我知道结果会怎样。这是一个糟糕的地方。我不想再次落到那里。

我可以待在一个我不断努力不生气的地方，因为我，你知道，我尽力在那段时间里不生气。但是当你每天遇到的东西让你积极地努力不生气时，这至少会让你的工作变得不那么有趣。我可以，你知道，尝试用我这里的小划艇来转向这艘泰坦尼克号，并为我失败而生气。所以这行不通。用你的桨推它。无法转向泰坦尼克号。对。

或者我可以说，我只是要朝那个方向划桨。泰坦尼克号的事情暗示我认为他们正在驶向冰山。我主要指的是事情的规模，而不是冰山方面。我希望他们不要撞上冰山。那将是悲伤的。你知道，一艘迪士尼游轮。我不会用一艘划艇和一个桨来转向一艘迪士尼游轮。所以我没有。我说……

我已经学到了很多东西。我现在对在一个拥有300万行代码的应用程序上工作是什么样的有了一些了解，该应用程序迁移到了一家大型公司的TypeScript，并考虑了这些大问题。现在我可以去做其他事情，而不会倦怠，也不会每天都对我的工作感到生气，或者不会努力避免每天都对我的工作感到生气。我不会花我生命中的数年时间试图以我最终不相信的方式和在我不相信的事情上进行构建。生命太短暂了。那将是一种浪费。

好吧，这很糟糕，但我猜是时候离开了。不是出于怨恨或恶意或任何其他原因，而是说我们正朝着不同的方向前进。也许LinkedIn的这个特定角落在这个特定时刻所采用的价值观并不在道德上令人反感，但它们不是我的价值观。

这就是节目。感谢克里斯如此坦诚。我觉得这样的故事一直在一百个不同的地方上演。这些社会技术问题，人们就解决问题的正确方法发生冲突，但他们从未在小圈子之外被听到。所以谢谢你，克里斯，分享你的故事。在撰写本文时，克里斯正在寻找工作。你可以在chriscrycho.com找到更多信息。我会在节目说明中添加一个链接。

听到克里斯正在寻找与他的个人价值观相符的角色，你应该不会感到惊讶。这是我们聊天中一个重要的收获。你需要与你的团队和你的组织就什么重要达成一致。

有时这些事情会发生变化，你只需要分开。但具体来说，克里斯正在寻找一个可以帮助他推动工程卓越的角色。他对寻找改进软件构建方法非常热情。他有一篇关于这个主题的完整博客文章，以及他所说的棘轮。你应该在他的网站上查看一下。如果你喜欢这个播客，并且你已经听完了，除非你讨厌听或其他什么，否则我认为你喜欢。

如果你想支持这个播客并让它继续下去，你能做的最好的事情就是访问corecursive.com/supporters。你知道，除了个人之外，我没有这个播客的赞助商。链接在节目说明中。你可以加入作为播客支持者，你将可以访问额外剧集并加入社区。直到下次，非常感谢你的收听。