4 ms·

I believe the most important trait for debugging is stubbornness. When Stack Overflow and Google do not help, you start doing it yourself. You use tools like a

by qznc 9y ago

I believe the most important trait for debugging is stubbornness. When Stack Overflow and Google do not help, you start doing it yourself. You use tools like a debugger. If the tools do not help, you can look for other tools. If you cannot find them, you can develop your own. You can look at your code, the code of your operating system, and every library you use. You can trace and observe every instruction a CPU performs.

cup-of-tea 9y ago
Yeah, but it's also really bad for sleeping patterns. Countless times I've started to address a bug in the evening only to find it spirals down into some obscure feature I didn't even know existed. After hours of thinking and learning more about the language/tools/computer than you thought there was you feel great, but it's 3am. In my experience there are only two ways to really learn about programming: teaching and debugging.
- tonyarkles 9y ago
  Annnnnd... that's how I ended up solving a really stupid bug last night at 2am. I'll add curiosity to stubbornness too. I very much have to understand how a system is actually working before I'm willing to call it quits and call something successfully debugged. I've definitely worked with folks in the past who don't have that drive; they're more concerned about making it work than understanding why it does/doesn't work. My revelation last night was "deep in this (internal) library, a URL is being manipulated using a badly conceived regex, and that's why this URL is getting mangled". The curiosity to understand it on a deep level pretty much defined my academic career too. I'd already been programming (in some capacity) for about a decade by time I turned 18 and finished high school. Computer Science was a pretty obvious career path. But I ended up doing an EE/CS dual major, entirely because I wanted to understand the pieces below software as well. A few years after undergrad, I realized that a lot of people struggled to debug complex "cloud" systems, and went back to do an M.Sc. to study the problem more carefully. (And, per cup-of-tea's comment, I spent a fair bit of time during my M.Sc. teaching as well, including taking on a Spring & Summer session 200-level CS course as a sessional lecturer)
- jacquesm 9y ago
  > but it's 3am. Where do I sign? When I get really stuck on a bug it's sometimes taken weeks to solve in a never ending game of software dominoes. In very rare cases it ended up being a bug that you could only solve with a soldering iron and some creative rewiring of interrupts. Bugs can be crazily obscured. To the point where you wish you hadn't started but the sunk cost of time invested is such that there is no way back either. This is one of the reasons I was so happy to switch to Unix (and later Linux), the fact that in most cases the program crashes with a core file and access to post mortem debugging (and in many cases a nice stacktrace of how you got there) made short work of most of the bugs. Of course that means you now only have the hardest categories to deal with.
  - checkdigit15 9y ago
    > To the point where you wish you hadn't started but the sunk cost of time invested is such that there is no way back either. "All causes shall give way. I am in code Stepped in so far that, should I wade no more, Returning were as tedious as go o'er."
    - jacquesm 9y ago
      Anecdote: fix the root cause of some really hard to get to bug only to realize you forgot what the highest level problem was.
      - tonyarkles 9y ago
        Are you me? :D
- qznc 9y ago
  I don't do that anymore. As a father of small kids this is simply not an option. My substitute is to externalize my brain: Write things down. Journaling. Blogging.
ryandrake 9y ago
Not enough people reach for a debugger anymore and are actually willing to jump through code, set breakpoints, examine variables in memory. Not enough people dig down instruction by instruction and look at the registers. Debuggers and code monitors used to be your primary development tool. I’ve seen younger developers look at me as if I were some kind of sorceror when I merely step through a C function or dump the contents of RAM. This critical skill seems like a dying art. Isn’t debugging taught in school anymore?
- jacquesm 9y ago
  I actually rarely use a debugger. I used to but the speed with which current processors zip through code makes interactive debugging a lot less useful than it used to be, in very rare cases it is useful, but in the majority of the work I still do in the software world I've found that proper testing is what addresses the vast majority of the cases that would have hit the debugger in the past, and much faster too. Debuggers are still useful but I don't actually recall the last time when I hit a bug that required interactive debugging.
  - tonyarkles 9y ago
    > Debuggers are still useful but I don't actually recall the last time when I hit a bug that required interactive debugging. Microcontrollers: As a side rant, I'm perpetually grouchy with the fact that Arduinos don't have debugger support. I was using AVRs well before the Arduino was a thing (still have my STK500 kicking around...) and I feel like it's a pretty big lost opportunity for hobbyists to not be able to do a deep dive into what is actually going on for when they want to "level up" their MCU skills. Printfs over serial are great, but they often dork with the timing enough to change the character of bugs; JTAG debugging does too, but you can often insert breakpoints with surgical precision to see what's happening without breaking the timing of what you're trying to debug.
    - jacquesm 9y ago
      Yes, in the embedded world I can see lots of applications for the debugger, that's a different world. Real time emulation made life a lot easier as well, compared to the old fashioned way (burn eprom. pray. power up.)
