7 ms·

From the article: > One thing developers spend a lot of time on is completely absent from both of these lists: debugging! I notice that times changed a bit. Th

From the article: > One thing developers spend a lot of time on is completely absent from both of these lists: debugging! I notice that times changed a bit. This was true in software engineering like 10 years ago, but in recent years there is much more emphasis on good practices, constant refactoring, implementing lots of tests alongside the production code, etc. I debug maybe 1-2 hours per month, as a full-time programmer.

JohnBooty 8y ago
in recent years there is much more emphasis on good practices, constant refactoring, implementing lots of tests alongside the production code, etc. I debug maybe 1-2 hours per month, as a full-time programmer. I mean, sure, but in my career the practices you describe are rare. An awful lot of software development involves slogging through "legacy" code that is about as far away from those practices as it gets.
- wool_gather 8y ago
  What do you mean by "slogging through legacy code" if not debugging, refactoring, and (hopefully/sometimes) writing tests?
  - oblio 8y ago
    Aren't you agreeing with him? :)
  - JohnBooty 8y ago
    Yeah that's what I mean. Because I spend a lot of time slogging through legacy code, I spend a lot of time debugging.
    - wool_gather 8y ago
      I guess I misunderstood/reversed the point you were making; sorry.
      - JohnBooty 8y ago
        I love when a debate ends with two people realizing they essentially were agreeing all along ;-)
crdoconnor 8y ago
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.
eksemplar 8y ago
I agree on good practices, but often TDD is wasted time. Not on larger systems, but on small systems with limited functionality where you build using principles like SOLID so you always know where the flaw is, even without the test. We used to write an awful lot of tests on everything. When we stopped we increased productivity by almost 60% at almost no cost. As I said, we still work with TDD, but we only do it when it makes sense.
- bjpbakker 8y ago
  > often TDD is wasted time I'd say it depends. I find that TDD works mostly as the complement to a good type checker. It is extremely useful when the PL has weak or no type checking (eg javascript, ruby, python, c, etc).
