良好的 DevEx 会提高生产力。以下是数据
来自 GitHub 和 DX 的研究表明，更好的开发者体验——更少的干扰、更清晰的工具和流程，以及更多深度工作时间——与显著的自我报告生产力提升相关，许多工程师表示这与他们的日常现实相符。评论者欢迎有这样一份可用于为工具、自动化和开发者基础设施投资辩护的数据，但也批评该研究依赖主观调查、存在赞助背景，并且缺乏公认的客观生产力指标。讨论的大部分内容集中在改进 DevEx 的实际杠杆上——减少会议、加快构建和测试、简化 CI/CD、将内部平台视为一等产品——同时指出组织政治往往和技术同样重要。
对研究及其目的的看法
- 许多人认为这篇文章和研究是在为 GitHub 和 Copilot 做营销，不过也有人指出，它对希望为 DevEx 争取预算的管理者来说，仍然是一个有用的“CYA”数据点。
- 一些评论者认为，任何需要这项研究来决定是否投资工具的经理，可能本来就不会改变行为。
- 也有人对研究偏差提出担忧（企业赞助、样本有限），以及受访人群过于狭窄（已经在为 DevEx 调研付费的公司）。
深度工作、会议与文化
- 大家普遍强烈认同，无会议时间和深度工作能显著提升产出。
- 有人主张设置一个“会议日”，而不是一个“无会议日”，并对每周会议数量设定硬性上限。
- 也有人指出，某些会议确实有价值，但不被打扰的专注时段对 IC 来说是“火箭燃料”。
衡量生产力与感受
- 主要批评是：这项研究大多衡量的是自我报告的生产力感受，而不是客观结果。
- 关于是否可能存在客观的开发者生产力指标，也展开了争论。
- 有人建议的替代指标包括：DORA 指标、部署交付周期、构建/测试时长、入职时间，以及业务影响（收入与工程支出对比）。
- 也有人认为，自我报告的生产力可能是最弱的一类衡量方式之一。
DevEx 包含什么
- 对 DevEx 的定义主要围绕工具质量、减少摩擦、清晰的任务、合理的流程，以及短反馈循环。
- DevEx 被描述为与 DevOps 和内部开发平台相重叠，重点是自助式基础设施和顺畅的工作流。
- 也有多人强调，开发者满意度和留任才是 DevEx 的主要结果，即便生产力很难证明。
工具、CI 与现实中的痛点
- 具有影响力的 DevEx 工作例子包括：自动化工作站搭建、内部平台、用于一致开发环境的容器。
- 常见抱怨包括构建速度慢、测试套件耗时过长，以及 CI 系统（尤其是 GitHub Actions 和一些云 CI 产品）很难在本地快速迭代。
- 有人把问题归咎于糟糕的配置，而不是工具本身；也有人认为这些工具在根本上就有缺陷。
组织动态与阻力
- DevEx 工作常常被低估、阻挠，或被政治化；有些人会因为执着于现有系统而主动抵制改进。
- 像这样的研究被视为 DevEx 支持者的弹药，但也被认为有些“显而易见”（好的工具和更少的打扰会有帮助）。