4 ms·

The debugger being sequential is a consequence of your code also being sequential at the CPU level. Understanding the code is often a luxury we don't have, eit

The debugger being sequential is a consequence of your code also being sequential at the CPU level. Understanding the code is often a luxury we don't have, either because we didn't write it in the first place or because there are just too many moving parts each tracking their own state and interacting with everything under the sun. This is especially true for long-running programs that do much more than just transform inputs into outputs. For example a video game would be complete hell to develop without a solid debugger. Even if you believe you understand the complete code and all its behavior the testers will always find a way to make the game crash after 2 hours of playing leaving the game's state completely broken and without a debugger you'll be scratching your head endlessly trying to replay how that happened. In these cases the number of different states and behaviors you can get out of the system is incredibly high, easily a few orders of magnitude more than the human brain can handle.

yellowapple 11y ago
> or because there are just too many moving parts each tracking their own state and interacting with everything under the sun. For me at least, that's typically my cue to start refactoring. If I can't model at least the general behavior of my program in my head, then it's probably needlessly complicated. This isn't always possible, of course (such as in the case of long-running programs, as you mentioned; it's still possible in a lot of cases, though, and splitting off functionality into smaller, easier-to-digest pieces can make troubleshooting much easier), but it's been a useful mentality for me, and has significantly reduced the need for me to use some sort of debugger or even 'print' statements to make sense of code. This doesn't address the original question of understanding new codebases, though.

yellowapple 11y ago

> or because there are just too many moving parts each tracking their own state and interacting with everything under the sun. For me at least, that's typically my cue to start refactoring. If I can't model at least the general behavior of my program in my head, then it's probably needlessly complicated. This isn't always possible, of course (such as in the case of long-running programs, as you mentioned; it's still possible in a lot of cases, though, and splitting off functionality into smaller, easier-to-digest pieces can make troubleshooting much easier), but it's been a useful mentality for me, and has significantly reduced the need for me to use some sort of debugger or even 'print' statements to make sense of code. This doesn't address the original question of understanding new codebases, though.