嗯，是的，我知道这是一个轶事问题 - 如果你想结束，那就去做吧。
但我现在正打猎18个月。每次当我认为我有一个可复制的用例时，我会有人告诉我我们还有其他事情要做。
最长的“会话”时间似乎是昨天2个完整的工作日，以追踪多线程竞争条件，该条件仅在安装程序后第一次出现 - 幸运的是这次它是可重现的。所以我不得不在构建之后创建构建，重置VMWare映像大约23434次。
我之所以这么做的原因是我在接下来的45天没有里程碑，所以我抽出时间。
但是我想知道其他人或开发团队是否为一个bug开了一个虫子狩猎季节。我记得我过去曾经工作过的一家公司，他们在Java中有一个非常讨厌的内存漏洞，并为修理它的人提供了一个月工资 - 但从未允许正常的工作时间来追踪它。我认为这个错误今天仍然存在 - 我离开公司8年后。
答案 0 :(得分：4)
我在SPI驱动程序中遇到了一个错误，最终需要花费两个月才能找到。我会解决我认为的问题，只是弹出另一个问题。
实际的错误是当DSP以更高的频率发送数据包时，数据包有时会在SPI通道内被破坏，所以cpu得到的是坏数据。
这很难排除故障，因为我最终必须在示波器上证明它实际上是硬件问题。我们必须捕获一个包含已损坏数据的数据包并显示它不是软件。
答案 1 :(得分：3)
如果我在几个小时内找不到错误，请转到我的白板并尝试在那里找到错误。复杂错误通常是设计缺陷的结果。
答案 2 :(得分：2)
错误：特征性。
描述：为程序添加更多功能的冲动，通常是因为“我一直在编写更多代码，所以我的软件应该做更多的东西！”这个想法推动了这一点。
时间直到固定：大约半小时。只要我添加此选项...
答案 3 :(得分：0)
我处理了一个神秘的间歇性错误，持续了大约3年，直到另一位开发人员发现了问题并修复了它（见this answer）。在我的辩护中，问题的最终根源是微软的SqlCE复制代码中的一个错误，在我反复强行驳回之后，这可能是问题的根源。
答案 4 :(得分：0)
对于许多问题，这取决于你是否计算我实际修复它的时间，或者其他人已经花费的时间，当他们认为他们“修复”它时。
答案 5 :(得分：0)
我有一个不熟练的十年。
事情是我不确定它是否存在。它始终只是根据某人的记忆在后见之明中看到的。几个星期前我以为我有一个可重复的案例 - 但是当我收到相关文件时，我无法重现它，我发现其中一个已经腐败了。
我还杀了一个关于从未报道的那个年龄的人，我遇到了其他事情。