It depends on the difficulty of the bug(s) that need to be localized and fixed.<p>I use a wide range of techniques from simple printf's all the way to a full-blown methodology that has not failed, especially when dealing with coupled bugs or those caused by concurrency issues, hardware and such.<p>I wrote about my methodology here: <a href="http://ortask.com/wp-content/uploads/fault_localization_improved_testing-Non_ACM.pdf" rel="nofollow">http://ortask.com/wp-content/uploads/fault_localization_impr...</a>
Though I'm a big fan of debugging, and one of my specialties is debugging <i>everything</i>, I'd also like to point out that writing unit tests is also a very good way to "debug".<p>2 good things come out of unit tests:<p>1. You'll decrease the chances of having to debug that code again
2. You'll learn how to write code that needs less debugging.<p>Now to adress your question directly, I have developed a few techniques of debugging, which come in quite useful.<p>1. Going directly to the problem. Example 1: you're debugging some database problems -> put a breakpoint in the library that's interfacing with the database. Example 2: Some object has some unexpected property -> put a breakpoint at the point when that property is set. Example 3: you're receiving weird http requests -> put a breakpoint as close as you can to the code giving you the request.<p>2. Conditional breakpoints. Some IDEs have this feature build in. If not, you can just write code around that. All you have to do is write a conditional statement with the condition you expect, and if it will evaluate to True, put a breakpoint inside this condition - there you have it, simple conditional breakpointing (helps with loops and other scenarios).<p>3. Write code that minimizes state change. I know I'm being preachy again, but the worst bugs I encountered all revolved around objects being changed by code in extremely unexpected places. Don't do that! Think by default never to modify objects once created, and only stray from this rule when the alternative becomes ridiculous (e.g. when you have to write a lot of really complicated code which nobody will understand)
I usually will look at the input, and then look at my output. If it's not what I expect, I look at the code. Then I'll discover something usually. It's hard to articulate how I do it. I couldn't pass one of those hacker rank style challenges for 2 or 3 companies this year out of the box, but I think I can debug code pretty well.
For 'shallow' bugs, printing / logging - solves problem 90% of time.<p>Deeper bugs use the IDE, breakpoints and debugger, goto definition and call stack examination solve the other 10%<p>Some tips for production: Put logging calls in at critical points -- e.g. initialisation of interfaces log input and output shapes (I work in mostly in vectors), DEBUG level logging, which is more verbose, can log the shape of incoming vectors to help with sanitation efforts.
Yes, debug logs are my usual m.o. too. In general I follow the divide-and-conquer approach for localizing the source of a bug - it works well for > 95% of bugs.<p>If you're using an interpreted language, a REPL is brilliant for debugging individual functions (I use this mostly with Lisp, but also to some extent with Python).<p>Disclaimer: I'm not a professional dev...