Have you ever used a good visual debugger? I find that command line debuggers require you to keep too much state in your head at once, and even if you have a great memory and this isn't a problem, they still require you to query the new state after each step.

Sadly, most of the visual debuggers on linux don't meet my minimum standards for "good" (crashy, slow, typically have trouble inspecting certain types (mysteriously, since they're GDB frontends and GDB has no issue with it), etc...), and successive update to MSVC makes it's debugger worse and worse (although it's still the best I'm aware of at the moment)...

I've always find having to type commands in very distracting - makes it harder for me to think through things. When there's some kind of command grammar, and few prompts, and you have to remember to press Return, it's like trying to count while somebody shouts random numbers in my ear. Hovering the mouse and pressing individual keys is about all I can manage :)

Moving on from my own personal intellectual deficiencies, one nice thing about Visual Studio (that everybody should copy, in my view) is that running your program under the debugger is the default. So any time you see anything unusual happen, or there's a crash, you can start debugging straight away.

This is also good when combined with automated tests. Get your tests to stop the debugger at the point of failure (for VC++, something like "if(IsDebuggerPresent()){__debugbreak();}" in your test macro(s) will do the trick) just before they abort or throw or whatever. Then when you have a failing test, you have all the information you'd have normally - and the option of some post-mortem examination. Sometimes, you won't need it, but sometimes, you will. The latter situations are always a bit more stressful and I think it makes sense to optimise for that.

So agree here. I have only used GDB command line for c++, pdb for python and the Chrome Dev Tools js debugger. GDB was a nightmare when I was in college, new to programming in general, not a clue what I was doing...

Then I got into js development, the Chrome one was night and day different. I could actually see what was happening, it displays where it is stopping every time. You can see that picture you need to paint in your head on the screen without trying to remember which letter to press, which bits of code you have to store in RAM in your brain. I have many complaints about it still, but it works pretty well for most of the things I need it for.

Then I was shown pdb, which is very much like GDB from what I remember of it. Now armed with my knowledge of how debuggers work from Chrome, I am much more confident in pdb, but it's still a pain in the ass compared to something more "visual".

I used visual debuggers in college, Eclipse and Java. But then I found Ruby, and switched almost entirely from debugging to unit tests. Yes, they're not entirely the same thing, but I had found that using a debugger meant I didn't write tests. Once I found and fixed the problem, done.

Once I started writing tons of tests, I found I didn't need the debugger as often. When your methods are less than ten lines, they're much easier to reason about, and a method becomes a pretty decent 'unit' to check out, no need to step through.

However, this also probably has to do with my relative skill levels and the languages and tools involved too. Ruby debugging has gotten better, but only in the last couple of years. And I didn't really know how to write tests nearly as well when I was doing Java.

I work in an area where unit testing is, generally speaking, more effort than its worth (game programming -- the state space is generally too huge for unit tests to be really practical). So I can't really comment on the effectiveness of them, other than to say that yes, they are different.

Typically, instead of unit tests, I write state tracking and visualization code. This goes a long way towards helping track down bugs and keeping me out of the debugger, but honestly, a lot of that is just an indication of debugging tools being crap in general.

QTCreator on linux is good.

Qt Creator / KDevelop and so on are basically frontends to gdb though, and suffer the same limitations on reverse debugging. (Perhaps supports lldb as well, never tried)