> CTB: one surprising commonality amongst many of the interviews thus far is the lack of use (or disdain for) debuggers. Almost everyone trots out print statements!
Interesting. I came of age before debuggers were a 'thing' available to common kids at home (80s BASIC, etc). As I've worked in various environments over the years, debuggers are nice when available, but they're not always available. Code is only running in production, you don't have full access to a debuggable environment, company won't pay for tool X, etc. print/log statements always work, regardless of what tool/language you're working with. Or... 'always work' enough of the time that it's not surprising it's a common theme.
I jump between client projects relatively often (consulting) and while I do use debuggers, I don't use them exclusively (perhaps no one does?). The longer I'm in a codebase, the more likely it will be that I'll end up with a full debugger setup and get comfortable stepping through all the bits.
I've been a developer for 40+ years, and have to agree. I've never found debuggers to be the most efficient way to debug code, and it's not something I'd normally reach for during development.
The only time I normally used a debugger is for post-mortem debugging - looking at a production core file for a multi-threaded process to see where it was in the code (and maybe inspect a few variables) when it crashed. If the core isn't sufficient to isolate the problem, then I'll add more logging to isolate it next time it happens.
During development, printf is just so much more convenient. I'll always put print/log statements in my code as a combination of tracing execution flow and to validate assertions / check that variables have the types of value that I'm expecting. Often this sort of pre-emptive debugging is all you need, and if not it should point to exactly where you need to sprinkle a few more print statements to isolate an issue.
The convenience of print statements is that once you've put them there, at critical points in your code, and printing critical values, they are always there (can conditional them out once code is working, if wanted), as opposed to having to go into a debugger, navigate to points in code, setup breakpoints, monitor variables etc ...
I'm of a similar vintage, and I found debuggers valuable when I was debugging Windows 3x and 9x programs, C or MFC C++. You needed to get in to the data structures in memory sometimes, and Microsoft made good debuggers at the time.
Modern development, scripting languages and web development, I rarely use a debugger, setting it up for each of the various languages we jump to is too much bother.
> I'll always put print/log statements in my code as a combination of tracing execution flow and to validate assertions / check that variables have the types of value that I'm expecting.
This is where Go's superfast compiles shine. Debuggers-B-Gone.
The biggest issue for me is working on distributed systems. It's non-trivial to run many different servers and clients through a debugger all at the same time, components often have timeouts that are going to trigger due to the delay you'd cause even if you could, and much of the most vexing behavior happens in the networking stack rather than in your own software, and you can't run Linux in a debugger while also running your own software on top of the Linux that is in a debugger.
This is why we have logs, metrics, and traces. They attach at least some of the same instrumentation you'd get out of a debugger but all the time. You lose the flexibility to stop, step, and modify program behavior at runtime, but also gain data that is representative of what happens at full speed, which may be the only time certain bugs manifest anyway.
Using debuggers makes a lot of sense in this case. If I had to switch context that frequently between relatively stable applications, it would be helpful to have a debugger framework for doing work.
`printf` statements are helpful when the error exists beneath the debugger: in the application framework itself.
> they're not always available
100% agreed. `printf` is "one tool" I can use to follow the control flow of a function call across frameworks, programming languages, and even operating systems. It's also something I can reliably assume my coworkers have in their tool belt, and thus provides a common language that even multiple different organizations can use to cross-collaborate a specific debugging session.
the longer i'm on a project, the more inclined i may be to get a debugger going, but often there's much more low hanging fruit to deal with that doesn't necessarily need a debugger to figure out.
For sure debuggers are great not just for debugging but as a way to reverse engineer a large codebase.
I had noticed the disdain for debuggers and it used to make me feel a bit inferior for relying on them but then found that John Carmack loves them so I feel better now. Ha!
I started programming with scripting languages so mainly had to rely on print statements. I also worked in production support and QA in the past - print statements are the main tools over there. Even though I am programming in languages like Java/Go/Python now that have proper debugger support, all that history has resulted in me relying mainly on print statements. Also my print statements are now more carefully structured to provide almost a narrative to help support/QA folks (and myself) - I don't want them to suffer like I did due to lack of well designed log statements.
There's a general distain for fancy tooling like IDEs. I have to wonder how a lot of these people would think of programming these days, with the rise of AI, ubiquitous code analysis, linting, formatting, CI, packages. Even in the short amount of time that I've been programming, writing software has changed massively. I have to imagine it'd appear as a completely different enterprise to them.
I really enjoyed "Coders at Work". Joe Armstrong's interview really stuck out to me; it seemed like he just thought differently than everyone else in the book. In a way, he reminded me of Larry Wall.
When I last read the book I found most interviewees had an aggressive or bro-like manner, putting coding skills over everything else. Made me kind of sad from the viewpoint of someone who has duties outside of coding
To me the interviewees didn't come off as you describe at all. They are discussing the subject matter, which is the focus of the book "craft of programming" (see: subtitle).
Also most of them (at least) are known to have a focus on the practice of programming itself. They are literally authors/stewards of established algorithms, programming languages, operating systems and browser engines. What else would would you expect?
> CTB: one surprising commonality amongst many of the interviews thus far is the lack of use (or disdain for) debuggers. Almost everyone trots out print statements!
Interesting. I came of age before debuggers were a 'thing' available to common kids at home (80s BASIC, etc). As I've worked in various environments over the years, debuggers are nice when available, but they're not always available. Code is only running in production, you don't have full access to a debuggable environment, company won't pay for tool X, etc. print/log statements always work, regardless of what tool/language you're working with. Or... 'always work' enough of the time that it's not surprising it's a common theme.
I jump between client projects relatively often (consulting) and while I do use debuggers, I don't use them exclusively (perhaps no one does?). The longer I'm in a codebase, the more likely it will be that I'll end up with a full debugger setup and get comfortable stepping through all the bits.
I've been a developer for 40+ years, and have to agree. I've never found debuggers to be the most efficient way to debug code, and it's not something I'd normally reach for during development.
The only time I normally used a debugger is for post-mortem debugging - looking at a production core file for a multi-threaded process to see where it was in the code (and maybe inspect a few variables) when it crashed. If the core isn't sufficient to isolate the problem, then I'll add more logging to isolate it next time it happens.
During development, printf is just so much more convenient. I'll always put print/log statements in my code as a combination of tracing execution flow and to validate assertions / check that variables have the types of value that I'm expecting. Often this sort of pre-emptive debugging is all you need, and if not it should point to exactly where you need to sprinkle a few more print statements to isolate an issue.
The convenience of print statements is that once you've put them there, at critical points in your code, and printing critical values, they are always there (can conditional them out once code is working, if wanted), as opposed to having to go into a debugger, navigate to points in code, setup breakpoints, monitor variables etc ...
I'm of a similar vintage, and I found debuggers valuable when I was debugging Windows 3x and 9x programs, C or MFC C++. You needed to get in to the data structures in memory sometimes, and Microsoft made good debuggers at the time.
Modern development, scripting languages and web development, I rarely use a debugger, setting it up for each of the various languages we jump to is too much bother.
2 replies →
> I'll always put print/log statements in my code as a combination of tracing execution flow and to validate assertions / check that variables have the types of value that I'm expecting.
This is where Go's superfast compiles shine. Debuggers-B-Gone.
Correct me if I'm wrong but you basically just described good logging practices, yea?
1 reply →
The biggest issue for me is working on distributed systems. It's non-trivial to run many different servers and clients through a debugger all at the same time, components often have timeouts that are going to trigger due to the delay you'd cause even if you could, and much of the most vexing behavior happens in the networking stack rather than in your own software, and you can't run Linux in a debugger while also running your own software on top of the Linux that is in a debugger.
This is why we have logs, metrics, and traces. They attach at least some of the same instrumentation you'd get out of a debugger but all the time. You lose the flexibility to stop, step, and modify program behavior at runtime, but also gain data that is representative of what happens at full speed, which may be the only time certain bugs manifest anyway.
> I jump between client projects relatively often
Using debuggers makes a lot of sense in this case. If I had to switch context that frequently between relatively stable applications, it would be helpful to have a debugger framework for doing work.
`printf` statements are helpful when the error exists beneath the debugger: in the application framework itself.
> they're not always available
100% agreed. `printf` is "one tool" I can use to follow the control flow of a function call across frameworks, programming languages, and even operating systems. It's also something I can reliably assume my coworkers have in their tool belt, and thus provides a common language that even multiple different organizations can use to cross-collaborate a specific debugging session.
the longer i'm on a project, the more inclined i may be to get a debugger going, but often there's much more low hanging fruit to deal with that doesn't necessarily need a debugger to figure out.
For sure debuggers are great not just for debugging but as a way to reverse engineer a large codebase.
I had noticed the disdain for debuggers and it used to make me feel a bit inferior for relying on them but then found that John Carmack loves them so I feel better now. Ha!
I started programming with scripting languages so mainly had to rely on print statements. I also worked in production support and QA in the past - print statements are the main tools over there. Even though I am programming in languages like Java/Go/Python now that have proper debugger support, all that history has resulted in me relying mainly on print statements. Also my print statements are now more carefully structured to provide almost a narrative to help support/QA folks (and myself) - I don't want them to suffer like I did due to lack of well designed log statements.
There's a general distain for fancy tooling like IDEs. I have to wonder how a lot of these people would think of programming these days, with the rise of AI, ubiquitous code analysis, linting, formatting, CI, packages. Even in the short amount of time that I've been programming, writing software has changed massively. I have to imagine it'd appear as a completely different enterprise to them.
Joe Armstrongs dissertation is also an enlightening read;
https://erlang.org/download/armstrong_thesis_2003.pdf
Fred Hebert's eulogy for Joe Armstrong always moves me to tears: https://ferd.ca/goodbye-joe.html
I really enjoyed "Coders at Work". Joe Armstrong's interview really stuck out to me; it seemed like he just thought differently than everyone else in the book. In a way, he reminded me of Larry Wall.
When I last read the book I found most interviewees had an aggressive or bro-like manner, putting coding skills over everything else. Made me kind of sad from the viewpoint of someone who has duties outside of coding
To me the interviewees didn't come off as you describe at all. They are discussing the subject matter, which is the focus of the book "craft of programming" (see: subtitle).
Also most of them (at least) are known to have a focus on the practice of programming itself. They are literally authors/stewards of established algorithms, programming languages, operating systems and browser engines. What else would would you expect?
I found them all to be really down to Earth for such accomplished people.
It's entirely a matter or perception (and prejudice, most likely).
For example, if you watch any talks by Joe Armstrong you'll immediately perceive it as a kind, funny and down-to-earth guy.
I listened to the audiobook and didn't get the same impression. I wonder if it's audio related.
Fonders at Work is great, CaW was rather boring - just a sequel to make $$