这是我用来帮助高级工程师更好地响应意外要求的一项心理练习。
随着软件工程师的任职和经验积累，组织中的其他人自然会寻求他们的专业知识。 一些示例：一名初级工程师要求介绍一个不熟悉的组件。 财务团队需要知道如何在报告中处理极端情况。 客户支持人员希望突出显示一个错误，并询问修复该错误的难度。
工程师可能会变得压力重重，试图对同事提出的他们没有时间从事其他重要工作的要求做出快速而彻底的响应。 最好的帮助意愿可能会因响应最新请求时经常出现暂停而延迟重要工作。
可视化“参与频谱”产生的可能反应要比实际想到的第一件事要大。
首先，认识两个极端：“我至少能做的”通常是礼貌地拒绝（“对不起，我太忙了”）或重定向（“请某某人问”）。 “我所能做的”是暂停我当前的任务，直到我完全解决了这个问题。
这些极端情况很少是最有效的应对措施。 使用它们打开可能的响应范围。
接下来，考虑2-3种中等反应，范围从“少量参与”到“大量参与”。 在初级工程师学习新组件的示例中，“稍加参与”可能是向他们发送指向文档，一些相关代码文件或提取请求的链接。 “大量参与”可能是安排一对一的时间来讨论该体系结构，展示如何对其进行测试以及配对其功能。 您可以提供早期反馈和代码审查。
最后，结合这些响应的元素以合成新的响应。 如果该组件的文档记录正确，则可以说“查看这些文档以获取该组件的概述。 如果您有任何疑问，请告诉我。 另外，我很高兴查看一些正在进行的代码。”或者它缺少文档，“让我们讨论该组件并一起编写一些文档。”
对于来自客户支持的错误报告，“稍加参与”可能是向错误报告添加额外的上下文，以便可以更轻松地对其进行分类。 “大量投入”可能是您自己实施了部分修复程序，同时积压了完整的修复程序。 综合的混合响应可能是在错误报告中添加上下文，并询问利益相关者是否值得实施短期修复程序，或者等待对长期修复程序进行优先级排序。
整个智力锻炼需要30–60秒。 以我的经验，其中一个综合响应通常会跳出每个人的时间和注意力中最有生产力的使用方式，并且比我想到的第一件事有了重大改进。
