The five programming books that meant most to me

image

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.

Source Code Pro — Adobe’s New Programmer’s Typeface

Source Code Pro example

I’ve been interested in the issues surrounding how typography and layout can aid or impede developers working with source code. There’s an excellent book from ACM Press Human Factors and Typography for More Readable Programs (1990) by Baecker and Marcus that walks the reader through (in great detail) an iterative design process developing what the authors call ‘a visual C compiler’ to present C code in a format that maximizes a developer’s ability to read and understand large bodies of source code by appropriate use of typography and color. Considering that the book was published in 1990, I have to assume that many (most?) developers were still restricted to character-based monochrome development environments, and that the book was thus pretty much science fiction at the time (I started my career not long after this and remember being lectured by a greybeard of the time that color in computer displays was just a useless distraction). Certainly, few of its lessons have been folded into the tools that we work with. A few years later, Marcus published another book Graphic Design for Electronic Documents and User Interfaces (1992) that further develops and generalizes some of these principles for the modern bitmapped display systems of the time (Mac, OpenLook, NeXT, etc.). Flipping through it now reminds me that I should give it a re-read, and that a few years after its publication, an article by Marcus suggesting the development of systems supporting gender-specific UI layouts caused a lengthy kerfluffle in Communications of the ACM (I do remember his suggestion that women would find interfaces featuring rounded elements including circular windows to be more attractive and usable as something that particularly raised ire in readers).

Another book from that era that influenced my thinking about the environment in which we work is Knuth’s excellent Literate Programming (1992), especially the parts discussing his ‘Web’ (and later ‘CWEB’) system for Literate Programming, in which the primary artifact being created is discursive documentation that happens to have code embedded in it — the documentation is output for readability via his TeX system, and manipulated for compilation using a ‘weave’ program. TeX itself was written in this manner. 20 years later, and this is still science fiction, though.
When I sat down to write this piece, I was excited about the announcement of Adobe’s new monospaced font Source Code Pro, which I’m switching all my terminals and editors over to after using the excellent Inconsolata font for the past few years. Source Code Pro seems to have some especially clean and distinguishable glyphs for the commonly confused characters:

Confusable characters

The font is downloadable for free from here at Sourceforge. Also interesting is that the font itself is fully open source — you can also download all the source code used for the creation of Adobe’s entire Source Sans font family.

Now that I’ve thought about it in terms of the kinds of tools and environments we were promised 20 years ago, I’m less excited now. You can keep your flying cars. I want a more awesome way to build software.