Not if I can help it. I mostly do medium-scale (5-50 people) C++ development. There are two main mode of debugging that I fall into: 1) I just wrote some code

Not if I can help it. I mostly do medium-scale (5-50 people) C++ development. There are two main mode of debugging that I fall into: 1) I just wrote some code. Does it actually do what I planned? Let's see where it goes in practice. 2) Some code I've never seen before just screwed up. What the hell is just happened? OMG What the hell is all this stuff? It helps that games are largely "while(1) doMainLoop();" kinds of apps as opposed to event-driven, asynchronous, multi-process, distributed, interpreted, whatever apps. It also helps that, as much as I can, I work in Visual Studio. The debugger works easily, reliably, continuously. It's faster for me to casually browse through deeply nested data structures than it is to type "print foo.x, print foo.x.bar". Data breakpoints are god-sent. "Break, change a variable and continue" is really nice for tweaking and quick-and-dirty testing. "Break and move the instruction pointer" is great for re-running a rare screw-up or skipping over code that would kill the process you are deep in the middle of debugging. It seems to me that most of the people who rail against debuggers fall into A) working on systems that are not amenable to debuggers, B) stuck with very poor debuggers or none at all, or C) don't need debuggers because they either working alone on very small code bases or have dedicated many years of their life to absolutely understanding a every line of a single, slowly changing code base.