10 ms·

I sat with a talented developer whilst we wrestled with a threading issue this past week. I wanted to inspect the value of a variable within a method during exe

I sat with a talented developer whilst we wrestled with a threading issue this past week. I wanted to inspect the value of a variable within a method during execution and asked him to set a breakpoint. He didn't know how to do that in the IDE, which he'd been using for over a year. Debugging is indeed a skill which needs learning.

theonething 4y ago
A talented developer who doesn't know how to set a breakpoint sounds contradictory to me.
- alfiedotwtf 4y ago
  I read a long time ago, that either Kernighan or Ritchie said they never use a debugger and just sprinkle printf() statements.
  - sfpotter 4y ago
    Concluding that using printf to debug is superior to using a debugger would be a mistake! I’ve been programming in C for nearly 20 years and primarily used printf for debugging for the first 12-15 years, and have used debuggers more and more. I use Emacs, and its gud mode is so nicely integrated into everything that using gdb is truly much, much faster than the alternative. I don’t use print debugging at all anymore. It takes less time and cognitive overhead to just stop the program on the same line you would have inserted your printf, but you can now inspect the entire program state. Obviously I’m not saying anything revelatory if you use an IDE on a regular basis… I guess this comment is for the folks who eschew IDEs.
  - wojciii 4y ago
    This works well mostly and I use this. I usually implement a logging system where I can enable/disable individual components but use a debugger to examine functions which are not behaving as intended.. or core dumps. Usually in connection with an unit test that fails or started failing caused by my changes to the codebase that I'm working on. Logging alone is fine, but it can often be difficult not to drown in information. I do embedded programming in C mostly.
- agumonkey 4y ago
  Maybe rare but you may be very skilled at understanding structure and finding solution but knowing nothing about tools. As long as you're either one of them.
- Transfinity 4y ago
  Hi! I'm that person! Senior engineer, decade of experience. I've used debuggers in the past, both for running code and looking at core dumps, but I really don't find them to be cost effective for the vast majority of problems. Just write a print statement! So when I switched from C to python and go a couple jobs ago, I never bothered learning how to use the debuggers for those languages. I don't miss them.
  - wiseowise 4y ago
    What makes you talented?
  - theonething 4y ago
    > I never bothered learning how to use the debuggers for those languages. I don't miss them. This could be causal.
    - thaumasiotes 4y ago
      You'd have to assume that the python and go debuggers do something that C debuggers don't do.
      - actionfromafar 4y ago
        Or assume that python debuggers aren't as nice to use, or that python does not lend itself to inspecting weird memory and pointer dereferences, or a bunch of other possibilities.
  - arghnoname 4y ago
    I am also this person. I'm a systems programmer (kernel and systems software, often in C, C++, golang, bit of rust, etc) What I find is that if my code isn't working, I stop what I'm doing. I look at it. I think really hard, I add some print statements and asserts to verify some assumptions, and I iterate a small handful of times to find my faulty assumption and fix it. Many, many times during the 'think hard' and look at the code part, I can fix the bug without any iterations. This almost always works if I really understand what I'm doing and I'm being thoughtful. Sometimes though, I don't know what the hell is going on and I'm in deep waters. In those cases I might use a debugger, but I often feel like I've failed. I almost never use them. When I helped undergrads with debuggers it often felt like their time would be more productively spent reasoning about their code instead of watching it.
- kernal 4y ago
  True. A talented developer abuses the hell out of breakpoints by using hit counts, conditions and trigger points.
- crispinb 4y ago
  As an untalented developer, I used to make heavy use of debuggers, and knew them well. Currently, as a still untalented developer, I've fallen out of the habit of using them and don't know how to for my current toolchain. Neither situation was at all related to my talent (or lack thereof).
- noisenotsignal 4y ago
  You don’t need breakpoints all the time though. If you’re familiar with the code (or just “talented”), you might have an intuition for what the problem is and it’s faster to just think through it (and maybe write a few quick prints) instead of interrupting your train of thought setting breakpoints, clicking continue, waiting for the IDE to freaking load the debugging session (cough Visual Studio), rerunning the test, etc. Besides, every IDE has a different way to debug, so they might just not be familiar with the interface. I can’t tell you exactly how to debug in VSCode even though I’ve used it the most. I’ve had to run a debugger only a handful of times in the past couple of years and it’s always for codebases that are more tangled (e.g. .NET where there’s interfaces everywhere).
  - 8n4vidtmkvmk 4y ago
    +1. i just used a debugger today at my work for the first time in 4 years by coincidence. normally i just throw a couple prints and rerun the test and today i was reminded why. takes like 8 minutes to run the test in debug mode. lots of useful info in there but usually i can guess where the error is without it. it was indeed good at pinpointing the sigsegv though.
