I just finished reading Coders at work, by Peter Seibel. In this book, the author interviews 15 amazing people who shaped the way we produce programs and the basics of what is Programming and Computer Science.
The cast of interviewee include pretty notorious programmers (coders):
- Jamie Zawinskie (Netscape/Mozilla legend, and father of now defunct XEmacs)
- Brendan Eich (Inventor of Javascript)
- Doug Crockford (Js guru)
- Joshua Bloch (author of the Java Collections)
- Joe Armstrong (father of Erlang)
- Ken Thompson (father of Unix, Plan9 and Go, precursor of C)
- Simon Peyton Jones (functional programming God)
- Peter Norvig (AI guru)
- Guy Steel (programming linguist, sat on the founding committee of so many languages including Scheme, CL and Java)
- Brad Fitzpatrick (web whiz kid, author of memcached)
- Dan Ingalls (implementor of 7 generations of Smalltalk)
- L. Peter Deutsch (author of Ghostscript)
- Fran Allen (she pioneered the field of compiler optimization)
- Bernie Cosell (early engineer of ARPANET, which ultimately became the Internet)
- Donald Knuth (do I really need to present him?)
Seibel (the author) is a journalist turned Lisp hacker turned writer. The questions he asks are spot on, exactly the kind of questions a programmer would want answered. Some questions were pretty recurrent:
- How do you read a piece of code you didn't write?
- What's the best debugging strategy?
- How do you start a new program? top-down vs down-up?
- Do you feel you programmed better when you were young?
- Does the new generation of programmers have it harder because they cannot understand everything going on in the machine?
He also has this quirk question he enjoys asking:
- Do you see yourself as a scientist, an engineer, an artist, a craftsman or something else?
Other topics covered include the importance of opening black boxes, understanding the underlying machine, refactoring, and whether code should be a mean to an end or can be the goal in itself.
The answers vary greatly among his subjects, showing once again that programming has no one single Truth. Although all seem to agree on one thing: Write a ton of code, that's the only way to become good.
I enjoyed every single one of the interviews, although if I had to pick the most interesting ones:
Jamie Zawinski is the rockstar of programming. Think Guns'n Roses meets Frank Zappa. His interview covers a lot of the history of Netscape (and what later became Mozilla). He puts a huge emphasis on delivering the product on time, even if this means messy code.
Crockford goes great length convincing the author (and the reader) that Javascript is, against all odds, a wonderful language. He mentions the importance of subsetting the language and limiting yourself to the features you know are awesome. He also talks a lot about working in teams and the importance of code reading sessions.
Bernie Cosell is a maniac. I mean it he's inhumane. When he joined the team that built what became the first nodes of the internet, they had a very singular debugging technique. They would patch the binaries. You read correctly, patch the binaries, no source code involved. They would look at the output, figure out "Hey that's something wrong", add a jump instruction, modify the structure of their program and let it flow. They got by doing this for years. He was one of the first to insists that they stopped doing it. His interview is filled with the importance of readable source code. The idea I keep in mind is: "It doesn't matter if it works. If I cannot understand what you wrote, it's still useless to me".
Don Knuth is out of this world. If jwz is the rockstar, he's the J. S. Bach of programming. Just like others in this book, but probably more than the rest, he absolutely adores programming. And it's contagious. He believes that reusable code is a terrible idea, that goto statements aren't as bad as we believe and that there's no single Truth, what works for him won't work for the next guy. He also talks a lot about the idea of literate programming, and the importance of keeping 2 models in your head at the same time.
A couple of similarities were:
- Not many of them seem to enjoy C++.
- They all seem to be using emacs. According to Seibel himself, there are 2 groups of people he interviewed: Those who're proud of using emacs, and those ashamed they're still using emacs :)
I could go on forever. Honestly, buy the book. It's such a great read. If you're at all interested in programming and curious to know how legends of the field think about the craft (or is it engineering? art? science?) then you will enjoy every page of it. I know I certainly did.
PS: The only thing really missing from the book is a summary of all the interviews. What should we take from all this? It seems like Seibel owe us some further analysis. Fortunately that's exactly what he did in a talk (available on Youtube) that he gave at Google shortly after the book came out.
The cast of interviewee include pretty notorious programmers (coders):
- Jamie Zawinskie (Netscape/Mozilla legend, and father of now defunct XEmacs)
- Brendan Eich (Inventor of Javascript)
- Doug Crockford (Js guru)
- Joshua Bloch (author of the Java Collections)
- Joe Armstrong (father of Erlang)
- Ken Thompson (father of Unix, Plan9 and Go, precursor of C)
- Simon Peyton Jones (functional programming God)
- Peter Norvig (AI guru)
- Guy Steel (programming linguist, sat on the founding committee of so many languages including Scheme, CL and Java)
- Brad Fitzpatrick (web whiz kid, author of memcached)
- Dan Ingalls (implementor of 7 generations of Smalltalk)
- L. Peter Deutsch (author of Ghostscript)
- Fran Allen (she pioneered the field of compiler optimization)
- Bernie Cosell (early engineer of ARPANET, which ultimately became the Internet)
- Donald Knuth (do I really need to present him?)
Seibel (the author) is a journalist turned Lisp hacker turned writer. The questions he asks are spot on, exactly the kind of questions a programmer would want answered. Some questions were pretty recurrent:
- How do you read a piece of code you didn't write?
- What's the best debugging strategy?
- How do you start a new program? top-down vs down-up?
- Do you feel you programmed better when you were young?
- Does the new generation of programmers have it harder because they cannot understand everything going on in the machine?
He also has this quirk question he enjoys asking:
- Do you see yourself as a scientist, an engineer, an artist, a craftsman or something else?
Other topics covered include the importance of opening black boxes, understanding the underlying machine, refactoring, and whether code should be a mean to an end or can be the goal in itself.
The answers vary greatly among his subjects, showing once again that programming has no one single Truth. Although all seem to agree on one thing: Write a ton of code, that's the only way to become good.
I enjoyed every single one of the interviews, although if I had to pick the most interesting ones:
Jamie Zawinski is the rockstar of programming. Think Guns'n Roses meets Frank Zappa. His interview covers a lot of the history of Netscape (and what later became Mozilla). He puts a huge emphasis on delivering the product on time, even if this means messy code.
Crockford goes great length convincing the author (and the reader) that Javascript is, against all odds, a wonderful language. He mentions the importance of subsetting the language and limiting yourself to the features you know are awesome. He also talks a lot about working in teams and the importance of code reading sessions.
Bernie Cosell is a maniac. I mean it he's inhumane. When he joined the team that built what became the first nodes of the internet, they had a very singular debugging technique. They would patch the binaries. You read correctly, patch the binaries, no source code involved. They would look at the output, figure out "Hey that's something wrong", add a jump instruction, modify the structure of their program and let it flow. They got by doing this for years. He was one of the first to insists that they stopped doing it. His interview is filled with the importance of readable source code. The idea I keep in mind is: "It doesn't matter if it works. If I cannot understand what you wrote, it's still useless to me".
Don Knuth is out of this world. If jwz is the rockstar, he's the J. S. Bach of programming. Just like others in this book, but probably more than the rest, he absolutely adores programming. And it's contagious. He believes that reusable code is a terrible idea, that goto statements aren't as bad as we believe and that there's no single Truth, what works for him won't work for the next guy. He also talks a lot about the idea of literate programming, and the importance of keeping 2 models in your head at the same time.
A couple of similarities were:
- Not many of them seem to enjoy C++.
- They all seem to be using emacs. According to Seibel himself, there are 2 groups of people he interviewed: Those who're proud of using emacs, and those ashamed they're still using emacs :)
I could go on forever. Honestly, buy the book. It's such a great read. If you're at all interested in programming and curious to know how legends of the field think about the craft (or is it engineering? art? science?) then you will enjoy every page of it. I know I certainly did.
PS: The only thing really missing from the book is a summary of all the interviews. What should we take from all this? It seems like Seibel owe us some further analysis. Fortunately that's exactly what he did in a talk (available on Youtube) that he gave at Google shortly after the book came out.
