The truth: Print statements work so well that they dramatically decrease the need for a debugger. Then when I actually do need a debugger, I have used it so infrequently that I forgot the commands, so I just use more Print statements.
There is absolutely no point single stepping through code, setting up breakpoints, inspecting variables etc, when you could instead just insert an extra log statement to see what is going wrong.
If your logging is good, often solving a bug is just a case of looking in a production log and seeing where things went wrong.
The other fact is that the majority of bugs I've seen in my own code have been caused when under load, and it's not feasible to run a debugger on a production system.
I've tried debuggers a fair amount, and they end up being completely useless to me.
I assume that statement refers to the amount of noise in question?
Sure, print statements are my normal tool, but often I'm working on transforming one data structure into another (compiler-style) and I'm encountering an error "somewhere" down in the middle. After the first few megabytes of logging output get generated, you start to really lose the thread of what's going on.
It depends on what you're doing. If you're a CRUD programmer, yeah, I can see how they'd be useless; that's a good deal of my job too and I don't use them then. But when I'm actually doing something interesting and twisty I often need them, if only to set some conditional breakpoints somewhere so I can get into the middle of a complicated process instead of trying to reconstruct the state later.
Also they are great for learning libraries by stepping through them.
A debugger is just a tool and to dismiss a tool as being pointless for all people is ridiculous. Being familiar with all the tools at your disposal as a software developer is never a bad thing.
Debugging helps you work with code you don't understand. So, the longer you work with the same code the less useful it becomes. However, plenty of coders move from project to project patch up a few problems and then move on.
I'd say not having a debugger is more like programming on paper. When you have a problem, you might end up thinking about it a little more because you can't rely on that one other tool.
I think it's more like never being taught how to use a knife, and thus eating the steak with your bare-hands, as you've always done. Hands work fine, why learn something new? I have no formal training in programming and it never really occurred to me to use a debugger. I still don't entirely understand what they do for you that you can't do by adding print/trace statements. That said I mostly use scripting languages and don't need to read too much code written by other people...
They allow you to evaluate state and often see things you'd miss otherwise.
Plus they can do what prints can do, but even easier. I can use tracepoints to print anything at any point in code, including the callstack. The nice thing though is I can turn the tracepoints on and off while never pausing/breaking the code.
Additionally I can attach a debugger to a running process.
Plus with more modern features, like historical debugging), I can go back to predefined instances of time (like a past exception that was thrown) and examine the callstack then.
And the other thing you can do interactively is (a) change the value of variables, (b) change the code, and (c) change the instruction pointer. I regularly do (a) & (c) -- (b) less so. It's a huge time saver when you step over function foo() and realize, hey it didn't set ABC. So then just set the IP back to foo(), but this time step into it.
When I would consult I would often find and fix bugs in a day or two with oode that I'd only seen for the first time, while others had been looking for weeks in code they had helped build. I'd look at their debugging techniques and it was obivous that they were often just not at all efficient.
That sounds better than what I tell others, that I'm not smart enough to use a debugger.
Debuggers let me get away with code that is on the edge of my understanding at the time that I'm writing it. The problem is that I'm not nearly as smart when I have to revisit that same code later.
In addition, debugging with print requires more understanding, so it's more likely to be correct than debugging with a debugger.
That said, I really liked my time in visual studio.
I don't believe this is true. I suspect the way most people use print statements for debugging goes something like: "I think the problem is somewhere in this function, let's stick a print statement here. Oops, that doesn't seem to be it, let's try one here. Oops, that's not it either, let's try printing out a different variable." and so on.
That's remarkably similar to using a debugger only a lot less efficient, because you have to go back through the whole edit-compile-run cycle each time (or maybe edit-deploy-run if you're working on a web app using a scripting language).
What is the basis for your suspicion? I ask because the folks who I see using print as their first-choice for debugging don't work that way. The overhead associated with changes (as opposed to restarting) gives them the opportunity to think (or grab a new cup of tea).
That said, that "poke around randomly" approach does seem to be "not rare" for folks who are "debugger first", as you yourself say.
To be fair, the folks I know who are most effective with a debugger also put in some time on understanding before they fire it up.
Debugger is more powerful, it can do everything print can, and more. Sure if it's a 5 minute walk to the market, then by all means, walk.