本文翻译自 Why senior developers fail to communicate their expertise，作者 Nair。

资深开发者是「问题回避者」

当我加入一个团队时，我会遇到两种资深开发者。

第一种会说类似这样的话：

“我发现了一个新工具，挺酷的……”

“这家公司就是这么做事的，所以……”

“你看这个 HackerNews 帖子说这是最佳实践，我们也许应该……”

我不喜欢这种资深开发者。有点自我保护意识，在行业里待了很久，可能人缘不错。但跟我不是一个频道。

然后还有第二种资深开发者：

“我们真的需要这个吗？”

“如果我们不做这个会怎样？”

“能不能先凑合用着？等这件事变得更重要的时候再回来处理？”

啊，这才是我心中的资深开发者。回避者、精简者、复用者。他们想尽可能少地写代码。

为什么？因为他们紧盯的是专业软件开发中一个独特的怪物：复杂性。

特殊情况、if 条件、新的数据库表、新组件——统统令人厌恶。资深开发者希望这些东西越少越好，会花大量时间确认自己是否真的需要增加代码。

因为往系统里加东西，就是在增加复杂性的风险。

当然，当然，这当然是一种简化。确实有擅长攻克未解问题、找到创新方案的资深开发者。

但最终，如果你对一个运行中的系统负责，你会害怕复杂性。

那为什么呢？复杂性的坏处是什么？为什么其他人理解不了？

业务其他人害怕的是不确定性

我们用两个循环来简化理解一个企业。

第一个循环——市场人员、销售、产品经理、CEO，他们都生活在这里：

这个循环的主要目标是尝试并学习。业务希望把东西推向市场，然后获得反馈——看看自己是否有价值。

这个循环里的怪物是不确定性。

不确定性很残酷，因为没有哪种策略能保证成功。再加上时间因素（营销/销售的薪酬、创始人的工资、产品经理需要的数据），尽快把东西推向市场就成了在截止日期前减少不确定性的唯一方式。推向市场的东西越多，得到的反馈越多，（潜在地）减少的不确定性就越多。

这个循环——所有公司都从这里起步——追求的就是速度。

但当企业有了客户之后呢？

资深开发者非常关心稳定性

现在，第二个循环来了。为服务付费的人。

很多资深开发者就在这个循环里。这个循环的主要目标是服务的延续性和保障。

让系统持续运行、可理解、可调试、可修复、可教学、可稳定。

资深开发者担心稳定性，因为他们承担着企业持续服务客户的责任。

什么会威胁这一切？

复杂性。

复杂性让系统变得难以理解、难以调试、难以修复、难以教学，最终——难以稳定。

复杂性上升 = 稳定性下降 = 资深开发者失职 = 糟糕糟糕不开心，支付中断，所有人伤心。

所以，如果第一个循环的目标是减少不确定性，第二个循环的目标就是管理复杂性。

但这为什么会导致沟通失败？

因为一旦你有了客户，两个循环就在同时运转。企业需要同时探索可能性和服务客户。

现在你可能已经能猜到这篇文章标题的答案了。

根据你处于哪个循环，你面对的问题框架完全不同（这也是为什么我觉得开发者对 AI 的看法会分裂——有些人在第一个循环工作多一些，有些在第二个循环多一些）。

第一个循环里的人讲的是这个故事：

但资深开发者在第二个循环里讲的是另一个故事：

两个故事对不上。

业务方越是要求构建和添加功能，资深开发者越是想回应：”呃，不行……维护成本……可理解性……持续开发的速度……长期的生产力……”。

但这丝毫不能解决业务其他人减少不确定性的需求。

文案写手的诊断：你不能用自己的问题去解释别人的问题。

文案写手的处方：你需要把你的解决方案描述成同时也能解决他们问题的方案。

资深开发者沟通失败，是因为他们用复杂性管理的语言来表达自己的问题，而实际上他们应该用不确定性减少的语言来表达自己的解决方案。

承认公司其他人在追求减少不确定性，资深开发者就能用自己的专业能力来帮忙。

而资深开发者最有用的技能是什么？不愿构建不必要的东西；发现复用已有成果的机会的能力。

