5 ms·

What I tell others: I'm so good that I don't need a debugger. The truth: Print statements work so well that they dramatically decrease the need for a debugge

by edw519 16y ago

What I tell others: I'm so good that I don't need a debugger. The truth: Print statements work so well that they dramatically decrease the need for a debugger. Then when I actually do need a debugger, I have used it so infrequently that I forgot the commands, so I just use more Print statements.

Vivtek 16y ago
Hahaha! This is exactly what I wanted to say!
mesmerized 16y ago
Not using a debugger is like giving up a knife and using a spoon to eat your steak. Yeah, you can do it, but why would you? Debuggers are invaluable when you encounter difficult bugs, especially ones related to threading issues. Being able to freeze/run threads at will comes in handy. Setting hardware breakpoints to see when particular memory locations are changing is also useful. Maybe you're just not using the debugger to its full potential?
- wingo 16y ago
  Cutlery and meat have nothing to do with debugging.
- axod 16y ago
  Proper logging > debugger. There is absolutely no point single stepping through code, setting up breakpoints, inspecting variables etc, when you could instead just insert an extra log statement to see what is going wrong. If your logging is good, often solving a bug is just a case of looking in a production log and seeing where things went wrong. The other fact is that the majority of bugs I've seen in my own code have been caused when under load, and it's not feasible to run a debugger on a production system. I've tried debuggers a fair amount, and they end up being completely useless to me.
  - jerf 16y ago
    "Proper logging > debugger." I assume that statement refers to the amount of noise in question? Sure, print statements are my normal tool, but often I'm working on transforming one data structure into another (compiler-style) and I'm encountering an error "somewhere" down in the middle. After the first few megabytes of logging output get generated, you start to really lose the thread of what's going on. It depends on what you're doing. If you're a CRUD programmer, yeah, I can see how they'd be useless; that's a good deal of my job too and I don't use them then. But when I'm actually doing something interesting and twisty I often need them, if only to set some conditional breakpoints somewhere so I can get into the middle of a complicated process instead of trying to reconstruct the state later. Also they are great for learning libraries by stepping through them.
  - maximilianburke 16y ago
    Logging changes the timing of code making it nearly useless for debugging problems of a concurrent nature. It also falls down when systems cannot afford the overhead of printing all trace data (see: video games), or when embedded platforms have no reasonable TTY to send log data to. A debugger is just a tool and to dismiss a tool as being pointless for all people is ridiculous. Being familiar with all the tools at your disposal as a software developer is never a bad thing.
    - axod 16y ago
      A great reason why you shouldn't use concurrency...
  - shortlived 16y ago
    I would say that logging is fine sometimes, perhaps most of the times but being able to hotswap new code, do a deep inspection of an object (and perhaps some further new evaluation of code that you hadn't previously thought of) comes in very very handy.
  - Retric 16y ago
    Not all developers work on the same sorts of problems in the same way with the same type of time pressure. Debugging helps you work with code you don't understand. So, the longer you work with the same code the less useful it becomes. However, plenty of coders move from project to project patch up a few problems and then move on.
- GrooveStomp 16y ago
  Debugging is just another tool. It's not the most valuable tool, but it's also not the least valuable. At work we rely heavily on logging and trace statements. There isn't even a functioning debugger for our UI language implementation. I'd say not having a debugger is more like programming on paper. When you have a problem, you might end up thinking about it a little more because you can't rely on that one other tool.
- roadnottaken 16y ago
  "Not using a debugger is like giving up a knife and using a spoon to eat your steak." I think it's more like never being taught how to use a knife, and thus eating the steak with your bare-hands, as you've always done. Hands work fine, why learn something new? I have no formal training in programming and it never really occurred to me to use a debugger. I still don't entirely understand what they do for you that you can't do by adding print/trace statements. That said I mostly use scripting languages and don't need to read too much code written by other people...
  - kenjackson 16y ago
    The debugger, after your brain, is probably the most powerful tool in your arsenal. They allow you to evaluate state and often see things you'd miss otherwise. Plus they can do what prints can do, but even easier. I can use tracepoints to print anything at any point in code, including the callstack. The nice thing though is I can turn the tracepoints on and off while never pausing/breaking the code. Additionally I can attach a debugger to a running process. Plus with more modern features, like historical debugging), I can go back to predefined instances of time (like a past exception that was thrown) and examine the callstack then. And the other thing you can do interactively is (a) change the value of variables, (b) change the code, and (c) change the instruction pointer. I regularly do (a) & (c) -- (b) less so. It's a huge time saver when you step over function foo() and realize, hey it didn't set ABC. So then just set the IP back to foo(), but this time step into it. When I would consult I would often find and fix bugs in a day or two with oode that I'd only seen for the first time, while others had been looking for weeks in code they had helped build. I'd look at their debugging techniques and it was obivous that they were often just not at all efficient.
anamax 16y ago
> What I tell others: I'm so good that I don't need a debugger. That sounds better than what I tell others, that I'm not smart enough to use a debugger. Debuggers let me get away with code that is on the edge of my understanding at the time that I'm writing it. The problem is that I'm not nearly as smart when I have to revisit that same code later. In addition, debugging with print requires more understanding, so it's more likely to be correct than debugging with a debugger. That said, I really liked my time in visual studio.
- vilya 16y ago
  "In addition, debugging with print requires more understanding, so it's more likely to be correct than debugging with a debugger." I don't believe this is true. I suspect the way most people use print statements for debugging goes something like: "I think the problem is somewhere in this function, let's stick a print statement here. Oops, that doesn't seem to be it, let's try one here. Oops, that's not it either, let's try printing out a different variable." and so on. That's remarkably similar to using a debugger only a lot less efficient, because you have to go back through the whole edit-compile-run cycle each time (or maybe edit-deploy-run if you're working on a web app using a scripting language).
  - anamax 16y ago
    > I don't believe this is true. I suspect the way most people use print statements for debugging goes something like: "I think the problem is somewhere in this function, let's stick a print statement here. Oops, that doesn't seem to be it, let's try one here. Oops, that's not it either, let's try printing out a different variable." and so on. What is the basis for your suspicion? I ask because the folks who I see using print as their first-choice for debugging don't work that way. The overhead associated with changes (as opposed to restarting) gives them the opportunity to think (or grab a new cup of tea). That said, that "poke around randomly" approach does seem to be "not rare" for folks who are "debugger first", as you yourself say. To be fair, the folks I know who are most effective with a debugger also put in some time on understanding before they fire it up.
syaz1 16y ago
What I tell people who tell me this: You're probably making a simple or sequential app. Debugger is more powerful, it can do everything print can, and more. Sure if it's a 5 minute walk to the market, then by all means, walk.

by edw519 16y ago

Vivtek 16y ago

Hahaha! This is exactly what I wanted to say!

mesmerized 16y ago

Not using a debugger is like giving up a knife and using a spoon to eat your steak. Yeah, you can do it, but why would you? Debuggers are invaluable when you encounter difficult bugs, especially ones related to threading issues. Being able to freeze/run threads at will comes in handy. Setting hardware breakpoints to see when particular memory locations are changing is also useful. Maybe you're just not using the debugger to its full potential?

wingo 16y ago
Cutlery and meat have nothing to do with debugging.
axod 16y ago
Proper logging > debugger. There is absolutely no point single stepping through code, setting up breakpoints, inspecting variables etc, when you could instead just insert an extra log statement to see what is going wrong. If your logging is good, often solving a bug is just a case of looking in a production log and seeing where things went wrong. The other fact is that the majority of bugs I've seen in my own code have been caused when under load, and it's not feasible to run a debugger on a production system. I've tried debuggers a fair amount, and they end up being completely useless to me.
- jerf 16y ago
  "Proper logging > debugger." I assume that statement refers to the amount of noise in question? Sure, print statements are my normal tool, but often I'm working on transforming one data structure into another (compiler-style) and I'm encountering an error "somewhere" down in the middle. After the first few megabytes of logging output get generated, you start to really lose the thread of what's going on. It depends on what you're doing. If you're a CRUD programmer, yeah, I can see how they'd be useless; that's a good deal of my job too and I don't use them then. But when I'm actually doing something interesting and twisty I often need them, if only to set some conditional breakpoints somewhere so I can get into the middle of a complicated process instead of trying to reconstruct the state later. Also they are great for learning libraries by stepping through them.
- maximilianburke 16y ago
  Logging changes the timing of code making it nearly useless for debugging problems of a concurrent nature. It also falls down when systems cannot afford the overhead of printing all trace data (see: video games), or when embedded platforms have no reasonable TTY to send log data to. A debugger is just a tool and to dismiss a tool as being pointless for all people is ridiculous. Being familiar with all the tools at your disposal as a software developer is never a bad thing.
  - axod 16y ago
    A great reason why you shouldn't use concurrency...
- shortlived 16y ago
  I would say that logging is fine sometimes, perhaps most of the times but being able to hotswap new code, do a deep inspection of an object (and perhaps some further new evaluation of code that you hadn't previously thought of) comes in very very handy.
- Retric 16y ago
  Not all developers work on the same sorts of problems in the same way with the same type of time pressure. Debugging helps you work with code you don't understand. So, the longer you work with the same code the less useful it becomes. However, plenty of coders move from project to project patch up a few problems and then move on.
GrooveStomp 16y ago
Debugging is just another tool. It's not the most valuable tool, but it's also not the least valuable. At work we rely heavily on logging and trace statements. There isn't even a functioning debugger for our UI language implementation. I'd say not having a debugger is more like programming on paper. When you have a problem, you might end up thinking about it a little more because you can't rely on that one other tool.
roadnottaken 16y ago
"Not using a debugger is like giving up a knife and using a spoon to eat your steak." I think it's more like never being taught how to use a knife, and thus eating the steak with your bare-hands, as you've always done. Hands work fine, why learn something new? I have no formal training in programming and it never really occurred to me to use a debugger. I still don't entirely understand what they do for you that you can't do by adding print/trace statements. That said I mostly use scripting languages and don't need to read too much code written by other people...
- kenjackson 16y ago
  The debugger, after your brain, is probably the most powerful tool in your arsenal. They allow you to evaluate state and often see things you'd miss otherwise. Plus they can do what prints can do, but even easier. I can use tracepoints to print anything at any point in code, including the callstack. The nice thing though is I can turn the tracepoints on and off while never pausing/breaking the code. Additionally I can attach a debugger to a running process. Plus with more modern features, like historical debugging), I can go back to predefined instances of time (like a past exception that was thrown) and examine the callstack then. And the other thing you can do interactively is (a) change the value of variables, (b) change the code, and (c) change the instruction pointer. I regularly do (a) & (c) -- (b) less so. It's a huge time saver when you step over function foo() and realize, hey it didn't set ABC. So then just set the IP back to foo(), but this time step into it. When I would consult I would often find and fix bugs in a day or two with oode that I'd only seen for the first time, while others had been looking for weeks in code they had helped build. I'd look at their debugging techniques and it was obivous that they were often just not at all efficient.

anamax 16y ago

> What I tell others: I'm so good that I don't need a debugger. That sounds better than what I tell others, that I'm not smart enough to use a debugger. Debuggers let me get away with code that is on the edge of my understanding at the time that I'm writing it. The problem is that I'm not nearly as smart when I have to revisit that same code later. In addition, debugging with print requires more understanding, so it's more likely to be correct than debugging with a debugger. That said, I really liked my time in visual studio.

vilya 16y ago
"In addition, debugging with print requires more understanding, so it's more likely to be correct than debugging with a debugger." I don't believe this is true. I suspect the way most people use print statements for debugging goes something like: "I think the problem is somewhere in this function, let's stick a print statement here. Oops, that doesn't seem to be it, let's try one here. Oops, that's not it either, let's try printing out a different variable." and so on. That's remarkably similar to using a debugger only a lot less efficient, because you have to go back through the whole edit-compile-run cycle each time (or maybe edit-deploy-run if you're working on a web app using a scripting language).
- anamax 16y ago
  > I don't believe this is true. I suspect the way most people use print statements for debugging goes something like: "I think the problem is somewhere in this function, let's stick a print statement here. Oops, that doesn't seem to be it, let's try one here. Oops, that's not it either, let's try printing out a different variable." and so on. What is the basis for your suspicion? I ask because the folks who I see using print as their first-choice for debugging don't work that way. The overhead associated with changes (as opposed to restarting) gives them the opportunity to think (or grab a new cup of tea). That said, that "poke around randomly" approach does seem to be "not rare" for folks who are "debugger first", as you yourself say. To be fair, the folks I know who are most effective with a debugger also put in some time on understanding before they fire it up.

syaz1 16y ago

What I tell people who tell me this: You're probably making a simple or sequential app. Debugger is more powerful, it can do everything print can, and more. Sure if it's a 5 minute walk to the market, then by all means, walk.