Books about programming
My day job is writing code, so naturally a lot of the books I read are about topics related to writing code.
Growing Object Oriented Software, Guided by Tests
Growing Object Oriented Software is the best second book you can read on doing test driven development. This book goes further in depth than any other book I’ve read. I owe my ability to do TDD at all solely to this book, without exaggeration.
The reason Growing is so special is because it’s practical. A lot of TDD books jump into “here’s how you write a unit test” and proceed directly to telling you the philosophy of unit testing and why it’s so great. This doesn’t help you at all when you have to TDD some component three levels down that wires into some other subsystem and talks to a database.
Growing takes the reader through the development of a real project involving a GUI and a remote system, both of which are real problems for beginners in TDD. The only unfortunate thing is that it’s near impossible to follow along by developing in parallel with the authors. Still, just reading to get the general approach and then applying it to your own projects is a good substitute.
This is required reading for any developer. Even more than books like Code Complete or Clean Code, Refactoring shows how to get into the mindset of making code better (by some metric of better), and what to do once you’re in that mindset. Moreover it shows you what’s required to take a piece of code that isn’t clear or well factored, and turn it into one that is.
A large part of the book is dedicated to a catalog of specific refactorings (some of which are implemented by IDEs now) but it’s debatable whether you need to read the entire catalog. A more useful approach might be to read just the example block and motivation for each refactoring, then reference it as needed.
When I first read Programming Pearls, I didn’t think it was very useful. A lot of the suggestions and ideas seemed dated. It wasn’t until my second read through that I actually grasped the material.
Programming Pearls is a sort of “Part 2” to a good algorithms and data structures book. Learning data structures lets you solve a lot of problems, but finding the best solution requires careful examination of the specific circumstances surrounding the problem. The real world is often very different from a hermetically sealed academic environment, this book helps bridge that gap. If nothing else it’s fun to think about some of the numerous problems that come at the end of the chapters and see some of the surprising answers.
Working Effectively With Legacy Code
Working Effectively with Legacy Code is unique because it’s the only authoritative book on its subject. The lessons from Working Effectively are surprising because they are mostly common sense. Add test cases, don’t make dangerous changes, grow the code towards a better state. There are various reasons that they become difficult to apply, but all the required information for turning a legacy project into maintainable and well factored code is here. If you ever have to work with any code that doesn’t have a comprehensive set of test cases then you can learn something from Working Effectively. Pairs great with Refactoring!
Books about “Devops”
I use the term Devops very losely here to describe anything that has to do with operations tasks that developers might have to perform. Regardless of whether or not you need to configure and manage infrastructure in your day to day, being able to own certain parts of the software creation pipeline is invaluable. Knowing how your software gets deployed and what to do when it fails gives you a huge leg up, these books help you do that.
Release It is one part encyclopedia of suggestions to incorporate into the design of your software and one part war stories describing what those suggestions are meant to prevent. I picked this book up at the start of a new project where there were a lot questions around how the software should be designed to be fault tolerant, how to make sure it would be easy to scale under burst workloads, and how make sure it would be easy to recover from failure. As the project went on, I was able to see more and more places where the patterns from Release It could be applied. Of course during the projects lifetime we also found plenty of places we wished we had applied them more throughly.
There’s a lot of good specific information here, but the real lesson from Release It is that if you want to design fault tolerant software, it’s not enough to write code. You can apply all the patterns and avoid all the anti patterns, but if your architecture is not correctly designed, or if you have a server that is a single point of failure, it won’t matter. You need to plan at a high level, measure closely, and work in multiple domains in order to accomplish the objective.
This was the first book on this list that I read, and it’s also required reading like Refactoring. The ideas here are the foundation of how we take code from running on a developers machine to running on production servers. The formalization of what it means to run a build server is presented here, and what tasks you should perform at each stage of the build and deployment pipelines. I would actually go so far as to say that Managers and Ops personal should read some of the sections. Highly recommended.
Books about other interesting topics
These are books that don’t necessarily have anything to do with writing software. Nevertheless you can apply a lot of the lessons to software development. They have impacted me the same way the above books have.
War of Art
The War of Art is a catalog of statements on, more or less, how to create something and what you’re likely to encounter in that pursuit. The genius of this book is really in its organization. It’s worth it to read the book through once to get a full picture of the philosophy being presented, but each short section can also be read individually. It’s quite common for me to be working on something, remember a section that applies, go back to re-read it, and then continue in a better mood.
A good book to keep on your desk as motivational reference.
Soft Skills is sort of like a life manual for software engineers. There’s a ton of good advice on this book but, for me at least, I wasn’t able to grasp everything on one read through. This is another good one to read through once and then come back and reference when you’re met with a situation that one of the chapters deals with.
A good example from my own experience is goal setting. I didn’t have much experience with setting goals before reading this book. In fact even after reading it I didn’t really understand a lot of the process or benefit of setting a goal, doing regular followups, and breaking goals down into meaningul pieces to accomplish them. It wasn’t until maybe 3 or 4 months and many failures later that it finally clicked. Over a year after reading Soft Skills I’m still finding information gleaned from its pages that I can apply to my life.
Zen and the Art of Motorcycle Maintenance
This is, at its heart, a philosophy book. I don’t have the background to give a proper analysis here, and yet this was one of the rare books that I couldn’t put down. There’s nothing I learned from this book that I could directly apply to software development. On the other hand, basically the whole book is applicable. One of the things I pulled from Motorcycle Maintenance is the idea that in order to be a better developer, I need to improve myself in general. To become a better person actually makes me a better developer as a consequence. That idea alone is why this is my favorite book of all of the ones in this list!