Why senior developers fail to communicate their expertise

# 为什么高级开发者无法有效传达他们的专业知识 来源：https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise § [高级开发者是问题的规避者](https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise#a-senior-developer-is-a-problem-avoider) ## 01 高级开发者是问题的规避者 当我加入一个团队时，我会遇到两种类型的高级开发者。第一种会说这样的话： > “我发现了这个新工具，它挺酷的……” > “那家公司是这样做的，所以……” > “看这篇 HackerNews 的文章，他们说这是最佳实践，我们大概应该……” 我不喜欢这种高级开发者。他们有点自我保护意识，在行业内待了很长时间，可能是个擅长与人打交道的人。但与我不同频。 还有另一种高级开发者： > “我们真的需要那个吗？” > “如果我们不做这个，会发生什么？” > “我们现在能不能先凑合一下？也许等以后这个问题变得更重要时再回来处理？” 啊，宝贝，这才是我的高级开发者。规避者、简化者、回收者。他们希望尽可能避免开发。为什么？因为在专业软件开发中，他们猎取的是唯一的怪物：**复杂性**。 特殊情况、if 条件、新的数据库表、新的组件。全都是讨厌的东西。高级开发者希望这些东西越少越好，花大量时间确保他们确实需要添加更多代码。因为向系统添加内容意味着冒着增加复杂性的风险。 是的，是的，当然这很简化。有些高级开发者擅长承担未解决的问题并找到新的创造性设计。但归根结底，如果你要为一个正在运行的系统负责，你就会害怕复杂性。 那么，为什么是这样呢？复杂性有什么坏处？为什么其他人都不明白这一点？ § [企业的其他部分害怕不确定性](https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise#the-rest-of-the-business-is-scared-of-uncertainty) ## 02 企业的其他部分害怕不确定性 我们将用两个循环来简化什么是企业。这是第一个循环；营销人员、销售人员、产品经理、CEO 都生活在这里： 手绘图展示了企业的第一个循环：营销人员、销售人员、产品经理和 CEO 将想法推向市场，并将他们学到的东西反馈到下一次尝试中。 这个循环的主要目标是尝试学习。企业希望将事物推向市场，然后获得反馈，看看他们是否有价值。 对于身处这个循环的人来说，怪物是**不确定性**。不确定性是残酷的，因为没有策略能保证成功。当加上时间成本（营销/销售的补偿、创始人的薪资、产品经理的数据）时，在截止日期之前尽可能快地将事物推向市场似乎是减少不确定性的唯一方法。 你能推向市场的东西越多，你能从中获得的反馈就越多，你就能（潜在地）减少不确定性。这个循环，以及所有公司都从这个循环开始，关乎纯粹的、原始的**速度**。 但当一家企业获得客户时会发生什么？ § [高级开发者非常关心稳定性](https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise#senior-developers-care-a-lot-about-stability) ## 03 高级开发者非常关心稳定性 啊，现在，这是我们的第二个循环。为服务付费的人。 手绘图展示了企业的第二个循环：付费客户使用现有服务，而团队努力维持该服务的运行。 很多高级开发者发现自己身处这个循环。这个循环的主要目标是服务的延续和保证。保持事物运行、保持事物可理解、保持事物可调试、保持事物可修复、保持事物可教授、保持事物稳定。 高级开发者担心稳定性，因为他们负责确保企业继续为客户服务。那什么会危及这一切？**复杂性**。 它使系统更难以理解、更难以调试、更难以修复、更难以教授，最终，更不稳定。 复杂性上升 = 稳定性下降 = 高级开发者未能履行职责 = 非常糟糕，支付中断，大家都难过。 所以，如果第一个循环的目标是减少不确定性，那么第二个循环的目标就是**管理复杂性**。 但这为什么会导致沟通失败？因为一旦你有客户，这两个循环就会同时运行。企业需要同时探索可能性并为现有客户服务。 手绘图展示了企业的两个循环并排运行：一个追求市场反馈，另一个保持付费客户得到服务。 好吧，现在你可能能发现我对标题中问题的答案。 取决于你把时间花在哪个循环上，你的问题会被不同地定义（这就是为什么我认为开发者在 AI 问题上的意见会分裂；有些人更多地专注于一个循环而不是另一个）。 手绘图展示了同一项开发工作如何被每个循环中的人以不同的方式定义——不确定性 versus 复杂性。 这是第一个循环中人们的故事： 手绘图展示了第一个循环的故事：请求涌入，团队竞相交付它们，以便企业能从市场更快地学习。 但这是第二个循环中高级开发者的故事： 手绘图展示了第二个循环的故事：每个新请求都增加复杂性，威胁到高级开发者负责的系统的稳定性。 故事不匹配。 高级开发者收到的构建和添加到系统中的请求越多，他们就越想回应“呃……复杂性……维护成本……可理解性……后续开发速度……长期生产力……”。 但这无助于解决企业其他部分减少不确定性的需求。 文案诊断： > 你不能用你自己的问题来解释别人的问题。 文案处方： > 你需要将你的解决方案描述为对他们问题的解决方案。 高级开发者沟通失败，是因为他们在应该用**减少不确定性**的术语表达解决方案时，却用**管理复杂性**的术语表达了自己的问题。 通过承认公司其他人寻求的是减少不确定性，高级开发者可以利用他们的专业知识提供帮助。 那么，高级开发者最有用的技能是什么？ 不愿构建不必要的事物；能够发现重复利用已构建事物的机会。 *需要收集调查数据？* Google 表单，宝贝。 *需要构建一个全新的功能来测试它？* 你试过在现有的 UI 中放一个按钮，看看人们是否点击它吗？ *需要新的分析服务？* 我们需要分析的最重要的决定是什么？我们可以从一个决定、一个图表、一个指标开始吗？ *你想给我烤一个完整的生日蛋糕？* 就在我的三明治上放一根蜡烛吧。 这就是高级开发者学会做的事情：他们学会通过善用现有软件来满足人们的需求。 但你如何在不发送整篇文章的情况下传达这一点？ 文案爱好者喜欢将多个信号提炼成单个短语。因此，这是每位高级开发者必须学会的魔法短语： **“我们能试试更快的方法吗？”** 使用“更快”承认了他们真正寻找的东西；“某种方法”暗示了另一种实现它的方式；“尝试”暗示了不完美，但也暗示了它可能足够好。 它完美地切中了公司其余部分的需求——通过速度减少不确定性，同时允许高级开发者发挥他们的专业知识：减少、重复利用，如果生活真的是祝福的话，就避免。 就是这样。这就是我对帖子标题的回答：高级开发者用复杂性的术语交谈，而其他人担心的是不确定性。 但是！大大的但是！ AI 现在似乎让这一切都变得毫无意义，不是吗？为什么要减少？为什么要重复利用？为什么要避免？AI 可以在如此短的时间内构建如此多的内容。 啊，嗯，它还不能做高级开发者仍然在做的一件事：**承担责任**。 § [高级开发者作为编辑多于作家](https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise#senior-developers-as-editors-more-than-writers) ## 04 高级开发者作为编辑多于作家 高级开发者非常关心理解系统，因为理解允许在出现问题时修复它。它允许在系统需要增长时智能地扩展它。最重要的是，它允许持续、可靠地为付费客户服务。 AI 威胁到这种可理解性。它在提高将事物推向市场的速度方面非常出色，但它也影响了另一个循环，即高级开发者负责的那个。 如果你有一堆 AI 代理、初级开发者、非开发者，以及你的投资者和他们的母亲向系统中添加代码，你会得到一个为了速度而牺牲稳定性的过度补偿的系统。 这是处于两个循环中的企业： 手绘图展示了企业的两个循环并排运行：一个追求市场反馈，另一个保持付费客户得到服务。 以下是 AI 如何影响这两个循环： 手绘图展示了 AI 加速第一个循环同时破坏第二个循环——以可理解性和稳定性为代价换取额外速度。 别提维持稳定性了，AI 简直是一个破坏稳定性的因素。它恶化了可理解性、可修复性、可调试性、可教授性、可保障性，所有这些该死的“性”。 AI 这样做却不负任何责任。真不友好。 这是高级开发者的主要担忧，却被忽视了。 幸运的是，高级开发者有一些技巧。具体来说：**解耦**。 长期以来，软件开发者是唯一能构建软件的人。他们负责这两个循环。 手绘图展示了一个单一的软件系统，历史上支持这两个循环，开发者同时负责速度和稳定性。 这是一个系统支持两个目标。如果我们有两个系统，每个目标一个呢？ 一个类比：小说作家急于完成初稿（通常称为“呕吐草稿”），然后提取有用的部分并去掉没用的。在最初的快速写作之后有一个编辑过程。编辑的工作是采取工作良好的部分，并将所有内容塑造成一个连贯的整体。 如果我们有一个仅用于速度的系统怎么办？ 所有专注于让事物成行的人都可以在这里工作。AI 代理、我们自己生成且未经审查的代码、初级开发者、营销等。我们可以称这个系统的版本为“速度版”。 它不必是可理解的，目标是将事物做得足够好，以便将其推向市场获取反馈。 然后，如果我们有一个专注于稳定性的第二个系统怎么办？ 我们可以称这个系统的版本为“规模版”。它由高级开发者设计，旨在稳定、可理解和可扩展。 “速度版”允许企业的其他部分继续从市场中学习，而高级开发者则构建一个经过良好审查且可理解的系统的后续版本。 此外，“规模版”的设计受到“速度版”系统中有效和无效部分的影响。 手绘图展示了提议的拆分：一个用于快速市场学习的“速度版”系统，以及一个由高级开发者在其后稳定的“规模版”系统。 功能在“速度”上构建，然后在“规模”上稳定。 这在实践中是什么样的可能不清楚，但思想是要有一个良好沟通的解耦，解释追求速度和追求稳定性之间的区别。 想象一下，你被要求构建一些雄心勃勃的东西，你说： > “没问题，我将在3天内准备好速度版。然后在大约6周内准备规模版。” 他们得到了他们想要的，速度和动力。 你得到了你想要的，观察和设计。 也许吧？ 你的想法，高级软件开发者？ 或者我应该说，高级软件编辑？