构建卓越开发者体验的核心原则
我在"开发者体验"领域工作了20多年，通过改进工具、系统和流程来帮助开发者提高效率、效果和幸福感。我曾深入参与Google和LinkedIn的开发者体验关键方面设计，与此领域的研究社区保持密切联系，并不断与各大科技公司的开发者体验领导者交流。
我想为您阐述构建卓越开发者体验的基本原则 - 在这个领域需要理解的最重要事项。我只对每个项目给出概述，可能会遗漏一些要点（因为要涵盖的内容很多），但希望这是对关键点的良好概述。
基本概念
在优化开发者体验时，您主要关注三个核心要素：
周期时间（又称迭代时间）：从开发者有任何意图到该意图完成之间的时间。
专注度（又称"心流"）：开发者保持专注于正在处理的任务而不被打断的能力。
认知负载（又称所需知识和决策）：开发者为了完成任务需要知道多少知识，以及他们必须做出多少决策才能完成任务。
让我们更详细地讨论这些要点。
周期时间（又称迭代时间）
编写软件的过程涉及大大小小的循环，基本上是开发者有意向某事到结果在物理世界中实现之间的时间。最小的循环如"我打算写这行代码"，或"我打算运行这个命令行工具并查看输出"。最大的循环如"我打算通过创建产品并让人们使用它来解决问题"，或"我们打算以需要100人一年的方式重新设计我们的系统"。
通常，加速大循环的方式是加速小循环。如果您只专注于加速大循环，结果的质量往往会受到影响。例如，假设我看到一个团队需要两周时间才能将任何更改部署到生产环境。如果我直接进去说"不惜一切代价加快部署速度"，而不说其他任何话，那么团队可能会以损害最终结果质量和软件可维护性的方式走捷径。
然而，如果我更深入地调查，我会发现有些小循环花费的时间太长。也许代码审查者需要很长时间才能回复。可能测试运行时间太长，因此开发者每次进行小更改时都必须等待太久。可能部署工具太难使用，因此开发者在使用时遇到困难并避免使用它。
另一方面，加速较小的迭代总是安全的（只要您发现它们确实存在问题）。例如，假设代码审查花费的时间太长。通常，在这种情况下您会发现审查者只是回复不够快。这里的解决方案是专注于审查者响应时间，而不是整体代码审查时间。例如，您经常发现在这种情况下，代码作者发送的PR太大，因此审查者需要很长时间来审查它们。
代码审查本质上是一个质量过程，因此您希望最终结果是高质量的代码。有时开发者和审查者之间需要来回五轮，开发者提交更改，审查者请求修改，直到最终结果良好。您希望这五轮都能发生。但您希望每一轮都能快速发生。如果每一轮都快速发生，您会发现PR审查时间只会达到应有的长度，开发者和审查者都对过程感到满意。
这适用于软件开发的各个部分。如果您发现人们编写代码需要很长时间，值得研究诸如：他们的构建需要多长时间？在开发过程中在本地运行测试需要多长时间？他们能多快获得做出决策所需的信息？
还值得注意的是，每个循环都是某种形式的观察、决策、行动循环，我在其他地方广泛写过相关内容。如果您致力于改进开发者体验，最好的改进方法之一是让开发者更容易观察事物。在他们需要的时候将所需信息直接放在他们面前。（永远不要将他们不需要的信息放在他们面前，因为这对认知负载不利，我们稍后会讨论。）例如，当测试失败时，失败应清楚指示问题所在，这样开发者就不必费力去弄清楚如何修复它。当他们创建新项目时，清楚说明他们的选项是什么（如使用什么语言、框架、如何命名项目等）以及从哪里开始。只需思考：“我如何做到让开发者永远不必思考，只需查看某物就知道下一步该做什么？”
专注度（又称"心流"）
软件开发是一项需要数小时深度专注才能成功完成的活动。开发者正在构建他们正在处理的事物的非常复杂的心理结构，并使用该心理结构做出决策和编写代码。他们不断思考（或在笔记中写下）“哦，完成这件事后别忘了做那件事”。这种专注状态通常被称为"心流"。
当开发者被打断得太彻底或太频繁时，这种复杂的心理结构就会消失，当他们回到任务时必须重新构建。他们有可能忘记脑海中"接下来做这个"的事情，并因此实际交付了损坏的软件。
我们将这种形式的中断称为"上下文切换"，此时开发者的注意力主要集中在编码以外的其他事情上。当您强制开发者进行上下文切换时，他们可能需要十或十五分钟才能完全重建他们在专注于编码时拥有的心理结构。因此，小的中断可能非常昂贵。
中断持续多长时间才会导致上下文切换因人而异。我见过从30秒到2分钟的数字。这也取决于中断是什么。如果中断是一个不需要思考的电话通知，您看了30秒并关闭它，这可能不会打断专注。如果中断是您收到的某个非常复杂的失败消息作为警报，那么无论阅读需要多长时间，它都可能打断专注，因为它需要太多的脑力工作，以至于打破了开发者关于当前任务的心理结构。
根据我的经验，如果中断引起不良情绪反应，它们也可能更具破坏性。对某事感到不安会分散注意力，以至于难以保持专注于您正在做的工作。您觉得必须对不安的事情做些什么，或者至少思考它。如果有人给我发送令人不安的消息，或者我的某个工具以极其令人沮丧的方式行为，那么即使中断只有5秒钟，也可能打破我的专注。
如果您从事开发者体验工作并希望改进心流，请思考以下问题：我的工具是否强制开发者在进行编码、测试或调试任务时从事一些复杂的非编码任务？我们是否确保开发者有多个不受干扰的小时来专注于编码？我的工具、系统或流程是否做了让开发者感到非常沮丧以至于打断他们专注的事情？
这里的另一个关键点是：开发者是否清楚地知道他们所做工作的目的并有明确的方向？也就是说，我是否被赋予了一个明确的任务，我知道为什么要做这个任务，为谁做，以及预期的结果是什么？否则，我自己的困惑会经常打断我的专注。我将不得不不断问同事我应该做什么。我会坐在那里思考我的任务，而不是实际去做。另外，我可能无法构建最好的东西，因为我没有所有需要的数据来做出好的决策。
专注是另一个您希望将清晰信息直接放在人们面前的领域，他们可以使用这些信息来观察、决策和行动。不要让他们中断工作去寻找现在需要的数据。有时，“我要去学习一些东西"是开发者的整个任务，在这种情况下，只要他们能轻松找到他们正在寻找的内容，让他们搜索信息就不是中断。但如果他们正在编码，他们只需要知道诸如"这个函数做什么"之类的信息，那么这些信息应尽可能快地在他们的编辑器中直接可用。
认知负载（又称所需知识和决策）
“认知负载"是我不太喜欢的术语，因为它含义不明确。为了开发者体验的目的，我们所说的意思是：开发者为了执行任务需要知道多少？开发者在执行任务时被迫做出多少决策？我将分别讨论这些要点。
减少所需知识
有许多人认为开发者应该尽可能多地了解他们正在做的事情，我同意他们的观点。然而，通过移除他们必须知道才能完成任务的事情，开发者的生产力和体验得到了显著改善。当开发者必须编写1和0来编码时，他们的生产力要低得多。用汇编语言编写比用Java或Python等高级语言编写效率低得多。理解这些语言如何转换为汇编是否能让您成为更好的程序员？是的，确实如此。您是否应该为了完成每个编程任务而必须知道这一点？不。
这是大多数拥有开发者基础设施的团队在公司中表现非常差的领域。他们制作的工具要求开发者深入了解该工具才能完成工作。如果开发者不需要与一百个这样的工具交互来完成工作，那也没关系。当然，有时会有更复杂的任务需要开发者深入并真正了解其中一个工具。但理想情况下，每个工具应该足够直观，开发者根本不需要学习太多就能成功使用它。更理想的是，应该重新设计基础设施，这样他们除非真的需要，否则根本不必使用该工具。
减少选择
这是开发者体验中最有争议的方面之一，但在多家公司长期经验后，我可以自信地说：开发者只需要做出他们需要做出的选择。
一些开发者认为必须允许他们对系统做出每一个选择 - 使用什么编程语言编写，使用什么包管理器安装依赖项，使用什么构建工具，如何缩进代码，使用什么监控系统，使用什么部署系统等。我理解这一点 - 我对自己最喜欢的东西也有强烈的意见。但大多数时候，像这样的决策实际上只是强迫团队做他们不应该做的工作 - 分散他们注意力，无法完成他们试图完成的核心任务。
极端地说，想象一下每次开始处理系统更改时，您必须全面研究选择什么编程语言，从10个做同样事情的选项中使用哪个库，使用什么构建工具，与每个人争论制表符与空格，决定使用什么代码审查工具，并通常做出软件工程中涉及的每一个其他可能的决策。您永远无法完成任何事情，对吧？让开发者实际上最有效、最高效和快乐的是只专注于他们需要做的任务，而不必不断做出关于该任务之外的无数事情的决策。
在公司内部，我甚至会说开发者不应该被允许做出他们不需要做出的决策。这听起来很极端，但做得好时，实际上会带来出色的开发者体验。
问题是开发者经常相信他们需要对他们实际上不需要的事情做出决策，但他们要等到几个月或几年后才能看到后果（或者他们无法理解决策将如何影响更大的业务）。例如，不应允许开发者选择世界上任何编程语言来完成他们的任务 - 这迫使他们围绕该语言开发一堆新库或基础设施，而不是专注于他们实际需要完成的任务。这对业务也有大量其他不良长期后果，当您只是一个真正喜欢特定语言的个体开发者时很难看到这些后果。（我再次理解！我是一个编程语言爱好者，有很多强烈的个人偏好。）
然而，必须非常小心这个原则 - 需要允许开发者做出他们需要做出的决策。我观察过很多人编码，每个人使用他们的编辑器和周围工具的方式都大不相同，因为人们的思维方式大不相同。您不能对人们工作流程的某些部分施加太多硬性约束，因为这会显著损害生产力，而对整个业务没有任何实际好处。我从未见过公司说"每个人都必须使用这个编辑器"能带来任何好处。我见过"我们将为一个编辑器提供比另一个更多的支持，但我们仍将把所有功能作为命令行工具公开，因此您可以使用任何您想要的东西"带来好处。
您必须小心的另一件事是，如果您的基础设施限制了开发者可以做出的决策，您需要真正做好集中维护该基础设施的工作。也就是说，需要一个中央团队做出这些决策并持续对结果负责。如果您说"每个人都必须使用这个构建工具来处理他们的Java项目”，那么您最好确保该工具现在和将来持续对每个人都有效。有时您需要提供一组有限的选择。例如，如果您只是说"每个人都只能用Java编写所有内容”，您会发现它不是适合所有事情的语言。
做好这一点的关键是深入了解您的开发者的需求和他们工作的系统的需求。您需要深入了解他们解决的问题类型，以便知道需要或不需要做出什么决策。您需要能够随着时间的推移适当调整这一点（更改策略），而不会完全开放并允许混乱统治。
事实是，大多数开发者不想对他们的系统做出每一个决策，然后被迫做一堆定制的低级工作才能开始他们的任务。他们喜欢编程是因为他们可以告诉计算机做某事并让它做，并且因为他们喜欢解决帮助用户的问题。让他们专注于完成这些所需做的事情，而不是软件工程整个宇宙中每一个其他可能的决策或任务。
我在《推理与选择》中写了更多关于这方面的内容，包括讨论这个原则如何使推理系统变得更容易。这是任何软件系统最重要的方面之一：无需运行就能推理其行为的能力，而减少选择的原则有助于实现这一点。
请注意，我上面主要从基础设施级选择的角度讨论了这一点，因为如果您是从事开发者体验的中央团队，这通常是最重要的，但该原则广泛适用。在团队内部，您可以说"这些是我们的代码模式，请不要使用其他模式"（只要这不限制必要的选择）。在开发工具时，您可以设置合理的默认值，这样人们就不必对工具允许的每个可能选项做出决策。这个原则可以应用的领域非常多。
开发者体验的挑战
开发者体验的大多数困难方面是人为方面，而不是技术方面。其中一些有技术成分，但大部分困难更多是人类如何做出决策、适应变化等。主要困难是：
理解问题：现在改进开发者体验最重要的事情是什么？我们如何充分理解这些问题，以便构建正确的解决方案？
管理变更：如何推出新变更？如何让人们采用新系统或行为？如何处理对变更感到不安的人？
提供杠杆作用：您为开发者构建的工具和系统不应需要太多工作来使用/采用它们，以至于它们实际创造的工作比节省的工作更多。
说不：您不能一次解决世界上所有问题。您必须能够确定优先级。另外，有时您会收到一个团队的要求，他们真的想要某个工具或功能，但这实际上会损害公司的开发者体验。
将痛苦施加给造成痛苦的人：如果一个团队做了给另一个团队带来困难（“痛苦”）的事情，而制造困难的团队自己从未因此经历任何困难，那么创造的痛苦只会不断增长。
让我们更详细地介绍这些。
理解问题
这里最重要的是要知道问题来自用户，解决方案来自系统开发者。您绝不能、绝不能颠倒这种关系，即您的用户告诉您构建什么解决方案，您就构建它，而开发者则坐在那里想象没有人实际告诉您他们有的问题。如果您从事开发者体验工作，开发者是"用户"，而您是"开发者"。
这可能非常棘手，因为有时您的用户包括高级执行官或技术负责人，他们对您应该构建什么有强烈的意见。您仍然需要坚持立场，只是从他们那里获取问题，而您基于从所有不同用户那里收集的良好数据设计解决方案。奇怪的是（我见过这种情况发生太多次）如果您构建用户告诉您构建的确切解决方案，而不是进行良好的研究然后设计最佳解决方案，您的用户不会喜欢它。他们可能一开始喜欢，但随着时间的推移他们会讨厌它，或者为您"设计"它的高管离开，新来的不喜欢它。
也很容易想，“嘿，我是开发者，所以我知道开发者想要什么”，并完全跳过与用户交谈。这行不通，因为所有开发者的工作方式都非常不同，并且通常有与您非常不同的需求。例如，如果您从未与机器学习工程师交谈过，您会震惊地发现这种体验与成为前端Web开发人员有多么不同。
如果您想了解如何从开发者那里收集数据和反馈，我在LinkedIn开发者生产力和幸福感框架上做了大量工作，它提供了一些如何做到这一点的指南。但是，如果您在一家小公司工作，您也可以直接与人交谈。这很容易。
反馈和投诉
在构建了某些东西之后，寻找有关系统的数据和反馈非常重要。尽管我们热爱我们构建的东西，但我们应该始终寻找开发者遇到的问题，以便我们能够解决它们 - 包括我们刚刚制作的东西的问题！随着时间的推移，这最终会为公司创造最佳的开发者体验。
这里要理解的一点是，在开发者体验领域，人们很少会向您发送正面反馈。当开发者工具"正常工作"时，开发者大多不会考虑它们。他们专注于他们正在做的任务，而不是您的工具，这应该是这样的。然而，如果某个工具或系统使他们难以完成工作，即使只是一点点，他们也会非常清楚这一点。
此外，并非每个开发者都是很好的反馈提供者。通常，他们只是与某个工具有了非常令人沮丧的体验，他们会向您提供一些非常情绪化的反馈，不会太考虑您的感受。当然，人们不应该这样做，如果您要写反馈，我鼓励您意识到您发送给的人是一个有良好意图的聪明人，所以请尊重他们。但有时会发生，您不应将其视为对您的个人攻击。
当您收到非常严厉的反馈时，处理的关键是：让用户知道他们被听到了。如果您的工具确实存在缺陷，同意用户的意见！您不必侮辱自己或自己的工作，只需对您拥有的东西的状态诚实。当您愿意说"是的，我同意这不是一个好的体验"时，用户实际上更尊重您。这并不意味着您必须立即修复它 - 您的团队设定自己的优先级。只需让人们知道他们被听到了，他们的投诉是有效的，很多噪音就会平息。
有时在您听到并承认痛苦之后，人们仍然继续刻薄，在这种情况下，您实际上应该告诉他们这种行为不可接受，如果他们继续这样做，就与他们的经理交谈。不过，只有少数人会这样行为。永远不要将此作为您对反馈的第一次回应。
管理变更
在美国长大时，我在历史课上学到了改变历史的伟大革命：1776年的美国革命、法国革命、苏联革命等等。这些故事听起来像是领导人引发了暴力革命，然后世界几乎一夜之间改变了。然而，当您研究许多这些情况下实际发生的事情时，“暴力的一夜革命"实际上只是重新建立了一个与以前非常相似（或更糟）的政府，而真正、积极的变化是通过随着时间的推移较慢的演变发生的。
我喜欢使用的类比是在海上转动一艘船。您只能以某个速率转动一艘非常大的船，否则它实际上会断裂成两半。船越大，这个转动速率越慢。公司或团队很像这样。它越大，安全地从一个方向"转向"另一个方向的速度就越慢。现在，明确地说，我并不是说变更必须永远进行。但它们也不会随着魔杖一挥一夜之间发生。
关于如何安全成功地推出变更，有很多需要了解的知识。
变更厌恶
在改进开发者体验时，您必须处理的主要因素之一是我们称之为"变更厌恶”。您对系统所做的任何变更在推出时都会收到某人的负面反馈。发生这种情况不是因为变更实际上有问题，而是因为用户习惯了它以前的工作方式，他们不喜欢它改变了。他们可能会批评新的用户界面，或者对为什么新东西"糟糕"有一些情绪化的论点，但通常他们真的只是对任何变更发生感到不安。这不是什么不寻常的事情；这是几乎所有人中都存在的因素。人们往往对在一段时间内愿意经历多少变更有一定的胃口，如果您超出了这个范围，他们会感到不安。
重要的是要认识到人们的反馈是简单的变更厌恶还是关于有价值事物的真实反馈。有几种方法可以判断：
变更厌恶通常持续3到10天。如果您在推出变更后的前3到10天内从用户那里收到反馈，并且没有大量用户提供相同的反馈，值得考虑用户的响应是否只是变更厌恶。
变更厌恶反馈通常是情绪化的。可能是侮辱性的。可能表达为只是意见（“新菜单的颜色很丑”）而不是事实（“我运行了新的命令行工具，它比旧命令行工具慢10倍。"）。
在管理变更时，您要避免的是创造如此多的变更厌恶以至于引起反抗。反抗基本上看起来像是如此多的人变得愤怒，以至于他们去找您的管理层并停止您的工作。如有疑问，向更少的人推出更小的变更，扩展速度更慢。随着时间的推移，您将了解您可以推出多少变更，以及多快推出。永远不要进行"大爆炸"发布，让所有用户同时经历大规模变更。
现在，所有这些都说，永远不要将所有反馈归因于"变更厌恶”。通常人们确实有合法的反馈。如果许多人向您提供相同的事实反馈，您查看它，他们的反馈有道理，并且您认为修复它会改进产品，那很可能不是变更厌恶。另外，说"这只是变更厌恶"并不意味着您应该完全忽略反馈。您至少应该承认它，让人们知道他们被听到了。这确实意味着您不应该与那个人争论或试图与他们讲道理，因为他们正在情绪化反应，您试图用"逻辑"说服他们摆脱它不会帮助任何人。如果您认为是变更厌恶，您承认他们，而他们只是继续与您斗争，有时您应该忽略他们并继续做您的工作。如果他们3天后带着更有理的论点回来，那么您知道这不只是变更厌恶，而且到那时他们可能也更有帮助。
增量推出
除了增量开发和设计之外，还必须知道如何增量推出变更，以便并非所有用户同时经历所有变更。这基本上有三个组成部分：
管理发布，使其尽可能具有最小破坏性。这意味着小变更，尽力不要求您的用户做工作来采用变更。
选择一个好的初始用户群组推出，该群组足够大以获得有用的反馈，但不要太大。
了解何时扩展群组以及扩展速度。
最小破坏意味着诸如：不要破坏用户的系统。不要求您的用户做手动工作来采用变更。必要时提供清晰的文档。确保系统提供非常清晰的错误消息，以便开发者在首次尝试失败时知道该做什么。基本上，设身处地为用户着想，思考"我有很多事情要做，我每天使用30个工具来做。当有新功能或新工具供我使用时，我希望有什么体验？"
您如何选择初始群组主要取决于谁会提供有用的反馈，以及您需要组中有多少人才能获得该反馈。在开发期间，通常您和您的团队就足够了。然后可能是您的技术负责人、组织中的一些资深人士，然后是您领域之外真正想采用该工具的另一个团队。您希望您的初始用户真正参与，而不是被迫使用系统，因为这将为您带来最活跃的使用和最好的反馈。然后您可以扩展到更多团队，然后公司的某个百分比，然后是整个公司。
您可以扩展的速度取决于几件事：您获得多少反馈。如果您从当前人群获得足够的反馈，并且您有很多工作要修复该反馈，那么不要扩展群组。毕竟，从更多人那里获得相同的反馈您将获得什么价值？另外，推出一个您已经知道需要重大工作的产品会损害您的可信度。
您必须为每个新团队做多少手动支持或手动入职工作。在广泛推出之前，这需要减少。否则您的团队将被手动工作压垮，无法在工具上取得进展。自动化的时间（或修复导致巨大支持负载的问题）是当您只有少量用户并且知道即将向大量用户推出时。
变更的破坏性有多大，或它引起多少变更厌恶。显然，破坏性越大，您必须推出的速度越慢。您必须考虑您给公司其他部分增加了多少工作，以及这如何影响公司其他部分实现自己目标的能力。
推动采用
假设您做得很好，进行了增量推出，但就是无法让人们使用您的新东西。您如何解决这个问题？
首先，您必须确保您真正理解了问题，并且问题是开发者知道并真正希望解决的。然后您必须确保解决方案真正处理了那个问题，而不会给开发者带来很多新问题（如新系统难以使用、经常失败、做得不如旧系统好等）。您必须听取反馈并解决它。
然而，只有一个解决方案能让您在整个公司达到100%采用率：您达到100%采用的唯一方法是让您的工具使用步骤为零。
这是什么意思？基本上，这意味着不是给开发者一些新的、手动的事情做，而是将功能直接放入他们的工作流程中。不是让他们运行工具检查PR，而是让它在代码审查期间自动发生。不是让他们运行工具格式化代码，而是让IDE在工作流程的适当点自动格式化代码。基本上，您找到开发者已经自然做的事情，并改进该体验，而不是让开发者做新的事情。
如果使用需要一个步骤，也许您会达到80%的采用率。如果需要两个步骤，您能有30%的采用率就很幸运了。如果需要开发者阅读长文档并遵循一组复杂的说明，那么，现在您知道为什么无法让任何人使用您的东西了。
您绝不应该从让工具使用步骤为零开始。做好这一点需要大量工作，在工具生命周期的开始时不值得。在其生命周期的早期，工具更难采用是可以的。无论如何，您只将其提供给小的、热情的人群进行初始反馈。在将其直接集成到人们的日常生活中之前，您希望专注于让工具正确。但一旦您确实做好了，“零步骤"是将您推向100%采用的口头禅。
提供杠杆作用
从事工具工作或改进开发者体验的全部意义在于，您应该为团队/公司节省比您投入创建和维护工具的努力更多的努力。即使您的工具主要专注于提高工作质量而不是工作速度，这也是正确的 - 思考如果没有您的工具，获得相同质量的结果需要多少工作。（有时答案是"无限”，因为如果没有工具，不可能获得那么高质量的结果！）
现在，请记住，在软件中，减少维护工作比减少创建工作更重要。因此，您必须考虑不仅仅是工具的直接影响（和构建它的即时成本），还有随着时间的推移它将节省多少努力（以及随着时间的推移维护工具将花费多少成本）。不同的公司对此计算有不同的"时间范围" - 也就是说，如果我现在投入X小时，我在Z年内为公司节省Y小时的总努力。Z是"时间范围" - 公司愿意看节省的时间有多远。在Google，我们通常将该时间范围设为两年，因此对开发者生产力的任何投资必须在两年内"回本"。
因此，每当您查看对开发者生产力、质量等的投资时，您必须考虑开发和维护解决方案需要多少工作，与它将实际为公司提供多少价值相比。
人类时间
在这个领域最常见的错误之一是通过某种优化节省机器时间（CPU使用、内存使用和磁盘空间的随时间成本），而忘记了你节省了多少人类时间。在大多数情况下，一小时人类时间的成本比所涉及的所有机器时间一小时的成本贵数百倍。在Google，我写过的最受欢迎的文档之一本质上是对这个原则的证明，表明您必须节省数万小时的机器时间才能值得您自己工作的几个小时。优化机器时间有很多合法理由，但改进开发者体验很少是其中之一。
当您考虑开发者生产力改进的成本和价值时，首先考虑您将节省多少人类时间。
为您的开发者服务
如果您从事开发者生产力工作，您的口头禅之一应该是"我们为我们的开发者服务，我们的开发者不为我们服务"。太容易发布某个工具，让开发者做的工作比它节省的更多，或者只是比他们应该做的工作更多。该工具可能让他们填写可以自动化的信息表格。它可能暴露许多复杂的实现细节，开发者必须学习，而不是允许开发者只表达他们的意图并让系统解决如何实现这一点。
如果您从事开发者体验工作，让工具以这种方式行为对您来说工作量更大。发布迫使开发者做所有工作的东西要容易得多。但这违背了我们正在做的事情的全部目的 - 提供杠杆作用。
说不
从事开发者体验工作的团队往往与客户有非常密切的关系。他们可能与您坐在同一个房间或同一栋楼里。如上所述，他们可能包括公司中拥有很多权力的高级领导。另外，您的客户是开发者，他们往往对自己想要什么有非常强烈的意见，有众多复杂的需求，并且面临时间压力要为