[pmarreck]

> I find it depends a lot on my level of understanding of the project I'm working on. If I wrote 20% or more of the code, or if I was involved in the design, etc., when there is a problem I know just where to look and can get there quickly.

Well, I mean... Ever wonder why that is? Your understanding of the various states the program can get into is fresh in your mind. Come back to it in a year after not looking at it all that time and suddenly you're relying hardcore on your unit test suite to contain that same knowledge in "automated proof" form... OR you start spending a lot of time in the debugger to "re-understand" the system, slowly and manually... Or both.

If you need to use a debugger, it's because you are in some unexpected state. With full understanding comes full control and in those cases, no, you need neither a debugger NOR a test suite, but since a test suite on well-written code already identifies many possible state failures, I've found that leaning on that instead of a debugger works out better in the end.