Hacker News Reader

Comment by codewithcheese | Hacker News Reader

I'm surprised how many of my colleagues don't use the debugging features of their IDE. Being able to step through code line by line and see all the variables states at any time and evaluate arbitrary expressions given those states seems far superior to print/console based guesstimation. However, somehow my colleagues still do great work!

View on HN

Depending on which ecosystem you're working with you may be able to get those tools elsewhere. If you're working with client-side JavaScript for example, then you have multiple choices of browsers with excellent debuggers built in.

That’s still not the same as debugging within your IDE. Having to switch from the browser back to your IDE to find the files to make changes is just another context switch that slows you down. Plus, dealing with async loaded files can be a pain in the browser.

I've tried using VSCode's debugger for Javascript before. And it can be kind of nice, but ultimately on larger projects with their own build tools it can be hard to keep the sourcemaps working in such a way as to not screw up VSCode's debugger, and the gain over Firefox's built in debugger wasn't worth the effort for me to continue to maintain that config.

You can actually configure chrome to be able to edit your local files and save changes directly. Although admittedly it was a bit unreliable when I tried it.

Yeah but then you're editing code in, what is basically, notepad. Good luck finding the file you need to edit from the Chrome dev console.

Having the ability to do everything from your IDE allows you to leverage all of the tooling built into that IDE.

It's a fair sight better than notepad. You get syntax highlighting, Ctrl/Cmd-P to fuzzy search for files to open, and even things like multiple cursors. But you're right that it's not quite the same experience as a full editor. You won't get linting, type checking or autocomplete.

Concurrent code is not easy to debug line by line. Logging is a good alternative.

I prefer printf debugging. a) it works everywhere, even say when the bug is only reproducible in a remote CI, or in languages that don't have good IDE support. My printf skills are top notch thanks to using it everywhere. b) the printf stuff can stay around until the next compile. I can easily vary it, put it into VCS, share it with others, etc. For IDEs such features may exist, but again I'm locked into an IDE.

Sure, in some settings the source code is not available and you still want to debug. Then I use debuggers. But outside of that I prefer printf debugging.

Note that I'm not saying that people who prefer debuggers are wrong. They probably have their reasons, as I have. Everyone should be allowed to use the method they prefer the most.

So far as I can tell from having worked with lots of people with lots of different preferences, there is basically no correlation between preferences in debugging approaches and ability/productivity.

I do however really wish the world made it easier to help turn both state introspection via interactive debugger and state introspection via printf shotgun into structured trace-level logging that could be shared and/or committed to the codebase independent of the original debugging tool used.

Yes this. Distributed tracing is making these concepts more popular but in many cases it requires manual instrumentation of every function call and state one wants to track. I would love to see more auto-instrumentation but seems this should be implemented at the interpreter or compiler level.

Ah but who will debug the debuggers.

Reply on news.ycombinator.com