I share your aversion to debuggers. Everyone is different, and plenty of people like them - but I've always thought that they consume brain cycles that otherwise could be engaging with the code. That's why I like print(); it keeps my head in the code.
When you're debugging code you didn't write, and you don't have time to read and understand that half a million lines because you need to ship in one week, and you have 2 hours to fix the bug, the debugger can come in handy.
Personally, I'm fond of configurable logging, but I'm not under any illusions; logs are like freeze-dried debug sessions with less features. Logs verbose enough to contain the relevant information can also get borderline unwieldy and time-consuming to generate and process. The compiler I work with, when hosted in the IDE, could easily produce over 100GB of log output on a complex project test case, so I usually try and keep it down to 1..2GB or so, but that often leaves out the incriminating evidence, so it takes some back and forth... And the reason I'm using log files at all is often because debugging itself gets unwieldy on large test cases.
When you're debugging code you didn't write, and you don't have time to read and understand that half a million lines because you need to ship in one week, and you have 2 hours to fix the bug, the debugger can come in handy.
We're talking about programming, and that's not programming. That's called piling shit on top of shit.
No, it's what happens when you have code that's been maintained for decades by dozens of programmers, most of whom have since moved on to pastures new. Not all of the code has someone on the team who has full insight into it. Sometimes that code breaks because of changes elsewhere. Yes, it would be nice to fully understand the code before fixing the problem; but that's not always a luxury you have.
If you are clever enough to avoid situations where that is necessary than it might be said that you are skilled in the career choices of a programmer. However it does not say anything about your skill as a programmer per se.
I use debuggers as ways of inserting print statements into the code, without knowing what exactly I want to print before running it.
So, it goes something like this:
1. Insert `import pdb; pdb.set_trace()` into the code where I think there's an issue.
2. `print foo`
3. Hmm, that doesn't seem right... `print baz(foo)`
4. Ah, I needed to change... tabs over to editor
This style is heavily influenced by the fact that I primarily program in Python and Ruby, where one generally learns the language by typing commands into a REPL, rather than executing a file. When working on a Python project with a bunch of classmates who were good programmers, but used to Java and C++, I found that they found this approach utterly unintuitive.
