And in situations where it's applicable, I'm perfectly happy to use a debugger.
Unfortunately it doesn't work so well for things like intermittent wrong behavior in long-running programs. Better in that case to use pervasive logging (aka, printf debugging to a file).
Not for multi-threaded or networked code where breaking in the debugger changes the program's behaviour and causes timeouts. I still prefer printf in these cases.
As a Ruby and C developer, I wish there were more tools like Java's jvisualvm for realtime visualization of running systems without the overhead and forced synchronization of a debugger.
The next best thing IMO is detecting crashes and printing a stack trace, which reminds me I've been meaning to release some code I wrote that does so for C/glibc programs.
I completely agree about jvisualvm, I'm still blown away by the quality of the Java ecosystem. I've done a lot of server-side work on the JVM and it really blows away every single piece of tooling for C/C++.
While I'm no fan of the Java language, you get all these benefits for other JVM-hosted languages such as Clojure and Scala and that is fantastic. You basically get the entire ecosystem for free.
My favourite bug is where adding a printf makes the bug go away. Lots of fun tracking these down in multithreaded code where the bug only shows up after running for a 100 hours.
I have to say I have never had the pleasure of working at such low level, but I doubt I would enjoy it.
Another nice experience I have had is tracking down bugs that only show up in protected/encrypted code (anti-cracking) where you can’t use a debugger - fprintf becomes your best friend here.
I don't really enjoy debugging low-level code either, but I absolutely love developing it, reasoning about it and finding solution to problems at that level.
Knowing how to code low-level has radically changed how I code high-level as well because I now understand what the potential bottlenecks are on the hardware.
Come to think of it, I don't really enjoy debugging no matter what abstraction level I'm at! I prefer taking more time to think carefully about the problem and preventing bugs rather than spending that time chasing them. Which isn't always possible sadly.
The bugs that catch me out are those where a change was made somewhere else that invalidated the assumptions made by the function. These sort of bugs can’t be picked up by static analysis or valgrind, and if they are rare are really hard to trace.
I agree, but it's only available for Windows. We use it when debugging console games as the dev-kits and SDKs come with usually very tight VS integration.
However, network time-outs are still an issue when breaking in the debugger while running a multi-player session. We have a few quirks around this, but nothing perfect.
And we also develop on OS X and Linux where VS isn't available :)
Unfortunately it doesn't work so well for things like intermittent wrong behavior in long-running programs. Better in that case to use pervasive logging (aka, printf debugging to a file).