AnIdiotOnTheNet 9y ago
Been there. Usually before I pull out the debugger on some third-party piece of trash product from the 90s (now owned and neglected by MS) I've come up with a way to work around the problem in 15 lines of powershell and a scheduled task. It ain't pretty, and not knowing what's wrong will eat at me, but it is preferable to wasting my life on problems that I don't really want to solve that badly.

by qznc 9y ago

cup-of-tea 9y ago

Yeah, but it's also really bad for sleeping patterns. Countless times I've started to address a bug in the evening only to find it spirals down into some obscure feature I didn't even know existed. After hours of thinking and learning more about the language/tools/computer than you thought there was you feel great, but it's 3am. In my experience there are only two ways to really learn about programming: teaching and debugging.

tonyarkles 9y ago
Annnnnd... that's how I ended up solving a really stupid bug last night at 2am. I'll add curiosity to stubbornness too. I very much have to understand how a system is actually working before I'm willing to call it quits and call something successfully debugged. I've definitely worked with folks in the past who don't have that drive; they're more concerned about making it work than understanding why it does/doesn't work. My revelation last night was "deep in this (internal) library, a URL is being manipulated using a badly conceived regex, and that's why this URL is getting mangled". The curiosity to understand it on a deep level pretty much defined my academic career too. I'd already been programming (in some capacity) for about a decade by time I turned 18 and finished high school. Computer Science was a pretty obvious career path. But I ended up doing an EE/CS dual major, entirely because I wanted to understand the pieces below software as well. A few years after undergrad, I realized that a lot of people struggled to debug complex "cloud" systems, and went back to do an M.Sc. to study the problem more carefully. (And, per cup-of-tea's comment, I spent a fair bit of time during my M.Sc. teaching as well, including taking on a Spring & Summer session 200-level CS course as a sessional lecturer)
jacquesm 9y ago
> but it's 3am. Where do I sign? When I get really stuck on a bug it's sometimes taken weeks to solve in a never ending game of software dominoes. In very rare cases it ended up being a bug that you could only solve with a soldering iron and some creative rewiring of interrupts. Bugs can be crazily obscured. To the point where you wish you hadn't started but the sunk cost of time invested is such that there is no way back either. This is one of the reasons I was so happy to switch to Unix (and later Linux), the fact that in most cases the program crashes with a core file and access to post mortem debugging (and in many cases a nice stacktrace of how you got there) made short work of most of the bugs. Of course that means you now only have the hardest categories to deal with.
- checkdigit15 9y ago
  > To the point where you wish you hadn't started but the sunk cost of time invested is such that there is no way back either. "All causes shall give way. I am in code Stepped in so far that, should I wade no more, Returning were as tedious as go o'er."
  - jacquesm 9y ago
    Anecdote: fix the root cause of some really hard to get to bug only to realize you forgot what the highest level problem was.
    - tonyarkles 9y ago
      Are you me? :D
qznc 9y ago
I don't do that anymore. As a father of small kids this is simply not an option. My substitute is to externalize my brain: Write things down. Journaling. Blogging.

ryandrake 9y ago

Not enough people reach for a debugger anymore and are actually willing to jump through code, set breakpoints, examine variables in memory. Not enough people dig down instruction by instruction and look at the registers. Debuggers and code monitors used to be your primary development tool. I’ve seen younger developers look at me as if I were some kind of sorceror when I merely step through a C function or dump the contents of RAM. This critical skill seems like a dying art. Isn’t debugging taught in school anymore?

jacquesm 9y ago
I actually rarely use a debugger. I used to but the speed with which current processors zip through code makes interactive debugging a lot less useful than it used to be, in very rare cases it is useful, but in the majority of the work I still do in the software world I've found that proper testing is what addresses the vast majority of the cases that would have hit the debugger in the past, and much faster too. Debuggers are still useful but I don't actually recall the last time when I hit a bug that required interactive debugging.
- tonyarkles 9y ago
  > Debuggers are still useful but I don't actually recall the last time when I hit a bug that required interactive debugging. Microcontrollers: As a side rant, I'm perpetually grouchy with the fact that Arduinos don't have debugger support. I was using AVRs well before the Arduino was a thing (still have my STK500 kicking around...) and I feel like it's a pretty big lost opportunity for hobbyists to not be able to do a deep dive into what is actually going on for when they want to "level up" their MCU skills. Printfs over serial are great, but they often dork with the timing enough to change the character of bugs; JTAG debugging does too, but you can often insert breakpoints with surgical precision to see what's happening without breaking the timing of what you're trying to debug.
  - jacquesm 9y ago
    Yes, in the embedded world I can see lots of applications for the debugger, that's a different world. Real time emulation made life a lot easier as well, compared to the old fashioned way (burn eprom. pray. power up.)

AnIdiotOnTheNet 9y ago

Been there. Usually before I pull out the debugger on some third-party piece of trash product from the 90s (now owned and neglected by MS) I've come up with a way to work around the problem in 15 lines of powershell and a scheduled task. It ain't pretty, and not knowing what's wrong will eat at me, but it is preferable to wasting my life on problems that I don't really want to solve that badly.