4 ms·

Excerpts from Coders at Work: Joe Armstrong Interview (2013)

72 points by susam 2y ago

vsaase 2y ago
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
- locallost 2y ago
  I found them all to be really down to Earth for such accomplished people.
- m1keil 2y ago
  I listened to the audiobook and didn't get the same impression. I wonder if it's audio related.
- dgb23 2y ago
  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?
- znpy 2y ago
  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.
le-mark 2y ago
Joe Armstrongs dissertation is also an enlightening read; https://erlang.org/download/armstrong_thesis_2003.pdf https://erlang.org/download/armstrong_thesis_2003.pdf
- ignoramous 2y ago
  Fred Hebert's eulogy for Joe Armstrong always moves me to tears: https://ferd.ca/goodbye-joe.html https://ferd.ca/goodbye-joe.html
jacobyoder 2y ago
> 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.
- ryjo 2y ago
  > 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.
  - jacobyoder 2y ago
    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.
- HarHarVeryFunny 2y ago
  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 ...
dkekenflxlf 2y ago
Fonders at Work is great, CaW was rather boring - just a sequel to make $$
randyl 2y ago
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.

72 points by susam 2y ago

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

locallost 2y ago
I found them all to be really down to Earth for such accomplished people.
m1keil 2y ago
I listened to the audiobook and didn't get the same impression. I wonder if it's audio related.
dgb23 2y ago
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?
znpy 2y ago
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.

le-mark 2y ago

Joe Armstrongs dissertation is also an enlightening read; https://erlang.org/download/armstrong_thesis_2003.pdf https://erlang.org/download/armstrong_thesis_2003.pdf

ignoramous 2y ago
Fred Hebert's eulogy for Joe Armstrong always moves me to tears: https://ferd.ca/goodbye-joe.html https://ferd.ca/goodbye-joe.html

jacobyoder 2y ago

> 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.

ryjo 2y ago
> 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.
- jacobyoder 2y ago
  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.
HarHarVeryFunny 2y ago
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 ...

dkekenflxlf 2y ago

Fonders at Work is great, CaW was rather boring - just a sequel to make $$

randyl 2y ago

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.