2 ms·

agree entirely that both techniques are useful and should be learned by programmers one thing I think the "just do print debugging" folks miss is what a good t

agree entirely that both techniques are useful and should be learned by programmers one thing I think the "just do print debugging" folks miss is what a good teaching tool a visual debugger is: you can learn about what a call stack really is, step through conditionals, iterations, closures, etc and get a feel for how they really work at some level being a good programmer means you can emulate the code in your head, and a good visual developer can really help new programmers develop that skill, especially if they aren't naturals i emphasize the debugger in all the classes i teach for this reason

Stratoscope 2y ago
> at some level being a good programmer means you can emulate the code in your head, and a good visual developer can really help new programmers develop that skill [emphasis added] I think you meant "a good visual debugger". And I agree completely. A visual debugger isn't just a tool for fixing bugs. It's also a tool for understanding the code. At my last job, the codebase was so complicated that you could spend hours scratching your head over what was going on in a function, especially how the code got to that function and what data the calling functions had that led to this point. Of course you could add print or log statements, but then the question is what to print! And which calling functions needed more print statements. With a visual debugger, I could just set a breakpoint in the confusing function, see all the data it had, and also move up the stack to see what data all the calling functions had. There are cases where you need print debugging. I added one feature that worked perfectly locally and on a test server, but failed in a Jenkins job (ironically running the job on that same test server). That was a case where I added print statements throughout the code, just to see how far it got when running locally vs. under Jenkins. There are many ways to debug a problem. It is wise to be familiar with all of them and know what to use when.

Stratoscope 2y ago

> at some level being a good programmer means you can emulate the code in your head, and a good visual developer can really help new programmers develop that skill [emphasis added] I think you meant "a good visual debugger". And I agree completely. A visual debugger isn't just a tool for fixing bugs. It's also a tool for understanding the code. At my last job, the codebase was so complicated that you could spend hours scratching your head over what was going on in a function, especially how the code got to that function and what data the calling functions had that led to this point. Of course you could add print or log statements, but then the question is what to print! And which calling functions needed more print statements. With a visual debugger, I could just set a breakpoint in the confusing function, see all the data it had, and also move up the stack to see what data all the calling functions had. There are cases where you need print debugging. I added one feature that worked perfectly locally and on a test server, but failed in a Jenkins job (ironically running the job on that same test server). That was a case where I added print statements throughout the code, just to see how far it got when running locally vs. under Jenkins. There are many ways to debug a problem. It is wise to be familiar with all of them and know what to use when.