While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…
Speaking from my own experience I'm not so sure that printf debuggers just have "incomplete knowledge [...] of modern debugging tools". I use printf (or the file-based equivalent, log files) quite a lot, but nobody can accuse me of not knowing good debugging environments. Also, what's "modern" about "Walk the call stack! See the parameters and values, add watches, set conditional breakpoints"? Those are all things we…
Don’t look down on print debugging
91–100 of 164 posts
Re: Don’t look down on print debugging
#92Re: Don’t look down on print debugging
#93To me there are three requirements for me to be comfortable with a team culture of print-debugging. 1. If a breakpoint debugger exists for the stack, it should still be convenient and configured, and the programmer should have some experience using it. It's a skill/capability that needs to be in reserve. 2. The project has automatic protections against leftover statements being inadvertently merged into a major branc…
Why would debugging be a team culture thing? It's very individual in practice.
Re: Don’t look down on print debugging
#94I've used both print and proper debuggers plenty. I tend to lean on print debugging more these days. The thing about debuggers, in addition to often being a headache to set up, it usually seems tricky and time-consuming to get it to step to the lines you actually want to examine and skip the stuff you don't. And if you step past something but then later realize it was important, time to start over. It's often faster…
How can you do this using print debugging? For every print statement I add, I can add a breakpoint. Even more importantly, I can see the stack frame and know which functions led to the current one. I can inspect any and all variables in scope, and even change their values if I want to pretend that the code before was fine and proceed further.
Re: Don’t look down on print debugging
#95While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…
Something is broken in prod, you cannot reproduce it in your test environment because you think it may be due to a config (some signing keys maybe) you can't check. And it looks like someone forgot to put logs around whatever is the problem.
You can either: spend multiple hours trying to reproduce and maybe find the cause. Or take 5mn, bash into one of your nodes, add some logging live and have a result right now: either you have your culprit or your hunch is false.
Re: Don’t look down on print debugging
#96Concise argument for print debugging: Print debugging is how you make software talk back to you. Having software do that is an obvious asset when trying to understand what it does. There are many debugging tools (debuggers, sanitisers, prints to name a few), all of them have their place and could be the most efficient route to fixing any particular bug.
Re: Don’t look down on print debugging
#97I agree with the title that you shouldn't look down on print debugging. You should look down on people who are slow at fixing bugs and who refuse to try tooling to be able to keep pace -- and using print statements can sometimes be a marker of this. But print debugging is just a tool and has its place, and the use of print debugging is not itself an indicator of poor developer performance. If you can find/fix bugs as…
I find the people quick at fixing bugs are even quicker at introducing new bugs.
Person was a wizard at finding bugs. And they didn’t write many. My goal in code reviews was to find them from this person. I found 2 in 5 years.
Re: Don’t look down on print debugging
#98While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…
It's particularly annoying on projects that are set up without considering proper debuggers, because often it's impossible or difficult to use them, e.g. if your program is started via a complicated bash script or makefile rather than directly.
Re: Don’t look down on print debugging
#99Earlier quoted context omitted.
Speaking from my own experience I'm not so sure that printf debuggers just have "incomplete knowledge [...] of modern debugging tools". I use printf (or the file-based equivalent, log files) quite a lot, but nobody can accuse me of not knowing good debugging environments. Also, what's "modern" about "Walk the call stack! See the parameters and values, add watches, set conditional breakpoints"? Those are all things we…
It got put in vs code so mediocre developers can finally use it. Like all things they cargo cult it because they don't know how to use it properly.
Re: Don’t look down on print debugging
#100While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…