>Of course, nowadays in modern webdev it seems that most developers no longer use step-debuggers
You make it sound like step-debuggers were the traditional, established thing.
Whereas most programmers back in the day would get by with some carefully placed print statements (based on specific intuition) instead of stepping around to see what goes on.
"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." (Brian Kernighan).
I've used both, and still do use both in concert with each other.
The debugger is a tool for gaining that intuition about how the program operates, and carefully-placed log statements are a tool for cutting the search space of where you need to place breakpoints and single-step.
I'm a heavy user of the excellent Visual Studio debugger for C++ and C#. But for years I didn't use an IDE or debugger for server side Python; I did a lot of Zope & Django debugging with print statements and log files. A couple of years ago I started using IDEA's PyCharm. It's massively accelerated how quickly I can fix bugs in Tornado based server code. More recently I've switched my server side coding style to use coroutines, and that requires a shift in debugging mindset as one can't make the same control flow assumptions as for conventional callback style single threaded async code. I'm looking forward to debuggers that understand how to step over yield or await.
Oh yes...don't get me wrong, there will always be room for crash-and-burn debugging (my pet name for that style), and no doubt interpreted languages make it a much faster and safer method than doing the same thing in C back in the day.
Of course memory corruption was always a nasty potential culprit in C, and once again, using a step-debugger help with those issues immensely for a variety of obvious reasons as you could very quickly often see the exact line the program blew up.
BK's explicit endorsement of C&B debugging was bound to show up sooner or later, and we didn't even really touch on the difficulty of using a stepper in multi-threaded network apps, but remember I simply posited that stepping through code in real-time helped me quickly learn from devs much smarter and more experienced than I.
For me that only applied to ZX Spectrum coding, ever since I moved into MS-DOS and also when coding with friends on their Amiga systems, that I have always used a debugger.
Only when the environment forbids me of using one, do I make use of such techniques.
You make it sound like step-debuggers were the traditional, established thing.
Whereas most programmers back in the day would get by with some carefully placed print statements (based on specific intuition) instead of stepping around to see what goes on.
"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." (Brian Kernighan).