- noelwelsh 4y ago
  There is a world of programming where debuggers don't serve much purpose. Individual microservices are usually trivial, but push complexity into the interactions between services. Debuggers are not much use there; distributed tracing is more relevant. Functional programming, which is a growing part of the industry, really emphasizes code you can easily reason about. That's arguably the whole point of functional programming. Debuggers don't get much use there either.
  - Eji1700 4y ago
    I'm not a talented developer but I did spend my day on an F# piece of code that builds a databale based on a record type using reflection (and eventually realized it was going to need to be recursive) and I probably would've just quit if I wasn't allowed to use a debugger. Now maybe if I was better that wouldn't be the case, but even the cleanest "wish i thought of that" functional code i've seen still looks like it'd be easier to fail fast using a debugger with. In fairness though, I will admit I use the debugger a lot less when i'm not screwing with reflection on generic types or whatever because runtime errors just happen a lot less in functional styles. Usually if it compiles, it runs, because the compiler can sanity check the code better than you can.
    - tokinonagare 4y ago
      > I'm not a talented developer > [uses F#] That has to be humblebragging. The average .net developer is terrified of or doesn't even know about F#.
      - Eji1700 4y ago
        It's really not. I'm quite terrible from any industry perspective. F# isn't hard, it's just different. Hell in many ways i'd argue it's much much easier once you get used to it. It doesn't have the support C# does so often you're stuck with a library that WILL work but doesn't have documentation for doing it in F#, and that can lead to struggles, but that's not really a sign of being a good coder. Most dotnet developers could probably code circles around me in F# if they knew it existed/gave it a chance. Personally I stuck with it because it had the low code look of python with strong typing. It took a bit to wrap my head around some functional stuff (basically map/iter = foreach and if you want to update something on each loop you probably want a fold, or more likely a built in function), but once I got over that hurdle it was pretty smooth sailing. The irony is that by far the hardest part is the library thing, which your average dotnet dev would handle WAAAAY better than me.
- ordu 4y ago
  I didn't use debuggers since switched from C to Rust. By the way I switched from emacs to VSCode and I do not know how to debug here. I never used debugger with lisp. Debugging is a language dependent technique.
  - tmtvl 4y ago
    I like debugging Lisp because the debugger is built in. A break here, an invoke-debugger there and the REPL takes me where I want to be.
- fooker 4y ago
  There are large categories of software engineering where debuggers are not used that much. I work on compilers and debuggers are more of an hindrance than help when trying to fix a compiler bug. I believe there is a similar situation for distributed systems.
- tkiolp4 4y ago
  Meh. I use the right tool for the job, and most of the time, a simple print statement put in the right place beats any debugger. Certainly the debugger has helped me in the past, but maybe one or two times only. Besides, putting a print statement costs nothing, and one knows exactly how to do so. Debuggers vary wildly: terminal, IDEs, etc.
- imetatroll 4y ago
  I don't usually use breakpoints in part because I use neovim and in part because... I seldom truly need them. Who are these people and what are these problems where stepping through method calls etc is actually necessary? I find it hard to believe. I've been successfully programming and problem solving this way for over 15 years.
- sidlls 4y ago
  I haven’t been shocked that fellow engineers don’t know how to use a debugger for at least ten years. Most jobs in the industry can be done adequately without getting into tools that low level.
marginalia_nu 4y ago
How would a breakpoint help with debugging a concurrency issue?
jbverschoor 4y ago
Well. a big part is curiosity, and apparently he isn’t curious not interested in what his tools do. I used to read every help file on windows / visual c++, the FreeBSD manual, plowed through the file system and tested this it. Just because I was curious
- deleted 4y ago
  [deleted]
- tkiolp4 4y ago
  There’s limited time. One cannot vey curious about all the stuff related to programming, so we must be selective.
  - jbverschoor 4y ago
    Sure.. that’s the story of the lumberjack with a blunt axe.
    - Jensson 4y ago
      Nah, debuggers are useful but hardly necessary to do your job well. People have been productive at programming long before they had many useful tools at all, the most important thing will always be how well you understand the program you are writing and not how you use your tools.
