Dave Schweisguth in a Bottle

Software is a uniquely plastic medium, and the practice of software development changes constantly and quickly. All software engineers are self-taught; even the college-trained learn most of their trade on the job. Though we learn by doing and by watching others and studying their work, I’ve found that reading has consistently been the most powerful way I can understand what I’m doing and learn new methods. So I’m constantly recommending to colleagues one book or another, hoping that they’ll get from it the same value that I did.

To make that easier, here’s a list I’ve been meaning to put together for a long time, of books and other writings that have been essential in shaping my practice of programming. Well-read programmers will find few surprises here, but can be sure that any of these that they’ve missed will be worth their time.

Extreme Programming Explained, Kent Beck, 1999. (Although there’s a second edition, I’ve only read the first.) It’s only 1999 and nearly all of the essentials of agile development are already here: developer testing, refactoring, pairing, collective ownership, iterations. Twelve years later, it’s still hard to do much better. This may be the ideal first book for a professional programmer. For extra credit, the C2 wiki, where I first saw much of this material, is still a great place to see how some of XP’s ideas matured in public.

Test-Driven Development By Example, Kent Beck, 2003. This book supplies the single magic ingredient missing from Extreme Programming Explained, the driving force at the heart of agile development. In a mere 200 pages this book will bring you out of the desert of test-last in which you’ve been wandering and put you on the path to constant upward productivity. Sound cultish? Yes, it’s that essential. The RSpec Book (Chelimsky et al, 2010) covers similar ground but is muddled by details of tool use and the complex relation between unit and functional testing; read it if you write Ruby, but read Beck first.

Refactoring, Martin Fowler et al., 1999. The first programming book that made me realize that there was such a thing as a good programming book. Chapter 3, the best chapter (not by Martin Fowler but by Kent Beck), “Bad Smells in Code”, tells you in only a few pages so many of the reasons why bad code might be bad and what to do about it. The bulk of the book is a catalog of refactorings, not as inspiring reading as chapter 3 but as essential to good programming as (they tell me) standard openings are to playing chess. Practice them until they’re part of you.

Object-Oriented Software Construction, second edition, Bertrand Meyer, 1997. (Amazon’s page says 2000, but appears to describe the same second edition.) A rare exception to the rule that good books are short. This thousand-pager taught me how to think about object-oriented programs and how to design classes (Meyer codified the Open-Closed Principle) and methods (he also codified command-query separation and Design by Contract), and much more. Even agilists need to know good design when they back in to it, and this book goes a long way towards teaching us how. For those in a hurry, or who can’t find a copy of OOSC, Mitchell and McKim’s Design by Contract by Example (2001) covers many of Meyer’s high points and has the advantages of being short and in print, although it lacks OOSC’s sweep and impact.

I was lucky enough to have some smart people point out to me Robert C. Martin’s paper “Design Principles and Design Patterns” (2000) (linked to, along with other good stuff, here) at a time when I badly needed its explanation of software stability. It is easily the most important writing on object-oriented design since OOSC, introducing rationally derived principles not just of class-level design but of architecture. Agile Software Development (Martin et al., 2001) has a more thoroughly developed version of the same material, along with discussions of agile practices and some design patterns.

Code Complete, Steve McConnell, 1993 (!). This is the definitive guide to writing code line by line. It discusses in detail the best ways to declare variables, use control structures, name methods and even format code. Some details are language-specific but their rationales can be easily adapted to whatever language you’re using. Although my first edition barely seems dated, if you insist on something more recent there is a second edition (which I haven’t read, so caveat lector) and Robert C. Martin’s Clean Code (2009) (which I have) does a reasonable job of serving the same purpose.

Continuous Delivery, Jez Humble and David Farley, 2010. Covering source code control, automated testing, continuous integration and automated deployment, this book accomplishes the hat trick of summarizing many practical aspects of managing and delivering software which I had to learn the hard way over many years, doing so clearly and insightfully enough that I appreciate its treatment even of familiar material, and integrating enough current thinking on distributed version control and short-cycle delivery that there is plenty to learn here even for long-time CI devotees.

I’ll add just one book which strays a bit up the food chain from this list’s focus on books about writing code. Writing Effective Use Cases, Alistair Cockburn, 2001, is wonderfully clear and concise on the subject of writing down what an application needs to do to meet a user’s needs. Writing out use cases has gone with the agile wind, but anyone writing or implementing user stories needs to understand and keep in mind all of the concepts presented here.

Look at that — not one book on a language or framework. Not that there aren’t a few good ones, but it’s learning the fundamentals, independent of this year’s favorite technology, that really has lasting value.

Aside from technology-specific books, I’ve left off many that are worthwhile but not of the same exalted rank as those above (a line which I found surprisingly easy to draw), some that I know are well thought of but haven’t read yet, and some that I just dislike. If you’ve got a recommendation that you think is as valuable as the books on this list I would love to hear about it.