I think it very much depends on the work you’re doing. My co-workers depend on debuggers which are a crutch that allow them to _feel_ like they have control over our spaghetti code — “it’s fine, I can step through!” — but the code I produce (without a debugger but through TDD) is much more resilient. There’s certainly engineering problems that benefit from a debugger but I think for most modern work they’re not essential — and often a crutch.

While I don't think they are only ever used as a crutch, I'm starting to see more and more how they definitely are an enabler of spaghetti code.

It's not even just spaghetti but things that are very obtuse too. I often need a debugger whenever I see things in the code like if(variant.sourceId == null) and then below is the large unnamed block of code that also doesn't give any indication of what it implies. Because I have no idea what it implies, I have no idea how the data got into that state, so it's like... What case triggers this code?

I often wind up refactoring that stuff after computing an understanding of it. It usually comes out significanty easier to read and not likely you require a debugger to understand it.

So I that regard I think debuggers enable unnecessarily difficult to understand code to hang around.

I respectfully disagree. Debuggers are essential while you are debugging. Say you inherit some code and you are not sure where to make the necessary changes. Nothing beats stepping through until you find the place that does the thing and add your change.

I think this is the crux of it and there’s a balance.

Debugging by printing the state of variables too frequently and resorting to line-by-line debugging of every function can be inefficient if it becomes a crutch for the developer. This could be due to a lack of confidence or a lack of understanding — or just habitual.

Well, Linus is one of those people: https://lwn.net/2000/0914/a/lt-debugger.php3

>> I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_.

I mostly agree (the “too lazy” bit seems a little harsh).

I liken developers who proudly say they don’t use debuggers to surgeons who don’t take X-rays.

Sure, you could, but why make your life harder?

One of the best moves I made the first 10 years of my career was stepping through every single line of C++ I ever wrote just to observe it working as I thought (and a lot of times it wasn't). MSVC++/Visual Studio made this a very natural thing to do without breaking the flow.

Today, I use a variety of tools and languages and ... hmmm... I don't actually remember the last time I used a debugger on my own code.

Well, when debugging in C/C++ (and I have used lot of debuggers) you may find they don't help you to find the hard to spot problems.

Sometimes a bug just doesn't pop when debugging due to differences in the memory management of the debug mode or race conditions in multi-threaded due to different timings...

So, "text-debugging" (like printf("I'm here") debugging) sometimes is the only way to find precious bugs.

Back in the day most of my colleagues only relied in printf debugging. But we were just a bunch of linux geeks developing kernel modules, linux apps and QT apps (QT brought a nice IDE for debugging, truth to be told)...