4 ms·

I admit that I am not a good programmer as many in this thread are. I remember being scared and nervous looking at a large codebade and single stepping through

• jerf 8y ago
  I'm generally not a debugger user, not really out of principle but out of generally just not using one much, but I have two major exceptions: 1. Highly recursive code 2. Understanding a new codebase. It is true you ought to build up a model of what code is doing to work on it properly, but I find trying to just read the code that I'm not familiar with to build that model is often both slower and worse than using a debugger to walk through it. Slower, because I'm sitting on the outside trying to stare in at a dynamic process based on my radically incomplete understanding of its static description and the stored state in my rather meager head (I think my raw ability to hold state in my head is probably a bit below average in the programming domain, as evidenced to me by the behaviors I've developed to compensate and other people's lack of need for them). Worse, because when simply reading code it's easy to miss the "validate_input(input)" call that in fact turns out to invoke a multi-thousand line subsystem that doesn't just validate the input, but also statefully mutates it based on all kinds of things and is actually 60% of the system despite its seemingly innocuous name. Stepping through can fix both problems much more quickly, and I'm not being paid to "not use a debugger". I don't disagree that pervasive, continuous use of a debugger can afford bad habits, but the best answer is to simply not develop those bad habits, and then still use it when it is helpful... because there are days when it is very very helpful. (Highly recursive code is an exception because Ye Olde Printe Statementse really break down at that point, and even if you make them work it can still be a lot easier to understand it from the inside than the outside, after the fact. I don't just mean "recursively folding on a list", I mean code that does things like walk heterogeneous trees for a DOM tree or a compiler AST and does a whole bunch of inter-related recursive stuff. Sometime you just have to admit your brainstack has overflowed and call in the tools. Best to avoid writing that code at all if you can, of course, but there's times when it is not avoidable.... because that's where the superpowers come from: https://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html https://steve-yegge.blogspot.com/2007/06/rich-programmer-foo...)
• dmitryminkovsky 8y ago
  Oh I'm not sure I personally completely agree with any of those statements I quoted, including that one "needs to think at a different level" whatever that might mean. They were written by people who had an entirely different path into programming than me, and I think it's important to keep that in mind when consider what makes sense for you. I think practically each one of us can only think at the level at which we are currently capable of thinking, while understanding that we are capable of more. Single stepping through code for me has also been a great entry point into large code bases. I think what happens over time, especially if you look into the internals of open source project and libraries, is you lean to identify what kind of thing you're looking at: like, Is this a thing that's driven by an event loop? Is this an event driven system that calls some pipeline of functions through the stack? You begin to see that people generally make things in only a handful of different ways, and so it's easier figure out how things are connected. But for me it took a lot of stepping through code to figure out a lot of these things, so I'm not sure either how else you can go about it.