One way to look at it is that, if I rely on a debugger and the style of development it promotes I will not try to make those reload times shorter for my project

One way to look at it is that, if I rely on a debugger and the style of development it promotes I will not try to make those reload times shorter for my project and that will result in a different style of developing software, tool-wise. One thing I saw happen in C development is, because the projects were so big and a reload after a code edit would also require a re-initialization phase to bring you back to that point in the code you were before you made the change, is that at one point you introduce the scripting language the debugger offers. Small files, at first, to set-up global state, to call the right functions, etc, since the project was meant to be debugged as a whole and not worked on in individual buildable and runnable code files. Like the classic maths library, for example, extracted into a different file and developed individually, without taking into account the rest of the project. That speeds up the development velocity, for example. And you can test it against locally available sets of data, like lists, matrices and what have you. Yes, I've used the Common Lisp debugger. But I also use JavaScript to pay the bills, so to speak. I've wrestled for months on end with the nodejs debugger and its integration with Emacs. Lost connections, wrong configs, random errors, etc. I still think the debugger is an extra tool, like a code editor is an extra tool, the finished product doesn't have any trace of what code editor you've used in the process. So if you can make your life easier without one, why not, there is no absolute requirement that you should use a debugger, for our example. Anyway, that is my reasoning. It might be wrong, it might be right, but it's taken from actual practice. Some people might have different experiences and that is fine, too.