Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I always start by looking at the code and trying to get an intuitive leap about the problem. But if it does not come the next step will often be to drop a breakpoint on the first line of the 7 or 8 functions involved run it and feel the flow. One of my specialties is embedded code in C/C++. Not even an OS necessarily. ISRs changing state behind your back, etc. Feeling the program run can be important. Seldom do you single-step. Often you drop breakpoints at the important points like the first line of a function or the first line of an iteration.

Depending on what you mean by "isolating ... programatically" it might be very similar to how I sometimes use unit-tests in general or the REPL when programming in a high-level language such as Lisp or Python.

The unit-test/REPL lets you play with functions on an individual level. Checking inputs and outputs. Slowly synthesizing more complex arrangements which approach the problematic arrangement actually found in the real code.

All of this is about augmenting your intuitive understanding of the code with real solid empirical data about the behavior of the program. If you can't explain a given bug your intuitive understanding is somehow wrong or lacking and often you'll see surprising behavior when you actually instrument the program. Those surprises lead you to the solution.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: