4 ms·

> Doing “something else” means (1) rethinking your code so that it is easier to maintain or less buggy (2) adding smarter tests so that, in the future, bugs are

by maximus1983 7y ago

> Doing “something else” means (1) rethinking your code so that it is easier to maintain or less buggy (2) adding smarter tests so that, in the future, bugs are readily identified effortlessly. Investing your time in this manner makes your code better in a lasting manner… whereas debugging your code line-by-line fixes one tiny problem without improving your process or your future diagnostics. I've been a professional now for about 15 years and very, very rarely do I get to work on "my code". Almost all of the code I have to work with was written by someone else originally and I have to just modify the system for new requirements. Tests do not exist or if they do they are largely incomplete. So the only thing to do is to step through find the problem, fix the ticket and move on. Sure If I get to design the system I normally write it very simply / well structured with appropirate levels of abstraction and with enough tests to expose the bugs in my code. But very rarely do I get paid to work on my code, because my code doesn't need a lot of maintenance. I normally am asked to make changes to bad systems. > Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements. Thinking harder when I have a project with millions of lines of code (this is normal in large financial systems) won't help me. A debugger will. I think a lot of these famous programmers have never had to work with something terrible and probably never will and that is why they make such blasé statements.

tootie 7y ago
I find this kind of thinking to be borderline insanity. Why would I expend so much mental energy trying to understand what the past dozen developers were thinking when it's trivial to just inspect values and deal with the reality of the system as it is right now. If a function is expected to return a value of 25 and it's returning 17, I don't need to reason about their code to fix it. My tactic is always to write some very tight unit tests around the sections of code closest to the problem and run them through a debugger so I can see where it goes awry.
- bshipp 7y ago
  This is my experience as well. Debuggers are extremely helpful when trying to integrate third party code with incomplete documentation. It's one thing to run a print statement at a specific level, but having the ability to explore an object and it's neighbouring objects can immediately provide insight instead of trying to find the function in the source code and deciphering it.
- zepolen 7y ago
  This is how the system ends up as a maintainable mess in the first place, where the fix for the aforementioned bug was to +8 and move on, which causes (at a later date) some other section to break because instead of 25, it's returning 33 so the developer adds a -8 and moves on...
  - lostmyoldone 7y ago
    I assume you meant an unmaintainable mess, and not a maintainable mess, but nevertheless, debuggers are not the cause. You get messy code at least as quickly without a debugger, possibly even faster since bug fixes in my experience tend to be even more shallow, in many teams. The values of the management, the values of the team, and resource availability is what matters in regard to writing, and keeping code maintainable. I've worked with people who have had a similar idea, that using debuggers are somehow "bad", I have also had to rescue them by using a debugger to understand issues with code they had struggled to figure out for days, or even weeks, meanwhile causing severe issues for clients. When you claim tools as the cause for your mistakes, then it could certainly be the case that the tool is of bad quality, which clearly is not the claimed issue with debuggers in the article. More likely though is that you haven't really learned when, and how, and why to use the tool. Debuggers are brilliant for validating if you mental model of the code is correct, or more commonly, to understand how it's wrong. This can have a side effect of solving bugs, especially bugs in your own thinking
  - tootie 7y ago
    "Maintainable mess" is the apotheosis of every human endeavor.
- 7y ago
sanderjd 7y ago
I think it's a fantasy that if it were only "my code" it would be perfect and simple. Most of the worst code I've worked on was my code, after it had grown and adapted to new requirements and after I'd forgotten why I did things the way I did them. Tests are necessary but far from sufficient for making a system comprehensible.
- maximus1983 7y ago
  Sure I’ve written some awful code in the past but I am at the point that when building certain application types I know exactly what I am doing. If I was writing code in c++ I would probably create something awful because I wouldn’t know what I would be doing.
icxa 7y ago
> I think a lot of these famous programmers have never had to work with something terrible and probably never will and that is why they make such blasé statements. Do you think they never had to work with something terrible, or when faced with something terrible, they took the time to make it not terrible? The track record for the software these two have built speaks for itself.
- maximus1983 7y ago
  I think their definition of terrible and mine are very different.

tootie 7y ago

I find this kind of thinking to be borderline insanity. Why would I expend so much mental energy trying to understand what the past dozen developers were thinking when it's trivial to just inspect values and deal with the reality of the system as it is right now. If a function is expected to return a value of 25 and it's returning 17, I don't need to reason about their code to fix it. My tactic is always to write some very tight unit tests around the sections of code closest to the problem and run them through a debugger so I can see where it goes awry.

bshipp 7y ago
This is my experience as well. Debuggers are extremely helpful when trying to integrate third party code with incomplete documentation. It's one thing to run a print statement at a specific level, but having the ability to explore an object and it's neighbouring objects can immediately provide insight instead of trying to find the function in the source code and deciphering it.
zepolen 7y ago
This is how the system ends up as a maintainable mess in the first place, where the fix for the aforementioned bug was to +8 and move on, which causes (at a later date) some other section to break because instead of 25, it's returning 33 so the developer adds a -8 and moves on...
- lostmyoldone 7y ago
  I assume you meant an unmaintainable mess, and not a maintainable mess, but nevertheless, debuggers are not the cause. You get messy code at least as quickly without a debugger, possibly even faster since bug fixes in my experience tend to be even more shallow, in many teams. The values of the management, the values of the team, and resource availability is what matters in regard to writing, and keeping code maintainable. I've worked with people who have had a similar idea, that using debuggers are somehow "bad", I have also had to rescue them by using a debugger to understand issues with code they had struggled to figure out for days, or even weeks, meanwhile causing severe issues for clients. When you claim tools as the cause for your mistakes, then it could certainly be the case that the tool is of bad quality, which clearly is not the claimed issue with debuggers in the article. More likely though is that you haven't really learned when, and how, and why to use the tool. Debuggers are brilliant for validating if you mental model of the code is correct, or more commonly, to understand how it's wrong. This can have a side effect of solving bugs, especially bugs in your own thinking
- tootie 7y ago
  "Maintainable mess" is the apotheosis of every human endeavor.
7y ago

sanderjd 7y ago

I think it's a fantasy that if it were only "my code" it would be perfect and simple. Most of the worst code I've worked on was my code, after it had grown and adapted to new requirements and after I'd forgotten why I did things the way I did them. Tests are necessary but far from sufficient for making a system comprehensible.

maximus1983 7y ago
Sure I’ve written some awful code in the past but I am at the point that when building certain application types I know exactly what I am doing. If I was writing code in c++ I would probably create something awful because I wouldn’t know what I would be doing.

icxa 7y ago

> I think a lot of these famous programmers have never had to work with something terrible and probably never will and that is why they make such blasé statements. Do you think they never had to work with something terrible, or when faced with something terrible, they took the time to make it not terrible? The track record for the software these two have built speaks for itself.

maximus1983 7y ago
I think their definition of terrible and mine are very different.