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.
