Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: