8 ms·

Why I use a debugger

28 points by federicoterzi 5y ago

colesantiago 5y ago
I thought using debuggers was standard practice in non trivial programs?
- mkdirp 5y ago
  You'd think. But I still see discussions in JavaScript and PHP related threads where people swear by adding `console.log`/`var_dump` statements to their code over using the debugger. I've seen quite a few threads on r/php where individuals introduce a newer, supposedly better, library that can be used instead of `var_dump`, and there's always the inevitable "why not use the debugger?" to which many reply "because it's hard to set up" or "var_dump is better" or something silly to that effect.
  - ehnto 5y ago
    Which is strange, because debugging in JS and PHP is almost trivial to setup. Perhaps less so in PHP, but for JS it's right there in the browser for client side code.
    - nicoburns 5y ago
      JS is super straightforward until you're transpiling from a newer version of JS or from TypeScript and debugging is supported via source maps (which tends to be most JavaScript codebases). At that point, the debugging experience is pretty hit and miss. When it works it's fantastic, but it doesn't always work.
    - bruce343434 5y ago
      For sure not trivial with php
      - ehnto 5y ago
        It is pretty easy to locally or remotely debug with xDebug, the docs are pretty straight forward. What makes it difficult I find is when you're trying to use it in weird VMs.
  - charcircuit 5y ago
    Logging has the benefit of not stopping your programs. On what I work on stopping the program is not feasible. It will block all of the clients trying to communicate with it and if you pause for too long the clients will disconnect and this may make the problem hard to reproduce. Additionally it can be difficult to attach a debugger on a remote machine compared to deploying a simple update which mechanisms already exist for doing.
    - mkdirp 5y ago
      Logging is not debugging/print statements. You also wouldn't generally be debugging a request from random clients. You'd generally be debugging in your local dev environment.
- meltedcapacitor 5y ago
  You probably were not born last time I fired a debugger. Those who can't code, debug. :-) Joke apart it's a style thing, tracing and thinking gets you a long way, though virtuoso debugger users can be productive too no doubt. It's a bit like GUI vs CLI.
  - qsort 5y ago
    In principle, yes, thinking is strictly better than simulating, and over-relying on a debugger can get you into the habit of not reasoning about your code. In practice, most software is a stack of abstractions and bugs can be caused by anything at any level of that pile, including libraries. The ability to quickly inspect the state at a given execution step is not a tool that can realistically be dispensed by just thinking hard about the code.
  - ehnto 5y ago
    I wrote without a debugger for most of the start of my career, but problem solving is about having the right information on hand, and for me a debugger lets me gather that information quicker, and it also lets me iterate faster. There's another great benefit to a debugger, and that is troubleshooting long-running code or hard to prime iterations. Like for example, debugging a checkout flow can be very cumbersome as you have to prime the state for every test. There are plenty of workarounds if you have to log your way through it, but wouldn't it just be easier to use a tool designed for the job?
  - lukas099 5y ago
    You are thinking while you debug. It just gives you more to think about.
- deleted 5y ago
  [deleted]