需要收集调研数据？ Google Forms 就够了。

需要构建一个完整的新功能来测试？ 在现有 UI 上放个按钮，看看有没有人点击，试过了吗？

需要新的分析服务？ 我们需要分析来做的最重要的决策是什么？能不能从一个决策、一个图表、一个指标开始？

想给我烤一个完整的生日蛋糕？ 在我的三明治上插根蜡烛就行了。

这就是资深开发者学会做的事情：他们学会如何通过巧妙复用现有软件来满足人们的需求。

但你怎样沟通这些，又不用给每个人发长篇大论？

文案写手喜欢把多个信号浓缩成一句话。所以，每一位资深开发者必须学会的魔法句式是：

“我们能试试更快的方式吗？”

「更快」承认了对方真正在追求的东西；「某种方式」暗示了另一种达成目标的路径；「试试」暗示了不完美，但也意味着够用的可能性。

这句话完美地切中了公司其他人的需求——用速度减少不确定性——同时让资深开发者施展自己的专长：精简、复用，如果生活真的眷顾你，回避。

就是这样。这就是我对文章标题的回答：资深开发者用复杂性的语言说话，而其他人担心的是不确定性。

但是！重要的但是！

AI 现在似乎让这一切都变得毫无意义了，不是吗？为什么要精简？为什么要复用？为什么要回避？AI 能在那么短的时间里构建那么多东西。

嗯，它目前还做不到资深开发者仍在做的一件事。

承担责任。

资深开发者更像是编辑而非作者

资深开发者非常关心理解系统，因为理解意味着在出问题时能修复它；意味着在系统需要扩展时有能力扩；更重要的是，意味着能持续、可靠地为付费客户提供服务。

AI 威胁着这种可理解性。它在提高推向市场的速度方面表现惊人，但它也影响着另一个循环——资深开发者负责的那个循环。

如果你有一堆 AI Agent、初级开发者、非开发人员、以及你的投资人和他们的母亲都在往系统里加代码，你会得到一个只顾快不顾稳的系统。

AI 就是个彻头彻尾的破坏者。它恶化了可理解性、可修复性、可调试性、可教学性、可保障性——什么”可XX性”都没了。

AI 做了这一切，却不承担任何责任。

不好。这就是资深开发者最大的担忧，但没人把它当回事。

幸运的是，资深开发者还有几招。

那就是：解耦。

很长一段时间里，软件开发者是唯一能构建软件的人。他们负责两个循环。

一个系统，支撑两个目标。

如果我们有两个系统，每个目标一个呢？

一个类比：小说作家急着完成初稿（通常叫做「呕吐稿」），然后再提取出有效的部分，去掉无效的部分。在最初的快速写作之后，有一个编辑过程。编辑的工作是提取出运作良好的部分，将其塑造成一个有凝聚力的整体。

如果我们有一个专注于速度的系统呢？所有专注于让想法成真的人都可以在这里工作。AI Agent、我们自己生成但未审查的代码、初级开发者、市场人员等等。

我们可以把这个叫做系统的「速度版」。它不需要可理解，目标是让东西好到足以推向市场获取反馈。

然后如果我们有第二个专注于稳定性的系统呢？

我们可以把这个叫做系统的「规模版」。它由资深开发者设计，追求稳定、可理解和可扩展。

「速度版」让业务其他部门继续从市场中学习，同时资深开发者构建一个经过良好审查和理解的系统的后续版本。

而且，「规模版」的设计会受到「速度版」中有效和无效部分的影响。

功能在「速度版」上构建，然后在「规模版」上稳定下来。

这在实践中具体长什么样可能还不清楚，但核心思想是有一个沟通良好的解耦——解释追求速度和追求稳定性之间的区别。

想象一下，你被要求构建一个有野心的东西，你说：

“没问题，速度版我 3 天搞定。然后规模版大概 6 周。”

他们得到了他们想要的东西——速度和动力。你得到了你想要的东西——观察和设计。

也许可行？

你怎么看，资深软件开发者？

或者我应该说——资深软件编辑？