Hacker News new | ask | show | jobs
by Aurornis 588 days ago
println debugging is where everyone starts. Some people never graduate to knowing how to use a debugger.

Debugging through log data still has a place, of course. However, trying to do all of your debugging through println is so much harder, even though it feels easier than learning to use a debugger.

3 comments

I am comfortable using a debugger, but println debugging is easy, fast, and disproportionately effective for most of my debugging in practice.

I reach for a “real” debugger when necessary, but that’s less than 5% of the time.

I wonder, do you use a separate debugger, or a debugger that's integrated into your IDE? "Reaching for a debugger" is just pressing F5 in an IDE.

E.g. I keep wondering whether the split between people who can't live without debuggers vs people who rarely use debuggers is actually people who use IDEs versus people who don't.

Data point: I develop in Java and I use IntelliJ. I run everything in debug mode. So it’s really easy for me to enter the debugger.

But I find that if I have to step around more than a handful of times to find the issue then I forget what happened five steps ago. So I teach for print debugging quite often.

I use VS Code, and there's an extension that provides a debugger for the languages I use.
To be fair, if your code is multithreaded and sensitive to pauses, it becomes harder to debug with a debugger.

Ultimately, if you have a good logging setup and kinda know where the issue is a quick log message could be faster than debugging if all you want to do is look a variable value.

That is where OS tracing like DTrace and ETW come into play, which can then be loaded into a debugging session.
Logging can change timing issues though. There are too many cases where an added log statement "fixed" a race condition, simply by altering the timing/adding some form of synchronization inherent in the logging library.
That’s true but boy howdy does pausing the program at a breakpoint change timing!
printed/println debugging works if you wrote the code or have a good idea of where to go.

I frequently find myself debugging large unfamiliar code bases, and typically it’s much easier to stick a breakpoint in and start following where it goes rather than blindly start instrumenting with print statements and hoping that you picked the right code path.