> you don't know that you'll work out your problem By this reasoning you must not believe in any debugging techniques (what does it mean to "believe" in a debu

> you don't know that you'll work out your problem By this reasoning you must not believe in any debugging techniques (what does it mean to "believe" in a debugging technique anyways?). You don't know that they'll lead you to a solution to your problem. The differential coverage technique posted yesterday? It doesn't work all of the time, or may give you too much to look at to be practical. The statistical variant I posted in that discussion also doesn't always work, it can lead you astray. TDD? Even Kent Beck says to not use it all the time. These things, and rubber duck debugging, do work. That they don't work all the time is immaterial. Are they effective for you and your team? You rotate through techniques while debugging and you select them based on experience. A first pass with that differential coverage technique or a git bisect may be enough. If they don't help right away you go to other techniques. Repeat. Probably even cycling back once you've isolated the issue better. https://research.swtch.com/diffcover https://research.swtch.com/diffcover https://news.ycombinator.com/item?id=43795090 https://news.ycombinator.com/item?id=43795090