The trap that I’ve seen people get into is thinking they can just blindly step through code and they’ll eventually work out the problem. I think that’s the usag

The trap that I’ve seen people get into is thinking they can just blindly step through code and they’ll eventually work out the problem. I think that’s the usage of debuggers that you’re describing. And it’s a bit of a trap, maybe you start out with a targeted breakpoint but then wind up stepping through stuff without any real idea what you’re doing, mostly treading water. Effective use of printf and breakpoints is, IMO, as a tool in logically thinking through the problem. You work out some belief of the problem, you see how this belief being wrong could cause the bug but you can’t see how the belief could be wrong, so you use debugging tools to check your assumption. This is imo the easiest and quickest way to find something surprising. And once the assumption is either validated or invalidated, it’s time to go back to thinking through the problem logically. Personally I prefer printf to breakpoints most of the time, because they leave a trail that I can keep going back to when thinking through the problem logically, and because they build up as I work through a problem. I think printf debugging suffers the “trap” issue less for this reason, but sometimes it’s nice to do a little exploratory debugging once the assumption is invalidated.