Going through my RSS feeds this morning after a week away, I see this post from DHH at 37 Signals:
There are so many programming books out there, but most focus on specific technologies and their half-life is incredibly short. Others focus on process or culture. Very few focus on the timeless principles of writing good code, period. The following five books had the biggest influence on my programming style and development:
A very interesting list, and especially interesting to me that it has no overlap with mine. I do appreciate that his list concentrates on higher-level issues instead of more ephemeral matters (I angled the above photo so you can’t see my office’s Siberia shelf where I’ve exiled books like Brockschmidt’s “Inside OLE”). The five software development books that I’d grab if I had to evacuate in a hurry:
The Pragmatic Programmer: From Journeyman to Master (Andrew Hunt & Dave Thomas)
I re-read this book once a year or so. I love that it’s a set of small concrete steps that you can take every day to make your work better. Two specific changes I made as a result of reading this book were:
- I switched to using vim as my primary editor, even when relying on an IDE to maintain build environments (Tip 22: Use a Single Editor Well)
- When I read this book, C++ was really the only language that I had use for on a daily basis. Their Tip 28: Learn a Text Manipulation Language convinced me to pick up Python, which is now where I spend most of my time coding (and using it far beyond what their description of a text manipulation language would imply).
Code Complete (Steve McConnell)
I vastly prefer the first edition of this book, but there’s still a lot of great material in the second book. The great thing about this book is that he looks at software as a construction activity, and considers the effects on your code of elements from the lowest level inside a single line of code up to broader architectural considerations have on the final product. Most usefully for me, he’s done the work of scouring the literature and providing citations that back up his recommendations. In an argument with someone about issues of indentation, using white space, or other code layout issues? McConnell can point you to the relevant human factors/readability studies that will help you make your case (or change your mind).
Literate Programming (Donald Knuth)
Sure, most folks would have gone for Knuth’s multi-volume ‘The Art of Computer Programming’ if they were going to include anything by him. For me, though, Literate Programming is the really interesting read — his basic concept here is that the true purpose of source code is to explain to another human what you’d like a computer to do, and more incidentally to include the actual instructions that make up the program. It completely upends the traditional thinking, where a source file is mostly code with some comments/documentation strewn about (rarely enough, or at least enough of it being useful). This book is a collection of essays, mostly discussing the WEB (not world-wide — the essays in this book are all from the mid 80s or earlier) system for authoring programs that he developed while creating TeX. A program written using Knuth’s Literate Programming tools reads as a publication that happens to have source embedded in it; post-processing tools named ‘Weave’ and ‘Tangle’ convert from the human-focused layout into compilable source.
On the one hand, I think that Knuth’s vision as presented in this book is a pipe dream (and is largely obviated by more modern tools and methods for thinking about source), but I find the idea of programming as a branch of literature compelling enough that it remains at the front of my mind when I’m coding.
The Design of Everyday Things (Donald A. Norman)
Technically, not a programming book, but instead a book about making things that are intended to be used by humans. Originally written in the late 80s, as software development was slowly making the move from being presented to users via character-mode terminals to modern GUI environments, and many developers needed to be dragged into the era where it was no longer acceptable to deliver clunky, unusable systems. I’ve got a whole section of my shelves filled with Don Norman books — this early one was probably the most eye-opening for me.
Thinking In C++ (Bruce Eckel)
This is another book where the first edition is the important one for me, even though it would probably be less so for anyone reading it today. When this was released, I had been working as a C programmer, mostly, and had been having a difficult time making the switch to using C++ as anything more than ‘a better C’. What Eckel did in this book was to go feature-by-language-feature in C++ and first implement each one in C to provide a thorough understanding of what’s going on beneath the covers before writing the same example program again using the much clearer C++ syntax. Reading this book was one of those cases where a subject I had been struggling to grasp suddenly and thoroughly clicked into place for me.
Those are my five (and I could keep listing books — Design Patterns seemed too obvious, Alexandrescu’s Modern C++ Design perhaps too mind-blowing).
Tag — you’re it.