- foxfluff 5y ago
  It really depends on a lot of things. Debuggers can completely throw off timing, concealing the bug you're after. Debuggers may tell you that your program state is messed up (doh, sure), but not how you got there. Figuring out how you got there isn't necessarily any easier with a debugger than with generous logging. If anything, it can be much harder. Figuring out where exactly to break or which particular instance of a million dynamically allocated objects to watch, etc. is no easier with the debugger than it is reading the source code.. Single stepping sucks when you don't know where your things go haywire. You spend too long in the wrong part or speed right through the problematic part. So you gotta restart and do it all over again, rinse and repeat if there's a pile of abstractions between where you are and where the problem is. ($deity/printf() help you if you're looking at a task composed of tiny asynchronous events and any attempt at stepping forward in the code just throws you back into the guts of the async executor, ready to pop off a completely unrelated event from the queue.) If anything, I think debuggers are nice for simple, borderline trivial programs where everything fits on a screen and there's a handful of variables to keep track of. (These tend to be the programs I rarely need a debugger for though, and the debugger isn't necessarily any faster than a bunch of print statements). They're nice for getting stack traces or figuring out the contents of RAM and sometimes that's just what you need, but often that's just working your way backwards towards the real issue, without having a way to rewind time. rr might change a lot of that, if it's available for your platform..
  - Const-me 5y ago
    > Figuring out how you got there isn't necessarily any easier with a debugger than with generous logging. If anything, it can be much harder. Put a breakpoint early on startup, once hit put a data breakpoint on the part of the state which messed up, reproduce the bug, and there's very high chance debugger will take you to the code which broke the state. This will even happen if the code which breaks the state is a memory corruption bug in different thread, in the code written in another language, from a third-party DLL. > debuggers are nice for simple, borderline trivial programs where everything fits on a screen and there's a handful of variables to keep track of It's funny I think it's the opposite. When there's only a few variables, one can print/log the complete state pretty often. When the state takes a gigabyte of memory and changes often, similar amount of logging going to produce too many terabytes of logs to be useful. Debugging is interactive, you can inspect the complete state and find the most relevant pieces to watch.
- genericlogic 5y ago
  I have mentored a number of software developers from just starting their career to a decade+ long career. Nearly every time I open the debugger to help them work through an issue I get 'what is this? Why has no one ever told me about this?'. This is not a judgement, just an observation. I always assumed debuggers were just part of a tool set but it appears (in my experience) many individuals were never taught that it exists. I also do not claim its a magical tool that can solve all problems. There are plenty of times i do a "print 'i'm here' + var".
  - Timwi 5y ago
    I have the same experience, but with even far more basic things than a debugger, such as the Home/End keys on your keyboard, or the search/replace function. Nobody ever bothers to try and see what they do.
- simias 5y ago
  I hardly ever use them. I think it's mainly that I don't know how. I also generally dislike having to learn "context specific" tools, since you generally need different debuggers for different languages/environments/runtimes. I also do a lot of low level code (kernel/bootloader) where debuggers can be available but are often a lot harder to setup. Keep in mind that I also don't like IDEs and my coding setup is mostly vim + ctags + terminal. I really agree with the quote in TFA, when I write rust code a few judiciously placed dbg!() calls are generally all I need to identify the issue.
- School-Cotton 5y ago
  Depends on the language. Debugger support is extremely poor in Rust for example, so most people (in my anecdotal experience) just use print statements.
willcipriano 5y ago
On one of Gordon Ramsey's shows he had a chef who purported to be one of the best in the world. While cooking his scallops kept sticking to the pan, this makes them look bad and Gordon won't serve them looking like that. Gordon yelled something like "Why aren't you using the non-stick pans, it's right there in the name, non-stick". I hear his voice in my head at least once a month when one of the people I work with spends a week on a bug and never once whips out a debugger. It's right there in the name guys.
- enriquto 5y ago
  The name "debugger" does not reflect what it does. A debugger does never remove the bugs that you put in your programs.
  - willcipriano 5y ago
    If your IDE is anything like mine, you will have a little button with a bug on it. You don't click it, even out of desperation at any point in your career? I get really tired and demotivated working with people who are like that, you have to hand feed them everything. Come to think about it, using the debugger is probably the best indicator I've seen if you are a good programmer or not, I've never seen anyone bad at programming use one.
    - enriquto 5y ago
      My point is that the debugger may help you understand the bug, but does not remove it. A better name for the tool would be something like bugfinder, or steprunner. > You don't click it, even out of desperation at any point in your career? I think I've never used an IDE since the (good) times of borland C++. > I get really tired and demotivated working with people who are like that You would probably hate working with me then... sorry about that.
      - willcipriano 5y ago
        Whatever works for you man, but if you spend two plus weeks on a bug in a if statement that would've been obvious at a first glance with a debugger, I'm not going to feel like we are contributing at the same level. It's like we are tasked with digging a ditch together and you want to use a tea spoon instead of a shovel.
glandium 5y ago
There are cases where I use print debugging in Firefox because it's ironically often faster to rebuild and rerun than for gdb to load the debug info. Also for rust, it can be much more convenient to use the dbg! macro for pretty printing rather than dig in the mess of values in the debugger.
the-alt-one 5y ago
How quickly do you guys whip out the debugger when you encounter a bug? I often can figure it out by reading the code (I'm the quickest jump-to-source in the wild west!) quicker than I can from inserting print stmts or hooking up a debugger. I've also decided that I dislike having my IDE be my debugger, I prefer having an entirely separate UI for that. Maybe this is because I use Emacs and DAP mode and gdb is quite poor there, I'd rather use something like gdbgui.
- gjulianm 5y ago
  I only use the debugger when I'm really lost or when I'm suspecting compiler/inheritance/indirection shenanigans. Most of the time I try to add logging/tracing because those are reusable and can help me debug other issues later, and just the action of actively thinking where to put them and why often points me to the bug and the possible fix.
- morelisp 5y ago
  I suspect this will be controversial, but I read TPOP at a young age and I think it still summarizes my overall view. The quote from the article continues: Blind probing with a debugger is not likely to be productive. It is more helpful to use the debugger to discover the state of the program when it fails, then think about how the failure could have happened. Debuggers can be arcane and difficult programs, and especially for beginners may provide more confusion than help. If you ask the wrong question, they will probably give you an answer, but you may not know it's misleading. In the ~15 years since I read this I've seen dozens of colleagues try to use a debugger in place of thinking harder, and it never goes well. Sometimes, but much more rarely, I see someone use a debugger after thinking hard for a while. That usually goes excellently, and probably creates some unrealistic view of the tool's effectiveness because other programmers see the debugger and not the thinking. 99% of problems are solved during the "think harder" stage, and if I can't think my way out of some local problem I probably wrote too-complicated code anyway. (And if it's a non-local problem, the debugger may not help too much.) The goal of most IDEs seems to be first help with a debugger / executing code/tests, second help with writing code, and only thirdly help with reading code. The older I get, the more those priorities seem inverted to me.
sys_64738 5y ago
Classic interview question. Tell me about the time you used a debugger to solve a programming issue. Saying "I don't use a debugger" is like saying to a C programmer "I don't use pointers". Cut the interview short. Thank them for their time then escort to the exit.
- morelisp 5y ago
  Good analogy. Novice programmers overuse debuggers in the same way novice C programmers overuse pointers.
- mettamage 5y ago
  There are programmers that rarely need debuggers because they deeply think about the state of the program at every line of execution. I am not one of them but it is an amazing sight to see. And if they then use a debugger, they are in and out in a jiffy (usually).
  - rocgf 5y ago
    Allow me to doubt that this is possible on a regular basis. Anyone can get bouts of error-free code. It happens on a regular basis that I write dozens of lines of code and everything just works, without any debugging. However, it's not just the code you write, there are also bugs in code that someone wrote 5 years ago. Or a bug in a library that you have no idea about. A lot of times, these can be solved with a debugger and a few WTFs or with a week of trying to understand every line of code, it's states and the transition between those states. Let's be realistic here.
    - foxfluff 5y ago
      "Doesn't need debugger" isn't same as "error-free code." You can solve bugs by thinking about / reading code. I'd say that's the way I solve the vast majority of my bugs. Also "using a debugger" and "debugging" are not synonymous.
      - rocgf 5y ago
cool-RR 5y ago
I feel like many of the commenters here haven't experienced enough corporate environments. I love using a debugger for open-source projects I work on and web apps I used to do for clients, but when you're working for a big company it's usually difficult to impossible to attach a debugger. Almost all of them have such convoluted setups that you'd need to use remote debugging, which is difficult to configure. You can barely use your own IDE in some of the FAANGs. This was the catalyst that made me develop PySnooper.
- kotxig 5y ago
  The reason debuggers are often hard to use in these environments is because people who don't routinely use debuggers to do their job do not see the value of them, and so organizations do not prioritize your ability to do this. The tone of the comments here in general is sceptical of the use of debuggers and this is exactly why you can't use them in some FAANG's - it's not a popular belief even though to anyone who does use them routinely this is such a fundamental thing. I feel like I am so much more capable with the ability to use a debugger and to routinely use it by default during development. This is how vim users must feel explaining to all the sublime text and vscode users what they are missing out on. When you have it, it's a productivity superpower.
  - foxfluff 5y ago
    I use vim but I don't think it's a superpower and it's rare for me to need its advanced features. I doubt vim is giving me any edge over $other_editor, I just happen to find it ergonomic and a good fit for me. Maybe I don't use it well enough? Likewise, I don't feel debuggers are a superpower. It's rare for them to "save the day". It's just a tool that I sometimes go for. The last time I remember using a debugger was a few months ago to figure out a memory leak. hexdump would've worked just as well.
- School-Cotton 5y ago
  I worked for Facebook and Amazon and used a debugger at both places regularly, on several layers of the stack.
soyyo 5y ago
>>we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. This ignores the typical scenario where you are working in a business application that you've never seen most of the code, only the relevant parts of whatever tasks you have done in that program, and all of the sudden you are asked to solve a bug or make a change in some place that you didn't know even existed, the original developer is long gone, is not documented, and chances are that there are many great coding horrors. A debugger can be really helpful to uncover how that code works. Also it assumes that the only possible use of a debugger is set a breakpoint and then follow every next step until the end, but this is actually not the case. A debugger allows you set conditional breakpoints, skip whole sections of code, evaluate code using the actual context that the application had when it was stopped, make changes to variables while the program is being executed, it is a great tool to explore code and behavior. I respect that some people may not like them and don't want to use them, but I find pretty dumb the idea that not using them is superior and you are a worse programmer if you do.
mypastself 5y ago
In my experience, developers who don’t use a debugger belong to one of two groups: 1.) Older hacker types for whom it was previously unavailable or difficult to set up, so they learned to work (well) without it. 2.) Juniors/fresh grads, who often seem intimidated by it, likely because teachers and online resources didn’t emphasize it sufficiently. I think the first group would benefit from introducing a debugger into their work process, but for the second group it should be essential.
- cosmotic 5y ago
  In my experience, there are two intermediate group: 3.) Folks that are, for whatever reason, satisfied with log statements and can't be bothered to learn something new 4.) TDD die-hards where a debugger is evidence of a failure to follow the TDD manifesto I'm a huge proponent of debuggers but I've encountered Senior SWEs that are not old-hackers or just-out-of-college.
mule1 5y ago
Wait..... There are people who don't use debuggers that are readily available for compiled languages?
kotxig 5y ago
I am surprised to find in these comments that using the debugger routinely and by default isn't a popular idea. I couldn't do my job as well as I do without having the reflex to use the debugger. I shouldn't be surprised though, the last time I watched a coworker roll his face on the keyboard trying to debug something the conversation went something like: - Me: Just use the debugger... - Him: But it's hard and annoying to use the debugger - Me: It's hard and annoying not having the skills or reflex to use the debugger by default - Him: ... ok I agree ... continues rolling face on the keyboard and add print statements everywhere I think much of the sentiment in these comments is sounding like "that's not how I work so I will defend myself". Just learn how to use your debugger and integrate it into your work flow. You don't need a special IDE to use a debugger in most languages if that's the perceived problem.
- ahelwer 5y ago
  I’ve found corporate software environments anathema to learning. The daily standup will not reward “yesterday I learned how to use a debugger” or “yesterday I spent time reading documentation” but it does reward “yesterday I spent hours grinding out the root cause of a bug”. There are other reasons, of course - but fundamentally the messaging is to get it done with as little learning as possible. You should know it all already! Learning, it should also be said, is very very hard when you are burnt out. And most of the learning capacity is used up learning non-transferable knowledge about internal-only APIs and systems you will never use again. The solution is probably employer-funded sabbaticals but since those are rare people just settle for quitting and poking around at their own projects for a while. Now that I’m more of what you’d call a “senior” developer I realize the absolute importance of taking time to set up your development environment so compiling, debugging, unit tests, prototyping etc. are as seamless as possible - the benefits to productivity and general happiness are manifold! But having the clout to invest more “non-productive” time upfront so your overall productivity is much higher is not usually afforded to devs fresh out of school who tend to just grind it out.
- gjulianm 5y ago
  I don't use a debugger routinely and by default. First reflex is to add logging, telemetry or tests because those are useful when another issue pops in a similar place: instead of attaching a debugger (which might alter the program flow/timings), recreating the flow (which may or may not be easy) and setting breakpoints, I just read the data that I already have, which usually guides me (or other coworkers) in the debugging. For me, the debugger only comes out when those tools don't work quickly, I'm pretty lost or I'm inspecting the code flow of third party code.
mtVessel 5y ago
When I write code that has multiple, interrelated parts, before I ever run it I step through it in the debugger to verify that my logic is correct, I didn't make any off-by-one errors, library calls return what I expect, etc. I especially do this when the code has destructive side-effects (a file gets moved/deleted, a database get updated, whatever), so I can skip over any external actions I don't actually want to occur until I'm ready for a full test run. Everybody does this, right? Right???
- gjulianm 5y ago
  > I especially do this when the code has destructive side-effects (a file gets moved/deleted, a database get updated, whatever), so I can skip over any external actions I don't actually want to occur until I'm ready for a full test run. I always wrap these statements in a function/if-statement/similar thing that allows me to run the tool in "dry mode" so changes are not done but just logged. It's pretty useful because I can reuse that mode whenever I want without reattaching the debugger and stepping again through everything.
  - mtVessel 5y ago
    Yes, of course, that's the better approach. But you can quickly get bogged down in a ton of extra parameters/environment vars/config scripts/whatever depending on how granular you want that control to be. My laziness often precludes me from taking that approach until it's clear that it's warranted (but hopefully before I nuke anything critical).
- morelisp 5y ago
  No, if you use a debugger for this your test suite is too slow or otherwise too difficult to run.
georgewsinger 5y ago
I look forward to seeing the author write about Pernos.co, an extremely underrated debugging tool that basically changed my and my team's lives when fixing bad code.

28 points by federicoterzi 5y ago

colesantiago 5y ago

I thought using debuggers was standard practice in non trivial programs?

mkdirp 5y ago
You'd think. But I still see discussions in JavaScript and PHP related threads where people swear by adding `console.log`/`var_dump` statements to their code over using the debugger. I've seen quite a few threads on r/php where individuals introduce a newer, supposedly better, library that can be used instead of `var_dump`, and there's always the inevitable "why not use the debugger?" to which many reply "because it's hard to set up" or "var_dump is better" or something silly to that effect.
- ehnto 5y ago
  Which is strange, because debugging in JS and PHP is almost trivial to setup. Perhaps less so in PHP, but for JS it's right there in the browser for client side code.
  - nicoburns 5y ago
    JS is super straightforward until you're transpiling from a newer version of JS or from TypeScript and debugging is supported via source maps (which tends to be most JavaScript codebases). At that point, the debugging experience is pretty hit and miss. When it works it's fantastic, but it doesn't always work.
  - bruce343434 5y ago
    For sure not trivial with php
    - ehnto 5y ago
      It is pretty easy to locally or remotely debug with xDebug, the docs are pretty straight forward. What makes it difficult I find is when you're trying to use it in weird VMs.
- charcircuit 5y ago
  Logging has the benefit of not stopping your programs. On what I work on stopping the program is not feasible. It will block all of the clients trying to communicate with it and if you pause for too long the clients will disconnect and this may make the problem hard to reproduce. Additionally it can be difficult to attach a debugger on a remote machine compared to deploying a simple update which mechanisms already exist for doing.
  - mkdirp 5y ago
    Logging is not debugging/print statements. You also wouldn't generally be debugging a request from random clients. You'd generally be debugging in your local dev environment.
meltedcapacitor 5y ago
You probably were not born last time I fired a debugger. Those who can't code, debug. :-) Joke apart it's a style thing, tracing and thinking gets you a long way, though virtuoso debugger users can be productive too no doubt. It's a bit like GUI vs CLI.
- qsort 5y ago
  In principle, yes, thinking is strictly better than simulating, and over-relying on a debugger can get you into the habit of not reasoning about your code. In practice, most software is a stack of abstractions and bugs can be caused by anything at any level of that pile, including libraries. The ability to quickly inspect the state at a given execution step is not a tool that can realistically be dispensed by just thinking hard about the code.
- ehnto 5y ago
  I wrote without a debugger for most of the start of my career, but problem solving is about having the right information on hand, and for me a debugger lets me gather that information quicker, and it also lets me iterate faster. There's another great benefit to a debugger, and that is troubleshooting long-running code or hard to prime iterations. Like for example, debugging a checkout flow can be very cumbersome as you have to prime the state for every test. There are plenty of workarounds if you have to log your way through it, but wouldn't it just be easier to use a tool designed for the job?
- lukas099 5y ago
  You are thinking while you debug. It just gives you more to think about.
deleted 5y ago
[deleted]
foxfluff 5y ago
It really depends on a lot of things. Debuggers can completely throw off timing, concealing the bug you're after. Debuggers may tell you that your program state is messed up (doh, sure), but not how you got there. Figuring out how you got there isn't necessarily any easier with a debugger than with generous logging. If anything, it can be much harder. Figuring out where exactly to break or which particular instance of a million dynamically allocated objects to watch, etc. is no easier with the debugger than it is reading the source code.. Single stepping sucks when you don't know where your things go haywire. You spend too long in the wrong part or speed right through the problematic part. So you gotta restart and do it all over again, rinse and repeat if there's a pile of abstractions between where you are and where the problem is. ($deity/printf() help you if you're looking at a task composed of tiny asynchronous events and any attempt at stepping forward in the code just throws you back into the guts of the async executor, ready to pop off a completely unrelated event from the queue.) If anything, I think debuggers are nice for simple, borderline trivial programs where everything fits on a screen and there's a handful of variables to keep track of. (These tend to be the programs I rarely need a debugger for though, and the debugger isn't necessarily any faster than a bunch of print statements). They're nice for getting stack traces or figuring out the contents of RAM and sometimes that's just what you need, but often that's just working your way backwards towards the real issue, without having a way to rewind time. rr might change a lot of that, if it's available for your platform..
- Const-me 5y ago
  > Figuring out how you got there isn't necessarily any easier with a debugger than with generous logging. If anything, it can be much harder. Put a breakpoint early on startup, once hit put a data breakpoint on the part of the state which messed up, reproduce the bug, and there's very high chance debugger will take you to the code which broke the state. This will even happen if the code which breaks the state is a memory corruption bug in different thread, in the code written in another language, from a third-party DLL. > debuggers are nice for simple, borderline trivial programs where everything fits on a screen and there's a handful of variables to keep track of It's funny I think it's the opposite. When there's only a few variables, one can print/log the complete state pretty often. When the state takes a gigabyte of memory and changes often, similar amount of logging going to produce too many terabytes of logs to be useful. Debugging is interactive, you can inspect the complete state and find the most relevant pieces to watch.
genericlogic 5y ago
I have mentored a number of software developers from just starting their career to a decade+ long career. Nearly every time I open the debugger to help them work through an issue I get 'what is this? Why has no one ever told me about this?'. This is not a judgement, just an observation. I always assumed debuggers were just part of a tool set but it appears (in my experience) many individuals were never taught that it exists. I also do not claim its a magical tool that can solve all problems. There are plenty of times i do a "print 'i'm here' + var".
- Timwi 5y ago
  I have the same experience, but with even far more basic things than a debugger, such as the Home/End keys on your keyboard, or the search/replace function. Nobody ever bothers to try and see what they do.
simias 5y ago
I hardly ever use them. I think it's mainly that I don't know how. I also generally dislike having to learn "context specific" tools, since you generally need different debuggers for different languages/environments/runtimes. I also do a lot of low level code (kernel/bootloader) where debuggers can be available but are often a lot harder to setup. Keep in mind that I also don't like IDEs and my coding setup is mostly vim + ctags + terminal. I really agree with the quote in TFA, when I write rust code a few judiciously placed dbg!() calls are generally all I need to identify the issue.
School-Cotton 5y ago
Depends on the language. Debugger support is extremely poor in Rust for example, so most people (in my anecdotal experience) just use print statements.

willcipriano 5y ago

On one of Gordon Ramsey's shows he had a chef who purported to be one of the best in the world. While cooking his scallops kept sticking to the pan, this makes them look bad and Gordon won't serve them looking like that. Gordon yelled something like "Why aren't you using the non-stick pans, it's right there in the name, non-stick". I hear his voice in my head at least once a month when one of the people I work with spends a week on a bug and never once whips out a debugger. It's right there in the name guys.

enriquto 5y ago
The name "debugger" does not reflect what it does. A debugger does never remove the bugs that you put in your programs.
- willcipriano 5y ago
  If your IDE is anything like mine, you will have a little button with a bug on it. You don't click it, even out of desperation at any point in your career? I get really tired and demotivated working with people who are like that, you have to hand feed them everything. Come to think about it, using the debugger is probably the best indicator I've seen if you are a good programmer or not, I've never seen anyone bad at programming use one.
  - enriquto 5y ago
    My point is that the debugger may help you understand the bug, but does not remove it. A better name for the tool would be something like bugfinder, or steprunner. > You don't click it, even out of desperation at any point in your career? I think I've never used an IDE since the (good) times of borland C++. > I get really tired and demotivated working with people who are like that You would probably hate working with me then... sorry about that.
    - willcipriano 5y ago
      Whatever works for you man, but if you spend two plus weeks on a bug in a if statement that would've been obvious at a first glance with a debugger, I'm not going to feel like we are contributing at the same level. It's like we are tasked with digging a ditch together and you want to use a tea spoon instead of a shovel.

glandium 5y ago

There are cases where I use print debugging in Firefox because it's ironically often faster to rebuild and rerun than for gdb to load the debug info. Also for rust, it can be much more convenient to use the dbg! macro for pretty printing rather than dig in the mess of values in the debugger.

the-alt-one 5y ago

How quickly do you guys whip out the debugger when you encounter a bug? I often can figure it out by reading the code (I'm the quickest jump-to-source in the wild west!) quicker than I can from inserting print stmts or hooking up a debugger. I've also decided that I dislike having my IDE be my debugger, I prefer having an entirely separate UI for that. Maybe this is because I use Emacs and DAP mode and gdb is quite poor there, I'd rather use something like gdbgui.

gjulianm 5y ago
I only use the debugger when I'm really lost or when I'm suspecting compiler/inheritance/indirection shenanigans. Most of the time I try to add logging/tracing because those are reusable and can help me debug other issues later, and just the action of actively thinking where to put them and why often points me to the bug and the possible fix.
morelisp 5y ago
I suspect this will be controversial, but I read TPOP at a young age and I think it still summarizes my overall view. The quote from the article continues: Blind probing with a debugger is not likely to be productive. It is more helpful to use the debugger to discover the state of the program when it fails, then think about how the failure could have happened. Debuggers can be arcane and difficult programs, and especially for beginners may provide more confusion than help. If you ask the wrong question, they will probably give you an answer, but you may not know it's misleading. In the ~15 years since I read this I've seen dozens of colleagues try to use a debugger in place of thinking harder, and it never goes well. Sometimes, but much more rarely, I see someone use a debugger after thinking hard for a while. That usually goes excellently, and probably creates some unrealistic view of the tool's effectiveness because other programmers see the debugger and not the thinking. 99% of problems are solved during the "think harder" stage, and if I can't think my way out of some local problem I probably wrote too-complicated code anyway. (And if it's a non-local problem, the debugger may not help too much.) The goal of most IDEs seems to be first help with a debugger / executing code/tests, second help with writing code, and only thirdly help with reading code. The older I get, the more those priorities seem inverted to me.

sys_64738 5y ago

Classic interview question. Tell me about the time you used a debugger to solve a programming issue. Saying "I don't use a debugger" is like saying to a C programmer "I don't use pointers". Cut the interview short. Thank them for their time then escort to the exit.

morelisp 5y ago
Good analogy. Novice programmers overuse debuggers in the same way novice C programmers overuse pointers.
mettamage 5y ago
There are programmers that rarely need debuggers because they deeply think about the state of the program at every line of execution. I am not one of them but it is an amazing sight to see. And if they then use a debugger, they are in and out in a jiffy (usually).
- rocgf 5y ago
  Allow me to doubt that this is possible on a regular basis. Anyone can get bouts of error-free code. It happens on a regular basis that I write dozens of lines of code and everything just works, without any debugging. However, it's not just the code you write, there are also bugs in code that someone wrote 5 years ago. Or a bug in a library that you have no idea about. A lot of times, these can be solved with a debugger and a few WTFs or with a week of trying to understand every line of code, it's states and the transition between those states. Let's be realistic here.
  - foxfluff 5y ago
    "Doesn't need debugger" isn't same as "error-free code." You can solve bugs by thinking about / reading code. I'd say that's the way I solve the vast majority of my bugs. Also "using a debugger" and "debugging" are not synonymous.
    - rocgf 5y ago

cool-RR 5y ago

I feel like many of the commenters here haven't experienced enough corporate environments. I love using a debugger for open-source projects I work on and web apps I used to do for clients, but when you're working for a big company it's usually difficult to impossible to attach a debugger. Almost all of them have such convoluted setups that you'd need to use remote debugging, which is difficult to configure. You can barely use your own IDE in some of the FAANGs. This was the catalyst that made me develop PySnooper.

kotxig 5y ago
The reason debuggers are often hard to use in these environments is because people who don't routinely use debuggers to do their job do not see the value of them, and so organizations do not prioritize your ability to do this. The tone of the comments here in general is sceptical of the use of debuggers and this is exactly why you can't use them in some FAANG's - it's not a popular belief even though to anyone who does use them routinely this is such a fundamental thing. I feel like I am so much more capable with the ability to use a debugger and to routinely use it by default during development. This is how vim users must feel explaining to all the sublime text and vscode users what they are missing out on. When you have it, it's a productivity superpower.
- foxfluff 5y ago
  I use vim but I don't think it's a superpower and it's rare for me to need its advanced features. I doubt vim is giving me any edge over $other_editor, I just happen to find it ergonomic and a good fit for me. Maybe I don't use it well enough? Likewise, I don't feel debuggers are a superpower. It's rare for them to "save the day". It's just a tool that I sometimes go for. The last time I remember using a debugger was a few months ago to figure out a memory leak. hexdump would've worked just as well.
School-Cotton 5y ago
I worked for Facebook and Amazon and used a debugger at both places regularly, on several layers of the stack.

soyyo 5y ago

>>we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. This ignores the typical scenario where you are working in a business application that you've never seen most of the code, only the relevant parts of whatever tasks you have done in that program, and all of the sudden you are asked to solve a bug or make a change in some place that you didn't know even existed, the original developer is long gone, is not documented, and chances are that there are many great coding horrors. A debugger can be really helpful to uncover how that code works. Also it assumes that the only possible use of a debugger is set a breakpoint and then follow every next step until the end, but this is actually not the case. A debugger allows you set conditional breakpoints, skip whole sections of code, evaluate code using the actual context that the application had when it was stopped, make changes to variables while the program is being executed, it is a great tool to explore code and behavior. I respect that some people may not like them and don't want to use them, but I find pretty dumb the idea that not using them is superior and you are a worse programmer if you do.

mypastself 5y ago

In my experience, developers who don’t use a debugger belong to one of two groups: 1.) Older hacker types for whom it was previously unavailable or difficult to set up, so they learned to work (well) without it. 2.) Juniors/fresh grads, who often seem intimidated by it, likely because teachers and online resources didn’t emphasize it sufficiently. I think the first group would benefit from introducing a debugger into their work process, but for the second group it should be essential.

cosmotic 5y ago
In my experience, there are two intermediate group: 3.) Folks that are, for whatever reason, satisfied with log statements and can't be bothered to learn something new 4.) TDD die-hards where a debugger is evidence of a failure to follow the TDD manifesto I'm a huge proponent of debuggers but I've encountered Senior SWEs that are not old-hackers or just-out-of-college.

mule1 5y ago

Wait..... There are people who don't use debuggers that are readily available for compiled languages?

kotxig 5y ago

I am surprised to find in these comments that using the debugger routinely and by default isn't a popular idea. I couldn't do my job as well as I do without having the reflex to use the debugger. I shouldn't be surprised though, the last time I watched a coworker roll his face on the keyboard trying to debug something the conversation went something like: - Me: Just use the debugger... - Him: But it's hard and annoying to use the debugger - Me: It's hard and annoying not having the skills or reflex to use the debugger by default - Him: ... ok I agree ... continues rolling face on the keyboard and add print statements everywhere I think much of the sentiment in these comments is sounding like "that's not how I work so I will defend myself". Just learn how to use your debugger and integrate it into your work flow. You don't need a special IDE to use a debugger in most languages if that's the perceived problem.

ahelwer 5y ago
I’ve found corporate software environments anathema to learning. The daily standup will not reward “yesterday I learned how to use a debugger” or “yesterday I spent time reading documentation” but it does reward “yesterday I spent hours grinding out the root cause of a bug”. There are other reasons, of course - but fundamentally the messaging is to get it done with as little learning as possible. You should know it all already! Learning, it should also be said, is very very hard when you are burnt out. And most of the learning capacity is used up learning non-transferable knowledge about internal-only APIs and systems you will never use again. The solution is probably employer-funded sabbaticals but since those are rare people just settle for quitting and poking around at their own projects for a while. Now that I’m more of what you’d call a “senior” developer I realize the absolute importance of taking time to set up your development environment so compiling, debugging, unit tests, prototyping etc. are as seamless as possible - the benefits to productivity and general happiness are manifold! But having the clout to invest more “non-productive” time upfront so your overall productivity is much higher is not usually afforded to devs fresh out of school who tend to just grind it out.
gjulianm 5y ago
I don't use a debugger routinely and by default. First reflex is to add logging, telemetry or tests because those are useful when another issue pops in a similar place: instead of attaching a debugger (which might alter the program flow/timings), recreating the flow (which may or may not be easy) and setting breakpoints, I just read the data that I already have, which usually guides me (or other coworkers) in the debugging. For me, the debugger only comes out when those tools don't work quickly, I'm pretty lost or I'm inspecting the code flow of third party code.

mtVessel 5y ago

When I write code that has multiple, interrelated parts, before I ever run it I step through it in the debugger to verify that my logic is correct, I didn't make any off-by-one errors, library calls return what I expect, etc. I especially do this when the code has destructive side-effects (a file gets moved/deleted, a database get updated, whatever), so I can skip over any external actions I don't actually want to occur until I'm ready for a full test run. Everybody does this, right? Right???

gjulianm 5y ago
> I especially do this when the code has destructive side-effects (a file gets moved/deleted, a database get updated, whatever), so I can skip over any external actions I don't actually want to occur until I'm ready for a full test run. I always wrap these statements in a function/if-statement/similar thing that allows me to run the tool in "dry mode" so changes are not done but just logged. It's pretty useful because I can reuse that mode whenever I want without reattaching the debugger and stepping again through everything.
- mtVessel 5y ago
  Yes, of course, that's the better approach. But you can quickly get bogged down in a ton of extra parameters/environment vars/config scripts/whatever depending on how granular you want that control to be. My laziness often precludes me from taking that approach until it's clear that it's warranted (but hopefully before I nuke anything critical).
morelisp 5y ago
No, if you use a debugger for this your test suite is too slow or otherwise too difficult to run.

georgewsinger 5y ago

I look forward to seeing the author write about Pernos.co, an extremely underrated debugging tool that basically changed my and my team's lives when fixing bad code.