Set a breakpoint, burn through the code. Chrome has some really nice features - you can tell it to skip over files (like jQuery) you can open the console and poke around, set variables to see what happens.
Stepping though the code line by line for a few hours will soon show you the basics.
I remember needing to learn Ruby and Rails on an existing closed codebase and having the debugger take me right to the core of Rails several times to understand why certain things were done in a certain way in the top level code. This allowed me to get acquainted with internals of Rails and how Ruby's inheritance system much faster as well as the existing codebase that was built on top.
That's the theme I hear when prodding people who (sometimes loudly) say they don't use debuggers. They work on codebases that are either small, solo projects, or change very slowly. That way they can keep an accurate simulation of the entire program in their heads.
Meanwhile, I've always worked on codebases that were changing faster than I can keep up. The majority of my debugger time has been in code I've never seen before.
I don't find it a hindrance in any way seeing what part of the Django code called my code.
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.
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.
The debugger runs in as many threads as the app itself. If you're debugging C#, and your program is in 37 threads, you can debug all of them simultaneously or debug one and ignore the others.
Understanding the code and keeping it in memory sounds like a great practice, but it also seems entirely orthogonal to using a debugger.
I have the exact opposite attitude: I live in the debugger. Most of my resistance to trying "new hot" languages is their universally terrible debuggers. (Usually they either don't exist at all, or only exist in CLI form.) IMO, if you don't have a working, stable, graphical debugger, your programming language has no business being 1.x.
If you're working on, say, a huge Java codebase, then a debugger is practically essential because you've got a lot of code to navigate, and you probably want to see what flavour of objects are being passed around and how their state is being updated.
On the other hand, if you're working on, ooh, a Nodejs codebase, you're probably looking at less code, with a debugger that's much slower, and probably more functional code that is operating on data directly. Using a debugger in that case is often slower than just using print statements.
You're saying to delete commented-out code once the new code works. Put your code in version control instead. Logging is to once-off printfs as version control is to commented-out code.
Don’t be primitive about it. :-)
The serious answer is: use a good logging framework. In particular, I’d suggest something that can log at selective levels of information for different parts of your system.
If your project’s culture is to instrument your code like this routinely, it can be a very useful asset, and it’s no more disruptive in practice than say adding comments or writing tests. In each case, with experience you get better at judging where to focus your efforts and how much detail is worth including by default, and if that turns out not to be enough you can always add more while you’re working in that area.
With modern tools for recording and analysing logs, there is relatively little useful information that you can easily find using a debugger but can’t easily find from good log output. On the other hand, logging has some big advantages: you can capture how your system changes over time, you can record and review concurrent behaviour cleanly, you can capture information from different parts of distributed systems that might be written in different programming languages or running on different devices.
Just plain "debug log statements" I have yet to hear a good use case for. Every time people have put them in, it's because some bug called for their inclusion, then the bug got fixed, then the statements got left around after the bug was fixed. Or the bug didn't get fixed and it's a matter of "why don't you fix the bug?"
There's rare cases where there's an ongoing issue with a known bug that you don't know the fix for yet, so you drop debug statements in production code hoping to catch it. But this is supposed to be a rare, rare case.
For medium/large programs I'll often prefer a debugger because I can easily and quickly try to diagnose the problem without having to wait for a new build to complete with the added traces.
You're using a primitive debugger, you just don't know it.
You can dump statements through a function and see it's progression when run without having to interact with it.
Throw in something like FirePHP (which allows dumping pretty much anything out as a viewable/collapsible trace, other languages have similiar) and the use case for a lot of using a full blown debugger is removed (it's still incredibly powerful when needed).
So I use both.
(With that said, when I have a nasty bug that requires squishing around in the guts of my program, breakpoints are invaluable. But it's a pretty huge hammer that only comes out on occasion.)
EDIT: I wonder how useful an editor that allows inline debugging code would be? Instead of setting breakpoints in your IDE and then configuring them in an individual window, you'd enter a "debugging editor" mode that would allow you to add debugger-only code for things like conditional breakpoints and printf statements right alongside your normal code. The original source files would not be edited, but while in this mode, it would appear as if they were. (Maybe the debugging code would show up in red.) That way, you could easily access all your local state and implement complicated queries without ever leaving the context of your code. In other words, it would be just like printf debugging, but once you no longer need to debug you'd just collapse those statements out by leaving the debugging editor mode and your original code would be unchanged. Perhaps this debugging code would not compile along with the rest of the code but would instead use the debugging hooks that normal breakpoints use, unless the conditions are particularly complex or something. Just a thought.
Configuration got a lot easier since the installation wizard has been introduced: http://xdebug.org/wizard.php
But I use xdebug and phpstorm. I find it better than netbeans. Search in netbeans is good, but the whole thing has a weird GUI and is slow.
Best bet is to try a bunch.
That is incredibly powerful (PyCharm has it as well).
Without a debugger you're a sitting duck!