5 ms·

Good debugging 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 hyp

by skylark 11y ago

Good debugging 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. As a Python/JS developer a few print/console.log statements are usually all it takes for me to figure out what's wrong with something. For more thorny situations there's always PDB/chrome dev tools. At the end of the day, the people who are the best at debugging things aren't that way because of the tools they use. They're the best because they can clearly visualize the system, how data is flowing through it, and where potential problems might arise. Intuition from dealing with other similar problems also helps.

aerovistae 11y ago
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.
imdsm 11y ago
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.
- sz4kerto 11y ago
  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.
  - msellout 11y ago
    How do you use a debugger when your application is distributed across dozens of machines?
  - eiriklv 11y ago
    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.
  - oxymoron 11y ago
    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.
- wired8 11y ago
  So you litter your code with console.logs?
  - eiriklv 11y ago
    You remove them when you've figured out what's wrong and fixed it
    - ceejayoz 11y ago
      Or your build tooling can remove them automatically in production mode.
- delluminatus 11y ago
  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!
- heptathorp 11y ago
  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?
- devcheese 11y ago
  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.
  - daniel-cussen 11y ago
    You two probably work on dramatically different types of code.
rudolf0 11y ago
>... 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.
Terr_ 11y ago
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.
tedmiston 11y ago
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()

by skylark 11y ago

aerovistae 11y ago

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.

imdsm 11y ago

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.

sz4kerto 11y ago
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.
- msellout 11y ago
  How do you use a debugger when your application is distributed across dozens of machines?
- eiriklv 11y ago
  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.
- oxymoron 11y ago
  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.
wired8 11y ago
So you litter your code with console.logs?
- eiriklv 11y ago
  You remove them when you've figured out what's wrong and fixed it
  - ceejayoz 11y ago
    Or your build tooling can remove them automatically in production mode.
delluminatus 11y ago
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!
heptathorp 11y ago
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?
devcheese 11y ago
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.
- daniel-cussen 11y ago
  You two probably work on dramatically different types of code.

rudolf0 11y ago

>... 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.

Terr_ 11y ago

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.

tedmiston 11y ago

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()