bmitc 4y ago
It's interesting. I mainly use functional-first languages, and I rarely need breakpoints. Programming is much more compositional with certain languages.
fsociety 4y ago
I agree you should know how to use a debugger, however will also note that some companies mandate use of a specific IDE (or heavily encourage). I have seen devs scoff at the thought of print debugging, but I recall that in systems programming there are many times you can’t use a debugger or need to rely on other tool. I’d rather schools teach the concept of step debugging vs runtime debugging. Teach students to try to understand the code, make hypotheses, and verify them. I have seen some people use a debugger solely because they only know how to step debug. Meaning they start from main or another entry point and step through every line of code. My point being that, you can’t judge a developer by if they use print statements or a debugger. Judge them by the methodology of how they debug.
- solatic 4y ago
  > I have seen devs scoff at the thought of print debugging, but I recall that in systems programming there are many times you can’t use a debugger or need to rely on other tool. Not just systems programming, but fixing issues in scaled production systems as well. Have fun attaching a debugger to the process that got killed twenty minutes ago when the spot instance it was running on got reclaimed. If you don't collect telemetry, you're blind. Debuggers are a luxury that you get to enjoy for issues you have before you ship.
- ModernMech 4y ago
  > I have seen devs scoff at the thought of print debugging Next time they do, ask them to recommend a better method of debugging that works across generally all languages, compilers, IDEs, and platforms with next to zero configuration.
  - a_e_k 4y ago
    The key thing about print debugging for me, that I've never seen a typical debugger handle well, is what I like to think of as "temporal debugging": Taking a program trace from the print debug statements, grepping through it repeatedly to filter down to certain events of interest, looking at the interleaving of those events, and figuring out the order that things happened in to cause it to go off the rails. That sort of thing. (To be fair, time-travel debuggers can start to get at this, but those are pretty uncommon. Traces, as you say, work almost everywhere.) Or better yet, compare the traces between working and non-working runs to see how they differ. I've looked at diffs of traces this way before. (Sometimes I'll first use a small script to renumber pointers in traces by order of appearance.) I've also used this sort of strategy before for debugging rare threading or other non-deterministic issues. Have the shell run the program in a loop, saving each run's trace and results to a different file, go off and get lunch, come back and see if anything failed. Then look to see if any of the runs failed and look for the structural differences between the working and non-working traces. I can't imagine sitting and stepping through in a debugger 100+ times in the hopes that maybe this time, it will be the run that's just different enough to trigger the bug and that the debugger itself won't prevent the issue from manifesting. Not to mention, trying to remember the steps from all the good runs and spotting where the bad run goes bad before you've stepped to far. No thank you. I think people really underestimate print debugging. Debuggers are fast and easy for simple bugs, sure, but there's powerful stuff that you can only really do with printed traces.
roflyear 4y ago
I learned this stuff without having people show me.

theonething 4y ago

A talented developer who doesn't know how to set a breakpoint sounds contradictory to me.

alfiedotwtf 4y ago
I read a long time ago, that either Kernighan or Ritchie said they never use a debugger and just sprinkle printf() statements.
- sfpotter 4y ago
  Concluding that using printf to debug is superior to using a debugger would be a mistake! I’ve been programming in C for nearly 20 years and primarily used printf for debugging for the first 12-15 years, and have used debuggers more and more. I use Emacs, and its gud mode is so nicely integrated into everything that using gdb is truly much, much faster than the alternative. I don’t use print debugging at all anymore. It takes less time and cognitive overhead to just stop the program on the same line you would have inserted your printf, but you can now inspect the entire program state. Obviously I’m not saying anything revelatory if you use an IDE on a regular basis… I guess this comment is for the folks who eschew IDEs.
- wojciii 4y ago
  This works well mostly and I use this. I usually implement a logging system where I can enable/disable individual components but use a debugger to examine functions which are not behaving as intended.. or core dumps. Usually in connection with an unit test that fails or started failing caused by my changes to the codebase that I'm working on. Logging alone is fine, but it can often be difficult not to drown in information. I do embedded programming in C mostly.
agumonkey 4y ago
Maybe rare but you may be very skilled at understanding structure and finding solution but knowing nothing about tools. As long as you're either one of them.
Transfinity 4y ago
Hi! I'm that person! Senior engineer, decade of experience. I've used debuggers in the past, both for running code and looking at core dumps, but I really don't find them to be cost effective for the vast majority of problems. Just write a print statement! So when I switched from C to python and go a couple jobs ago, I never bothered learning how to use the debuggers for those languages. I don't miss them.
- wiseowise 4y ago
  What makes you talented?
- theonething 4y ago
  > I never bothered learning how to use the debuggers for those languages. I don't miss them. This could be causal.
  - thaumasiotes 4y ago
    You'd have to assume that the python and go debuggers do something that C debuggers don't do.
    - actionfromafar 4y ago
      Or assume that python debuggers aren't as nice to use, or that python does not lend itself to inspecting weird memory and pointer dereferences, or a bunch of other possibilities.
- arghnoname 4y ago
  I am also this person. I'm a systems programmer (kernel and systems software, often in C, C++, golang, bit of rust, etc) What I find is that if my code isn't working, I stop what I'm doing. I look at it. I think really hard, I add some print statements and asserts to verify some assumptions, and I iterate a small handful of times to find my faulty assumption and fix it. Many, many times during the 'think hard' and look at the code part, I can fix the bug without any iterations. This almost always works if I really understand what I'm doing and I'm being thoughtful. Sometimes though, I don't know what the hell is going on and I'm in deep waters. In those cases I might use a debugger, but I often feel like I've failed. I almost never use them. When I helped undergrads with debuggers it often felt like their time would be more productively spent reasoning about their code instead of watching it.
kernal 4y ago
True. A talented developer abuses the hell out of breakpoints by using hit counts, conditions and trigger points.
crispinb 4y ago
As an untalented developer, I used to make heavy use of debuggers, and knew them well. Currently, as a still untalented developer, I've fallen out of the habit of using them and don't know how to for my current toolchain. Neither situation was at all related to my talent (or lack thereof).
noisenotsignal 4y ago
You don’t need breakpoints all the time though. If you’re familiar with the code (or just “talented”), you might have an intuition for what the problem is and it’s faster to just think through it (and maybe write a few quick prints) instead of interrupting your train of thought setting breakpoints, clicking continue, waiting for the IDE to freaking load the debugging session (cough Visual Studio), rerunning the test, etc. Besides, every IDE has a different way to debug, so they might just not be familiar with the interface. I can’t tell you exactly how to debug in VSCode even though I’ve used it the most. I’ve had to run a debugger only a handful of times in the past couple of years and it’s always for codebases that are more tangled (e.g. .NET where there’s interfaces everywhere).
- 8n4vidtmkvmk 4y ago
  +1. i just used a debugger today at my work for the first time in 4 years by coincidence. normally i just throw a couple prints and rerun the test and today i was reminded why. takes like 8 minutes to run the test in debug mode. lots of useful info in there but usually i can guess where the error is without it. it was indeed good at pinpointing the sigsegv though.
noelwelsh 4y ago
There is a world of programming where debuggers don't serve much purpose. Individual microservices are usually trivial, but push complexity into the interactions between services. Debuggers are not much use there; distributed tracing is more relevant. Functional programming, which is a growing part of the industry, really emphasizes code you can easily reason about. That's arguably the whole point of functional programming. Debuggers don't get much use there either.
- Eji1700 4y ago
  I'm not a talented developer but I did spend my day on an F# piece of code that builds a databale based on a record type using reflection (and eventually realized it was going to need to be recursive) and I probably would've just quit if I wasn't allowed to use a debugger. Now maybe if I was better that wouldn't be the case, but even the cleanest "wish i thought of that" functional code i've seen still looks like it'd be easier to fail fast using a debugger with. In fairness though, I will admit I use the debugger a lot less when i'm not screwing with reflection on generic types or whatever because runtime errors just happen a lot less in functional styles. Usually if it compiles, it runs, because the compiler can sanity check the code better than you can.
  - tokinonagare 4y ago
    > I'm not a talented developer > [uses F#] That has to be humblebragging. The average .net developer is terrified of or doesn't even know about F#.
    - Eji1700 4y ago
      It's really not. I'm quite terrible from any industry perspective. F# isn't hard, it's just different. Hell in many ways i'd argue it's much much easier once you get used to it. It doesn't have the support C# does so often you're stuck with a library that WILL work but doesn't have documentation for doing it in F#, and that can lead to struggles, but that's not really a sign of being a good coder. Most dotnet developers could probably code circles around me in F# if they knew it existed/gave it a chance. Personally I stuck with it because it had the low code look of python with strong typing. It took a bit to wrap my head around some functional stuff (basically map/iter = foreach and if you want to update something on each loop you probably want a fold, or more likely a built in function), but once I got over that hurdle it was pretty smooth sailing. The irony is that by far the hardest part is the library thing, which your average dotnet dev would handle WAAAAY better than me.
ordu 4y ago
I didn't use debuggers since switched from C to Rust. By the way I switched from emacs to VSCode and I do not know how to debug here. I never used debugger with lisp. Debugging is a language dependent technique.
- tmtvl 4y ago
  I like debugging Lisp because the debugger is built in. A break here, an invoke-debugger there and the REPL takes me where I want to be.
fooker 4y ago
There are large categories of software engineering where debuggers are not used that much. I work on compilers and debuggers are more of an hindrance than help when trying to fix a compiler bug. I believe there is a similar situation for distributed systems.
tkiolp4 4y ago
Meh. I use the right tool for the job, and most of the time, a simple print statement put in the right place beats any debugger. Certainly the debugger has helped me in the past, but maybe one or two times only. Besides, putting a print statement costs nothing, and one knows exactly how to do so. Debuggers vary wildly: terminal, IDEs, etc.
imetatroll 4y ago
I don't usually use breakpoints in part because I use neovim and in part because... I seldom truly need them. Who are these people and what are these problems where stepping through method calls etc is actually necessary? I find it hard to believe. I've been successfully programming and problem solving this way for over 15 years.
sidlls 4y ago
I haven’t been shocked that fellow engineers don’t know how to use a debugger for at least ten years. Most jobs in the industry can be done adequately without getting into tools that low level.

marginalia_nu 4y ago

How would a breakpoint help with debugging a concurrency issue?

jbverschoor 4y ago

Well. a big part is curiosity, and apparently he isn’t curious not interested in what his tools do. I used to read every help file on windows / visual c++, the FreeBSD manual, plowed through the file system and tested this it. Just because I was curious

deleted 4y ago
[deleted]
tkiolp4 4y ago
There’s limited time. One cannot vey curious about all the stuff related to programming, so we must be selective.
- jbverschoor 4y ago
  Sure.. that’s the story of the lumberjack with a blunt axe.
  - Jensson 4y ago
    Nah, debuggers are useful but hardly necessary to do your job well. People have been productive at programming long before they had many useful tools at all, the most important thing will always be how well you understand the program you are writing and not how you use your tools.

bmitc 4y ago

It's interesting. I mainly use functional-first languages, and I rarely need breakpoints. Programming is much more compositional with certain languages.

fsociety 4y ago

I agree you should know how to use a debugger, however will also note that some companies mandate use of a specific IDE (or heavily encourage). I have seen devs scoff at the thought of print debugging, but I recall that in systems programming there are many times you can’t use a debugger or need to rely on other tool. I’d rather schools teach the concept of step debugging vs runtime debugging. Teach students to try to understand the code, make hypotheses, and verify them. I have seen some people use a debugger solely because they only know how to step debug. Meaning they start from main or another entry point and step through every line of code. My point being that, you can’t judge a developer by if they use print statements or a debugger. Judge them by the methodology of how they debug.

solatic 4y ago
> I have seen devs scoff at the thought of print debugging, but I recall that in systems programming there are many times you can’t use a debugger or need to rely on other tool. Not just systems programming, but fixing issues in scaled production systems as well. Have fun attaching a debugger to the process that got killed twenty minutes ago when the spot instance it was running on got reclaimed. If you don't collect telemetry, you're blind. Debuggers are a luxury that you get to enjoy for issues you have before you ship.
ModernMech 4y ago
> I have seen devs scoff at the thought of print debugging Next time they do, ask them to recommend a better method of debugging that works across generally all languages, compilers, IDEs, and platforms with next to zero configuration.
- a_e_k 4y ago
  The key thing about print debugging for me, that I've never seen a typical debugger handle well, is what I like to think of as "temporal debugging": Taking a program trace from the print debug statements, grepping through it repeatedly to filter down to certain events of interest, looking at the interleaving of those events, and figuring out the order that things happened in to cause it to go off the rails. That sort of thing. (To be fair, time-travel debuggers can start to get at this, but those are pretty uncommon. Traces, as you say, work almost everywhere.) Or better yet, compare the traces between working and non-working runs to see how they differ. I've looked at diffs of traces this way before. (Sometimes I'll first use a small script to renumber pointers in traces by order of appearance.) I've also used this sort of strategy before for debugging rare threading or other non-deterministic issues. Have the shell run the program in a loop, saving each run's trace and results to a different file, go off and get lunch, come back and see if anything failed. Then look to see if any of the runs failed and look for the structural differences between the working and non-working traces. I can't imagine sitting and stepping through in a debugger 100+ times in the hopes that maybe this time, it will be the run that's just different enough to trigger the bug and that the debugger itself won't prevent the issue from manifesting. Not to mention, trying to remember the steps from all the good runs and spotting where the bad run goes bad before you've stepped to far. No thank you. I think people really underestimate print debugging. Debuggers are fast and easy for simple bugs, sure, but there's powerful stuff that you can only really do with printed traces.

roflyear 4y ago

I learned this stuff without having people show me.