4 ms·

I tend to find that the amount of time/effort required on debugging is inversely proportional to good practices. If everything is heavily design by contract, c

I tend to find that the amount of time/effort required on debugging is inversely proportional to good practices. If everything is heavily design by contract, code is clean, there are lots of tests, everything it tdd'd then most bugs are almost always shallow and surfaced quickly. Good debugging skills and tools aren't so useful in this environment. By contrast, if the code base is a mess and there are no tests I seem to spend about 60% of my time ascertaining the cause of unexpected behavior. Good debugging skills and tools are invaluable in this environment.

ensiferum 8y ago
Couldn't agree more. When I work on my own software with very nice and clean design most bugs (which are quite rare) are almost always very superficial and simple. The most I ever need to do is to hit the bug in the debugger and look at the stack trace and the bug is obvious. That being said that has been really bad for my debugging skills which have atrophied tremendously. At work where the code bases are complicated messes I find myself not being able to debug something as well as I should.
stult 8y ago
Exactly, but I would argue that which of these environments you operate in isn't always under your or even your company's control, so debugging skills are indispensable for the overwhelming majority of engineers. For example, I spend 50% of my time debugging another company's code, 20% of my time debugging my company's legacy code, 20% of my time refactoring/implementing unit tests (I'm sure like most engineers here, I consider those inseparable and essentially one activity), around 9% on new feature implementation written to the same standards as that refactored code, and maybe 1% of my time debugging code that is up to standard. The 50% is the real killer because I have absolutely no control over the codebase that forms the bulk of it. It's produced by another company that's the primary contractor on the project and we just have to make our one small component work within the larger application. So it's not even like debugging a typical third-party dependency, in that we can't replace it with a different dependency and (due to terrible architecture) our code is riddled with hidden dependencies on their shitty, poorly documented code. My point being: debugging skills are a core competency for most engineers because it's rare to have complete control over the code you interact with, and even rarer to have it all up to acceptable standards. Even in the best of environments, we all spend time debugging issues arising from third-party dependencies, whether it's an issue with the IDE, compiler, language design, server configuration, or literally any of the million things that can break your system unexpectedly on any given day.
bjpbakker 8y ago
> everything is heavily design by contract, code is clean, there are lots of tests, everything it tdd'd then most bugs are almost always shallow I agree that this is all good practice and helps prevent common classes of bugs. Obviously it will also safe you time of debugging these. But your stack doesn't end at your code. There's a whole bunch of other code yours is linked to, there might be an interpreter or vm, there's the OS, the kernel and firmware. So IMO it's a bit naive to say you don't need debugging tools/skills.
- crdoconnor 8y ago
  >it's a bit naive to say you don't need debugging tools/skills. I didn't say that. >But your stack doesn't end at your code. There's a whole bunch of other code yours is linked to, there might be an interpreter or vm, there's the OS, the kernel and firmware. So Good quality code / projects would mean keeping a firm control over all of that stuff, so that when it breaks, it's fairly obvious what caused it (e.g. distinguishing between bugs caused by a different environment and bugs caused by newly pushed code).

ensiferum 8y ago

Couldn't agree more. When I work on my own software with very nice and clean design most bugs (which are quite rare) are almost always very superficial and simple. The most I ever need to do is to hit the bug in the debugger and look at the stack trace and the bug is obvious. That being said that has been really bad for my debugging skills which have atrophied tremendously. At work where the code bases are complicated messes I find myself not being able to debug something as well as I should.

stult 8y ago

Exactly, but I would argue that which of these environments you operate in isn't always under your or even your company's control, so debugging skills are indispensable for the overwhelming majority of engineers. For example, I spend 50% of my time debugging another company's code, 20% of my time debugging my company's legacy code, 20% of my time refactoring/implementing unit tests (I'm sure like most engineers here, I consider those inseparable and essentially one activity), around 9% on new feature implementation written to the same standards as that refactored code, and maybe 1% of my time debugging code that is up to standard. The 50% is the real killer because I have absolutely no control over the codebase that forms the bulk of it. It's produced by another company that's the primary contractor on the project and we just have to make our one small component work within the larger application. So it's not even like debugging a typical third-party dependency, in that we can't replace it with a different dependency and (due to terrible architecture) our code is riddled with hidden dependencies on their shitty, poorly documented code. My point being: debugging skills are a core competency for most engineers because it's rare to have complete control over the code you interact with, and even rarer to have it all up to acceptable standards. Even in the best of environments, we all spend time debugging issues arising from third-party dependencies, whether it's an issue with the IDE, compiler, language design, server configuration, or literally any of the million things that can break your system unexpectedly on any given day.

bjpbakker 8y ago

> everything is heavily design by contract, code is clean, there are lots of tests, everything it tdd'd then most bugs are almost always shallow I agree that this is all good practice and helps prevent common classes of bugs. Obviously it will also safe you time of debugging these. But your stack doesn't end at your code. There's a whole bunch of other code yours is linked to, there might be an interpreter or vm, there's the OS, the kernel and firmware. So IMO it's a bit naive to say you don't need debugging tools/skills.

crdoconnor 8y ago
>it's a bit naive to say you don't need debugging tools/skills. I didn't say that. >But your stack doesn't end at your code. There's a whole bunch of other code yours is linked to, there might be an interpreter or vm, there's the OS, the kernel and firmware. So Good quality code / projects would mean keeping a firm control over all of that stuff, so that when it breaks, it's fairly obvious what caused it (e.g. distinguishing between bugs caused by a different environment and bugs caused by newly pushed code).