I debug because I'm smart, and I enjoy it, and I frequently find bugs that I didn't know existed by seeing inside a frame as it's executing. Debugging is a crucial skill in many fields, particularly embedded work (which is the irony in your comment), and the insight from breakpoints and a couple afternoons of digging is unique among our tools. I hate sweeping generalizations of how programming should be done, regardless of what they are.
Watch this sweeping generalization:
If you don't love debugging, I don't think you're a seasoned or valuable programmer.
If you don't love debugging, I don't think you're a seasoned or valuable programmer.
I call bullexcrement.
I've been coding since before a good portion of the people on this board were sparkles in their parents' eyes. Debugging is a huge time-waster and value-sucker.
Now, if you would say "If you're not good at debugging...", I'd agree with that. But saying one isn't a seasoned or valuable programmer if they don't love debugging just shows a level of immaturity.
I've learned that one must ensure one doesn't confuse love of the results given by a thing or action with the love of the thing or action which gets you those results. You're a seasoned debugger if you can successfully debug a complex system, but you're a wise developer if you can do the things which ensure you don't have to do so.
I can't imagine a scenario, throughout history or today, in which debugging would be unnecessary. It's wisdom to realize that, and more wisdom to realize that "debugging" is a nebulous term here that people are nailing down in different ways.
Test-driven development will never replace debugging, and saying otherwise implies a misunderstanding of one of them.
That's quite a generalization. Debugging does not necessarily mean debugging your own code: you might have stumbled upon a compiler bug, or a timing bug with your hardware, or you may be trying to buffer overflow some massive proprietary database so you can take over the world. All of those tasks will involve lots of time looking at memory addresses and hex dumps, but none of them mean the person doing it is a bad programmer.
Why you need to look at them manually? Computer will compare all that much faster.
If you are good programmer and bug is non-trivial, you will create code to catch bug much faster than you will catch it manually. Moreover, you will be rewarded next time, because your code will be already written and ready to use.
Let's call it "exploratory programming" instead of debugging. Yes, your computer will run unit tests. No, your computer will not notice that memory is being corrupted because of a particular sequence of instructions emitted by the compiler. To solve a problem, you have to understand it. And if you're writing code to solve a problem that's well-understood, you should have just downloaded the library instead.
Did you ever saw how program crashes when run, but works fine in debugger (or vice versa)? What you will do in such case? What you will do after few such cases?
It dramatically improves your cycle time to debug this kind of issue interactively instead of repeatedly stopping the process, coding up a hypothesis as a test case, running the tests, and then dealing with the positive results and the false positive results.
Watch this sweeping generalization:
If you don't love debugging, I don't think you're a seasoned or valuable programmer.