4 ms·

Yes. 40 years of debugging with print statement (or MsgBox in MFC during that one Windows project in the 90s...). When I'm mentoring juniors, I always see the

Yes. 40 years of debugging with print statement (or MsgBox in MFC during that one Windows project in the 90s...). When I'm mentoring juniors, I always see them stepping through the code with a debugger. They're not really understanding the code, they're just looking for the line that crashed ("Oh, there's an NPE here"). And they do a local fix ("We'll just do an if(foo==null) check"). That doesn't usually fix the root cause (Why was foo null? Should it ever have been allowed to be null? Should we catch that earlier in one place?), and they never internalize or understand the codebase. Printf debugging requires you to reason about the code. And yes, I look like a n00b when I debug something I've never seen before and it takes me longer to find the first bug. But during that whole process I'm learning how the code is really organized and how things go together. I always advocate for the printf style of debugging.

harshalizee 3y ago
You can do all of that with a debugger too, likely much faster. Print statements are handy when dealing with an ecosystem with bad debug tooling, disparate systems calling different microservices, etc. Learning the debugger intimately within your stack is a hugely productive endeavor. Breakpoints are just debugging 101. Learning how to effectively break on conditions, expressions, breaking on multiple threads are vital to programming. Certain kinds of race conditions are nearly impossible to reproduce deterministically with only print/sleep statements. As an aside, I also encourage a first pass investigation purely with logging/telemetry to determine the issue. This will immediately reveal if your logging is insufficient or not. You can then get down to fixing the bug AND your telemetry so you can catch it without grokking through your code.
plorkyeran 3y ago
Juniors are failing to dig into problems to discover the root cause because they're juniors and that's something that many people have to be taught to do, not because they're using a debugger. Debuggers are an enormously powerful tool for understanding a codebase and thinking of them as a way to skip over that is a severe misunderstanding of why they're useful.
borlanco 3y ago
I always debug with printf for the clear benefits you mention, and I happen to know another one. Because I am commited to the Way of Printf, I have seen myself anticipating where printfs might be needed, and limiting the complexity of each segment of code to support printfs that aren't there yet. In my experience, commitment to printf debugging incentivizes coding for simplicity and observability.
yread 3y ago
Imagine if other engineers had this attitude towards tools: "I don't use a ruler when making a drawing. You have to reach a peace of mind to make a straight line and the junior nowadays just use a ruler instead. " I say that as someone who programs on paper and uses print debugging a lot.
TheLoafOfBread 3y ago
I have no idea why anyone would voluntarily hammer a nail using a forehead instead of grabbing a hammer - tool made for the purpose. Imagine that you are in a method X, which is called from 100 other methods. Method X crashes, but you don't know what method the wrong data causing a crash come from. In your scenario you will be putting 100 different printf. While somebody in debugger will just have a look on stack and will see it.
shrimp_emoji 3y ago
Yep. The debugger is a bloated, boondoggling waste of time except in very special circumstances. It's like a high-tier electronic warfare ship in EVE, when you just need to shoot some rocks 99% of the time.
Jcowell 3y ago
This seems such a weird logic to me. if you removed the debugger, they’re just going to put print statements wherever until they bartow it down. Hell if they’re doing that and not putting the breakpoint at exactly where the exception occurs based off the stack trace them already something is odd. How do you folks debug a third party library without jumping into the debugger? In order to test certain conditions at a breakpoint are you printing and refining the code every time ?
chrismcb 3y ago
Printf doesn't really require you to reason about the code anymore than stepping through the code does. Usually you already know where it crashes. You can randomly put a printf somewhere but the value may have changed somewhere else. If you are paying attention stepping through the code let's you see when the value changes. As opposed to adding a print, running, adding another print, running, etc. I would also argue stepping through code let's you understand the code better than a simple print. As you can see things happening in realtime. Both methods have their usefulness, both are just tools you should have in your toolbox.

harshalizee 3y ago

You can do all of that with a debugger too, likely much faster. Print statements are handy when dealing with an ecosystem with bad debug tooling, disparate systems calling different microservices, etc. Learning the debugger intimately within your stack is a hugely productive endeavor. Breakpoints are just debugging 101. Learning how to effectively break on conditions, expressions, breaking on multiple threads are vital to programming. Certain kinds of race conditions are nearly impossible to reproduce deterministically with only print/sleep statements. As an aside, I also encourage a first pass investigation purely with logging/telemetry to determine the issue. This will immediately reveal if your logging is insufficient or not. You can then get down to fixing the bug AND your telemetry so you can catch it without grokking through your code.

plorkyeran 3y ago

Juniors are failing to dig into problems to discover the root cause because they're juniors and that's something that many people have to be taught to do, not because they're using a debugger. Debuggers are an enormously powerful tool for understanding a codebase and thinking of them as a way to skip over that is a severe misunderstanding of why they're useful.

borlanco 3y ago

I always debug with printf for the clear benefits you mention, and I happen to know another one. Because I am commited to the Way of Printf, I have seen myself anticipating where printfs might be needed, and limiting the complexity of each segment of code to support printfs that aren't there yet. In my experience, commitment to printf debugging incentivizes coding for simplicity and observability.

yread 3y ago

Imagine if other engineers had this attitude towards tools: "I don't use a ruler when making a drawing. You have to reach a peace of mind to make a straight line and the junior nowadays just use a ruler instead. " I say that as someone who programs on paper and uses print debugging a lot.

TheLoafOfBread 3y ago

I have no idea why anyone would voluntarily hammer a nail using a forehead instead of grabbing a hammer - tool made for the purpose. Imagine that you are in a method X, which is called from 100 other methods. Method X crashes, but you don't know what method the wrong data causing a crash come from. In your scenario you will be putting 100 different printf. While somebody in debugger will just have a look on stack and will see it.

shrimp_emoji 3y ago

Yep. The debugger is a bloated, boondoggling waste of time except in very special circumstances. It's like a high-tier electronic warfare ship in EVE, when you just need to shoot some rocks 99% of the time.

Jcowell 3y ago

This seems such a weird logic to me. if you removed the debugger, they’re just going to put print statements wherever until they bartow it down. Hell if they’re doing that and not putting the breakpoint at exactly where the exception occurs based off the stack trace them already something is odd. How do you folks debug a third party library without jumping into the debugger? In order to test certain conditions at a breakpoint are you printing and refining the code every time ?

chrismcb 3y ago

Printf doesn't really require you to reason about the code anymore than stepping through the code does. Usually you already know where it crashes. You can randomly put a printf somewhere but the value may have changed somewhere else. If you are paying attention stepping through the code let's you see when the value changes. As opposed to adding a print, running, adding another print, running, etc. I would also argue stepping through code let's you understand the code better than a simple print. As you can see things happening in realtime. Both methods have their usefulness, both are just tools you should have in your toolbox.