Great Software Writing (that influenced me personally)

A few days ago a proposed a short-list of great software works. A couple of them are associated with the great works of software writing, and so I started to think about what the top five pieces of great software writing were.

This was a lot harder for me to narrow down, so in the end, I decided to make it personal. What had influenced me the most? This means I have to leave off The Art of Computer Programming, which is undoubtedly a great work, because I haven’t read it.

These works were chosen because they shape how I think about programming anything. They are language and framework independent. I chose three that are more about process and three that were more technical.

This is in the order I read the books or papers.



For me, these are works that still affect how I program today. My main lessons:

From Peopleware, that the biggest factors in programming productivity were access to quiet and long blocks of time, and that this explained correlations of productivity within a workplace.

From eXtreme Programming, unit testing, continuous integration, pair programming, small releases, and refactoring which are all part of how I have worked from the day I finished reading it.

From Joel on Software, don’t rewrite software, UI design for programmers, tons of software business. Also, one of the main reasons I applied to (and worked for) Trello.

From Design Patterns, that it’s useful to look for common solutions and give them a good name and description (not the specific patterns, although I obviously had learned from them).

From A behavioral notion of subtyping, I learned about how to progress software. I think about substitutability for almost every line of code I write inside of deployed software. I wrote about this in my blog post on Substitutable Versioning.

From Purely functional data structures, I learned that functional programming was technically possible. I had read about FP (and even wrote about it) in college (~1990), but at the time, it wasn’t conceivable to me that this could work—granted, I was just a student. After clojure came out, and introduced me to Okasaki’s work, I was convinced that FP had a place in my toolset. I wrote about that revelation back in 2008 in my 20 days of clojure series, where I tried to learn clojure quickly because I was helping to host a Rich Hickey talk.

Some notable things that I read but didn’t include are Decline and Fall of the American Programmer (this was interesting but turned out to be mostly wrong), Writing Solid Code, and Code Complete (great, but read it too late in my career to be influential).