I wrote a pretty long comment about the tools I use for debugging JS, but yeah, in the end the guy who's been here twice as long as me and wrote most of the system can usually debug things in a fraction of the time because he can guess what's causing a problem just from reading a description of the bug.

But I can't give that to people through a comment on HN, so I stuck to tools.

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.

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.

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.

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.

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.

In Python I use a small collection of built-ins frequently for debugging:

For any object foo:

    type(foo)     # show an object's type
    dir(foo)      # list an object's methods
    help(foo)     # pydoc
    id(foo)       # show an object's memory address
    foo.__dict__  # show an object's internal data structure

And I have a snippet triggered by "pdb<tab>" for pdb:

    import pdb ; pdb.set_trace()

One minor benefit of using a "real debugger" is that it makes it easier to stumble across situations or flows that you didn't expect just from a direct-reading of the code.

Granted, often those moments are cases where the code is working correctly but you misunderstood or misremembered things, but the fact that you identified (and resolved) the disconnect is valuable, particularly if you're doing a deep-dive to figure out a nearby problem.

>... is a lot like good science. You start with a firm understanding of the system, form a hypothesis about what could be wrong with it, test your hypothesis, and then repeat. The stronger your initial understanding of the system, the faster you can debug things.

>They're the best because they can clearly visualize the system, how data is flowing through it, and where potential problems might arise

This also applies very well to appsec/vulnerability finding.