Book Review: Coders at Work
/There are quite a lot of interviews with software developers out there. Though, I doubt there are many that feature such an array of accomplished developers as Coders at Work does. In this book, there are quite a few words of wisdom from developers who have been through the tough bugs and the long projects.
When I first got this book, most of the names I didn't recognize. In fact, there were only just a couple I did recognize by name - Donald Knuth and Douglas Crockford.
It was very interesting getting to know the other programmers in this book. Perhaps the most interesting reading in it, I felt, was the blurbs that introduce each person. Telling what they accomplished, what they're currently working on, and a sentence or two of what they talk about in the interview. The most fascinating thing is learning how each individual person being interviewed contributed to the world of computer science.
There were quite a few take aways from this book that may be applicable to everyday work. The biggest of these, though, is that most of the people being interviewed, when asking about how they debug a program, still use the very reliable print statement. In fact, there's this MIT open courseware lecture on debugging that just goes over exactly that!
Here are a few other items of note that I learned while reading this book:
Jamie Zawinski gives advice to not be afraid of what you don't know and that it's ok to ask someone who does about it.
Joshua Bloch says that it's important to know what you're trying to build before you get started. He suggested a talk he gave a quite a while ago now - How to Design a Good API and Why it Matters.
Joe Armstrong has a few nice pieces of advice.
- He gives a really good debugging technique for finding errors which is that all errors will be three statements before or after the last place you changed the program.
- He mentions that documentation tells you what the code is supposed to do. "Just read the code" will tell you what it does. Sometimes they aren't the same thing.
- He mentions a nice talk by Richard Hamming, "You and Your Research", that has a lot of advice such as...
If you don't do good stuff, in good areas, it doesn't matter what you do.
Simon Peyton Jones mentions an interesting paper on "Why Functional Programming Matters". Which has been turned into a talk!
Ken Thompson knew for a long time that working 60, 80, or even 100 hours a week will definitely generate burnout. External deadlines also definitely generate stress.
There's a ton more to learn from this book. From here you can step into the shoes of programming greats and learn the lessons they have learned.
