The five programming books that meant most to me

Image of Brett\'s bookshelf

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.

Brett g Porter

Brett g Porter

Lead Engineer, Audio+Music at Art+Logic
Audio+Music development engineer. Always looking for excuses to write code. Tweets at @bgporter.
Brett g Porter


Music (composer/trombonist/software) + Ice Cream (making/eating). Lead Software Engineer @Artiphon. Creator of @tmbotg. Exec board @ he/him.
@timur_audio @jetbrains @clion_ide Excellent news! Congratulations! - 14 hours ago
Brett g Porter
Brett g Porter

Latest posts by Brett g Porter (see all)


Creative Commons License

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.


  1. Kevin Seghetti

    The book I have given to people more than any other is Writing Solid Code. The most important part of the book is easy to remember: after finding a bug, ask 2 questions:
    1. How could I have prevented this bug?
    2. How could I have automatically detected this bug?
    The rest of the book is various ways to implement the answers to these questions.

  2. bgporter

    Yeah, that’s a good one too (my copy’s just offscreen in the photo above); haven’t read it in a long time, and should probably go back and do a quick re-read. There was kind of a golden age of books from Microsoft Press there for a while, wasn’t there?

  3. bpoteatal

    Crafting a Compiler in C.

    That was the first book where I *got* programming languages somewhere around my sophomore or junior year of college. Of course, I could hack together programs based on snippets of code I found in other places (and this was before google was the best source for finding guidance) but the concept of truly understanding the grammatical structure of a language and *why* it was like that hadn’t really permeated my consciousness.

    I imagine actually writing a few compilers was probably the biggest help but this book was behind me actually doing it.

  4. Gregg Irwin

    Always fun to hear other’s favorites and look at the shelf nostalgically. McConnell is a long-time favorite. All his books are worth reading IMO. PragProg, yes, that too. Bentley’s Programming Pearls is near the top of my list as well. And while I’ve never used Eiffel for production work, Meyer’s Reusable Software and Object Oriented Software Construction both had a big impact on my thinking, as did Harvey’s Computer Science Logo Style. My list is probably topped by Software Runaways by Robert Glass, because it turned me on to him as an author, and led to reading his other works.

    • bgporter

      Where McConnell lost me was with his book ‘After the Gold Rush’, where he tries to make the case for requiring software developers to become certified and applying a specific style and flavor of Engineering Rigor to software development that I don’t think is appropriate (or perhaps even attainable in this world). Maybe someday building software will be more like building bridges, but today it’s not. I suspect that the difference between making something out of physical materials will always be sufficiently different from making things out of logic and ideas that software development will always be more craft-like than engineering-like.

  5. Gregg Irwin

    We still have a long way to go. I don’t agree with current certification models, but I do think McConnell and Construx have done a lot to raise awareness and expectation in a good way. And there is a lot more gray than black and white. Are there still a lot of cowboys who want to do things their own way? Yes. Are we all mindless copy-paste hackers? No.

    I think we’re human, and subject to being Predictably Irrational, but see the value in simple concepts as explained in The Checklist Manifesto. I haven’t worked on something that could afford NASA’s cost per LOC, which is at the far end of McConnell’s spectrum. At the low end, we can do a lot better than we do now, and I think we’ll learn a lot of lessons from the Construx, Humphreys, and Wiegers.of the world.

    The trick is how to get the most value from the least effort. Most people follow the path of least resistance. Make the right way the easy way, and we win.


  1. Books: More Good Ones | Art & Logic Blog - [...] like to expand on Brett’s post a bit with some more recent books that I’ve enjoyed. And another which…
  2. Books: More Good Ones | - […] like to expand on Brett’s post a bit with some more recent books that I’ve enjoyed. And another which…