4 ms·
1. That can't happen 2. That doesn't happen on my machine. 3. That shouldn't happen. 4. What does that happen? 5. Oh, I see. 6. How did that ever work? St
by forrestthewoods 11y ago
1. That can't happen
2. That doesn't happen on my machine.
3. That shouldn't happen.
4. What does that happen?
5. Oh, I see.
6. How did that ever work?
Stage six is the worst. Especially when I wrote the original code.
(http://plasmasturm.org/log/6debug/ http://plasmasturm.org/log/6debug/)
- hitekker 11y agoYep, that's a good one! My first time seeing it was on http://bash.org/?950581 http://bash.org/?950581 It comes with a nice follow up after the first 6 rules: < MatthewWilkes> 7. svn blame < miniwark> 8. one day we will write tests
- golergka 11y ago> < MatthewWilkes> 7. svn blame Am I the only one who runs git blame (for the commit, not the author) 20 minutes into investigating the bug and git bisect an hour in? They are excellent tools to find when and how did the bug first occur
- brad0 11y agoI do this as well. Unfortunately we're far and few between.
- klibertp 11y agoIn the "Beautiful Code" book, there is a "Beautiful Debugging" chapter. The author describes how things like `git bisect` work. I had some success convincing people to use bisect at work by pointing them to this chapter.
- babuskov 11y agoYes. And usually discovering answer to 6 leads to finding another bug that would bite you later. So you often spend 2x time finding the answer to 6 than you spent for steps 1-5.
- babuskov 11y agoYes. And usually discovering answer to 6 leads to finding another bug that would bite you later. So you often spend 2x time finding the answer to 6 than you spent for steps 1-5.
- mercurial 11y agoI find that software developers often try their best to stay at stage 1 by dismissing "weird" issues reported by users if they are inconvenient.
- TheOtherHobbes 11y ago"Can't reproduce" = "Works fine on my machine. No problem!"