[DannyBee]

"So not only are you able to reproduce the error, but you're also able to go backwards to find how it happened!"

For some (and i'd guess a bunch of the people i mentioned in the parent comment), they definitely find this easier, but just to present a contrarian position: i actually don't. I admit to being weird - in a former life, i was a gdb maintainer.

I also was trained by people who believed the right approach was not to immediately try to find the sets of conditions and variables that caused your problem and declare victory, but to go and meditate upon the code and think about it until you understood it well enough to understand why this might happen even when you think it couldn't. That will often enable you to understand the code well enough to see what else is wrong.

(Again, i don't claim it's better, i just claim that's why i tend not to care about RR. The hard part for me is the thinking about the code, not the finding the sets of conditions and variables that caused a particular set of errors)

It's definitely the case that, personally, when i follow the "find conditions, fix bugs" approach, i tend to write much buggier code (even with good testing strategies) than when i follow the other way.

[roca]

This reminds me of Linus Torvalds' distaste for debuggers.

I think eschewing debugging is fine for code you understand pretty well and when you already have significant information about the failure. But when those conditions aren't met, debuggers are very useful. (NB, if you use logging code and think "I'm not using a debugger!", you're just using a bad one.)

It's true that a good debugger tempts one to think less deeply about the code than one should, but that temptation can be overcome.