Hacker News Reader

Comment by imdsm | Hacker News Reader

I'm the same, a few console.logs and I've usually found the problem. Meanwhile, others are attaching debuggers to step through code and try to understand it and I've already been done for 30 minutes and got a cup of tea and some crumpets.

Debugging for me is about my using my brain to step through code, not some fancy IDE that stops me from thinking. It wasn't always so easy though, but the first step is to stop using big tools to help you.

View on HN

While I agree with your assertion that debugging should ultimately happen in the head instead if in the IDE, debuggers can still be useful for console.log folks like us. Because they show you the values of all the variables in scope, a good debugger is basically the ultimate console.log, and can sometimes speed up the diagnosis process by allowing you to check multiple hypotheses in a single program execution.

Also, sometimes even just using console.log can cause bugs to appear or disappear. I recently encountered a bug which was almost impossible to diagnose with console.log, because the string returned by the .toString() call didn't correspond to the real object's actual properties. Of course, this is a rare case, but it highlights the benefit of trying different tools!

Uh, this might be true for simple programs, but please try and debug complex race conditions with console.logs. It doesn't work very well.

How do you use a debugger when your application is distributed across dozens of machines?

For threaded langs that might be true - but in js there are no race conditions in that sense, so console.logs are usually fine for debugging "out-of-order" stuff as well. This is ofc opinionated and based on preference, so YMMV.

Debugging complex race conditions isn't necessarily easy using a debugger either, since halting the passage of time has a tendency to make them go away. Why limit your toolbox? Logging statements and debuggers are both useful methodologies for resolving problems, but in the end, it's as the GP says -- your success is going to depend a lot more on your conceptual understanding of the issue and the application than on the debugging technology.

But how is writing a console.log statement quicker than simply clicking on a line number to set a break point and then inspecting what ever you want?

I'm not even sure if this is worth replying, but I for one use debugger way more than console.log. I also use debugger to try out multiple functions rather than saving code and waiting for a refresh each function I want to test.

You two probably work on dramatically different types of code.

So you litter your code with console.logs?

You remove them when you've figured out what's wrong and fixed it

Or your build tooling can remove them automatically in production mode.

Reply on news.ycombinator.com