Ask HN: What's the *right* way to debug a program?

Reproduce the bug. Reproduction steps/environments are usually provided by support engineers or QA. Look through log files for any specific error messages, and use grep to find where in the code the error is coming from if it's not specified in the exception stack trace or something like that. Look at the code and form a hypothesis about where the bug might be located (use a "binary chop algorithm" discussed in books such as Code Complete and Debug It). Create breakpoints and step through the code with a debugger and record your observations. If you still haven't found the bug, use the data you just collected to form a stronger hypothesis and repeat the process until you've identified the source of the bug. Then apply the fix, and run some unit (or integration?) tests to verify you didn't introduce a regression or that you actually treated the symptom instead of fixing the root of the problem.

This might not be the best approach, but it generally works for me. I highly suggest reading the following books: Debugging, Debug It! and parts of Code Complete.

There is no right way to debug. Whatever finds your bugs works.

Personally I use whichever debugger I have on hand with breakpoints and walk through code to see what's going on, that usually lets me find my bugs fairly quickly. Of course the first step is reproduction of the bug, which can sometimes be hard.

It depends on the kind of program. Is it client-side, server-side, is it a console command line application or a daemon process?