5 ms·

> I feel my way around it. I'll use my editor/debugger/REPL to jump me from place to place to build up a non-visual structure of the program in my head. This i

by octane 17y ago

> I feel my way around it. I'll use my editor/debugger/REPL to jump me from place to place to build up a non-visual structure of the program in my head. This is interesting because I am a "visual" developer and have never really used a gdb-style debugger at all in nearly 10 years of professional dev experience. I prefer isolating problematic code programmatically and refactoring my mental picture of the architecture/data structures until I can mentally visualize what's going wrong in my math/logic. This has given me grief with hairy pointer code where running something like 'printf' actually changes stuff in memory that you're trying to look at, but I really just don't understand how anyone can use a debugger to step through things one line at a time when that's essentially what I'm doing in my head when I look at code. Then again I've never worked on anything as complex as, say, an OS kernel, so what do I know.

mdakin 17y ago
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.

by octane 17y ago

mdakin 17y ago

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.