- de_watcher 8y ago
  But having a test framework always ready is useful. There is a "Test Driven Debugging": when you look around a bit inside the production error dumps, then try to reproduce it with a test, then debug the test in a much smaller scope with something heavy like Valgrind or a Record-Replay debugger (https://github.com/mozilla/rr https://github.com/mozilla/rr). If you write tests regularly during development then you can also isolate and test parts fast when something goes wrong in production.
- dtech 8y ago
  You don't have to do TDD for this to be useful or happen. In my current project we follow a "bug -> reproduce bug in testcase -> fix bug" method for some parts of the code. This has cause quite an extensive test suite to develop for those parts of the system.
  - jnurmine 8y ago
    I'm curious... I can see the obvious value of having a testcase for a class of bugs, but a testcase for a particular bug instance which was already fixed earlier does not seem right, so I probably misunderstood something. How often do the tests find a problem? When it does find a problem, doesn't this mean that one hits a bug which existed before? Can you give an example of a case when the test was useful?
LoSboccacc 8y ago
I think also that the excessive over reliance of framework that are almost impossible to debug makes the practice a chore - I program in debug often because I prefer to think programs in terms of data flows and not control flows and hate when reflective framework take complete control over initialization without giving debugging hooks in the documentation. it makes understanding your program almost impossible.
corpMaverick 8y ago
Logging. You forgot to mention good logging practices. It is like predicting what information will be needed if you ever need to troubleshoot a piece of code.
- josteink 8y ago
  > Logging. You forgot to mention good logging practices. Good logging practices help you pinpoint what code you need to debug. It does in no way replace debugging.
  - drb91 8y ago
    > The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. "Unix for Beginners" (1979)
    - rsynnott 8y ago
      Note the date. There have been some changes in tools in the last 40 years.
      - drb91 8y ago
        It’s still true. A debugger is still unnecessary for daily debugging.
        rsynnott 8y ago
        Unnecessary, maybe, but it's nice to have. I use IntelliJ's most days. If I just had something along the lines of gdb, I'd use it a lot less frequently; convenience and features have absolutely made debuggers a lot more attractive over the last few decades.
        josteink 8y ago
        > A debugger is still unnecessary for daily debugging. I think this serves nice as a historical record of how the state of the art was 40 years ago. Today, we have IDEs with integrated debuggers (not to mention Emacs and other editors usually integrate decently with gdb, lldb, pdb, etc. Using a debugger doesn't have to mean leaving your code and starting a different tool and different flow. If you'd ask any of my colleagues what they'd do if there was a new policy saying use of debuggers were no longer permitted on a daily basis, the answer would more likely than not include the word "riot". In a huge, complex code-base created by a diverse team of varied skill and competences, you can't assume all code is good or self-explanatory. When you get confused about what happens where and why, the debugger is probably going to be your best friend.
maerF0x0 8y ago
> I debug maybe 1-2 hours per month Do you include "Why isnt this test passing?" as debugging? I would and I spend a good amount of time answering that question.
roca 8y ago
That implies that either tests fail rarely, or when they do fail, it's always easy to determine what the root cause is. Both of those are far outside my experience. Which is it, for you?

JohnBooty 8y ago

in recent years there is much more emphasis on good practices, constant refactoring, implementing lots of tests alongside the production code, etc. I debug maybe 1-2 hours per month, as a full-time programmer. I mean, sure, but in my career the practices you describe are rare. An awful lot of software development involves slogging through "legacy" code that is about as far away from those practices as it gets.

wool_gather 8y ago
What do you mean by "slogging through legacy code" if not debugging, refactoring, and (hopefully/sometimes) writing tests?
- oblio 8y ago
  Aren't you agreeing with him? :)
- JohnBooty 8y ago
  Yeah that's what I mean. Because I spend a lot of time slogging through legacy code, I spend a lot of time debugging.
  - wool_gather 8y ago
    I guess I misunderstood/reversed the point you were making; sorry.
    - JohnBooty 8y ago
      I love when a debate ends with two people realizing they essentially were agreeing all along ;-)

crdoconnor 8y ago

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.

eksemplar 8y ago

I agree on good practices, but often TDD is wasted time. Not on larger systems, but on small systems with limited functionality where you build using principles like SOLID so you always know where the flaw is, even without the test. We used to write an awful lot of tests on everything. When we stopped we increased productivity by almost 60% at almost no cost. As I said, we still work with TDD, but we only do it when it makes sense.

bjpbakker 8y ago
> often TDD is wasted time I'd say it depends. I find that TDD works mostly as the complement to a good type checker. It is extremely useful when the PL has weak or no type checking (eg javascript, ruby, python, c, etc).
de_watcher 8y ago
But having a test framework always ready is useful. There is a "Test Driven Debugging": when you look around a bit inside the production error dumps, then try to reproduce it with a test, then debug the test in a much smaller scope with something heavy like Valgrind or a Record-Replay debugger (https://github.com/mozilla/rr https://github.com/mozilla/rr). If you write tests regularly during development then you can also isolate and test parts fast when something goes wrong in production.
dtech 8y ago
You don't have to do TDD for this to be useful or happen. In my current project we follow a "bug -> reproduce bug in testcase -> fix bug" method for some parts of the code. This has cause quite an extensive test suite to develop for those parts of the system.
- jnurmine 8y ago
  I'm curious... I can see the obvious value of having a testcase for a class of bugs, but a testcase for a particular bug instance which was already fixed earlier does not seem right, so I probably misunderstood something. How often do the tests find a problem? When it does find a problem, doesn't this mean that one hits a bug which existed before? Can you give an example of a case when the test was useful?

LoSboccacc 8y ago

I think also that the excessive over reliance of framework that are almost impossible to debug makes the practice a chore - I program in debug often because I prefer to think programs in terms of data flows and not control flows and hate when reflective framework take complete control over initialization without giving debugging hooks in the documentation. it makes understanding your program almost impossible.

corpMaverick 8y ago

Logging. You forgot to mention good logging practices. It is like predicting what information will be needed if you ever need to troubleshoot a piece of code.

josteink 8y ago
> Logging. You forgot to mention good logging practices. Good logging practices help you pinpoint what code you need to debug. It does in no way replace debugging.
- drb91 8y ago
  > The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. "Unix for Beginners" (1979)
  - rsynnott 8y ago
    Note the date. There have been some changes in tools in the last 40 years.
    - drb91 8y ago
      It’s still true. A debugger is still unnecessary for daily debugging.
      - rsynnott 8y ago
        Unnecessary, maybe, but it's nice to have. I use IntelliJ's most days. If I just had something along the lines of gdb, I'd use it a lot less frequently; convenience and features have absolutely made debuggers a lot more attractive over the last few decades.
      - josteink 8y ago
        > A debugger is still unnecessary for daily debugging. I think this serves nice as a historical record of how the state of the art was 40 years ago. Today, we have IDEs with integrated debuggers (not to mention Emacs and other editors usually integrate decently with gdb, lldb, pdb, etc. Using a debugger doesn't have to mean leaving your code and starting a different tool and different flow. If you'd ask any of my colleagues what they'd do if there was a new policy saying use of debuggers were no longer permitted on a daily basis, the answer would more likely than not include the word "riot". In a huge, complex code-base created by a diverse team of varied skill and competences, you can't assume all code is good or self-explanatory. When you get confused about what happens where and why, the debugger is probably going to be your best friend.

maerF0x0 8y ago

> I debug maybe 1-2 hours per month Do you include "Why isnt this test passing?" as debugging? I would and I spend a good amount of time answering that question.

roca 8y ago

That implies that either tests fail rarely, or when they do fail, it's always easy to determine what the root cause is. Both of those are far outside my experience. Which is it, for you?