这可能看起来是一个合理的问题，但它做出了一些可怕的假设：当查看所做的更改时，为什么一个看起来如此简单的修复需要两天时间才能完成？
因为报告该问题时含糊地描述了如何重新创建它。我花了几个小时才找到那件物品的可靠复制品。一些开发人员会立即回到报告问题的人那里，并在调查之前要求提供更多信息。我会尽我所能地利用所提供的信息。我知道有些开发人员不喜欢修复错误，所以他们会尽其所能来解决这个问题。声称没有足够的钱是一种很好的方式，让人看起来像你在试着帮忙，但什么都不用做。我知道报告错误可能很难，我很感谢任何这样做的人。在询问更多详细信息之前，我想通过尽可能多地利用所提供的信息来表达对错误报告的感激之情。
因为报告的问题与功能有关，所以我不太熟悉。因为它涉及的功能是我很少使用的功能，也不是我详细使用过的功能。这意味着我花了比想象中更长的时间来理解如何使用它，以及它如何与有bug的软件交互的细微差别。
因为我花时间调查了问题的真正原因，而不仅仅是看症状。如果某些代码抛出错误，您只需将其包装在try..catch语句中并隐藏该错误即可。没有错误，没有问题。对吗？对不起，对我来说，使问题隐形并不等同于修复它。吞咽错误很容易导致其他意想不到的副作用。我不想在将来的某个时候不得不和他们打交道。
因为我调查了是否有其他方法来解决同样的问题，而不仅仅是报道的复制步骤。一组再现步骤很容易使错误看起来像在一个地方，而实际上它可能更深层次。找出问题的确切原因，并找出解决问题的所有方法，可以提供有价值的见解。洞察力，比如代码实际是如何使用的，在哪里可能有其他可能的地方(其他？)。可能需要解决的问题，或者它可能显示代码中的不一致，这意味着在一个代码路径中导致(或处理)了错误，而不是在另一个代码路径中导致(或处理)了错误。
因为我花了时间来验证代码的其他部分是否可能以类似的方式受到影响。如果错误导致了错误，那么代码库中的其他地方也可能会出现相同的错误。现在是结账的好时机。
因为当我找到问题的原因时，我希望找到一种最简单的方法来修复它，同时将引入副作用的风险降至最低。我不想要最快的修理方法。我想要一个不太可能在将来引起混乱或其他问题的修复程序。
因为我彻底测试了更改，并验证它解决了所有受影响的不同代码路径的问题。我不想依赖别人来测试我所做的事情是否正确。我不想在未来发现错误，当我精神上继续前进时，我必须回到这个代码上来。(这句话的意思是：“我不想在将来发现一个错误，当我精神上继续前进的时候，我必须回到这个代码上来。)”上下文切换既昂贵又令人沮丧。让专门的测试人员再次检查相同的变化是我希望尽可能避免的事情。
我不喜欢修复错误。部分原因是他们会感觉像是我之前失败的结果。我不喜欢修复错误的另一个原因是我更喜欢做新东西。还有什么比不得不修复错误更糟糕的呢？必须反复修复相同的错误。我花时间确保在遇到任何错误时都能完全修复，这样它就不需要面对、调查、修复和测试不止一次。