Reading Up: Books Every Programmer Should Read

When discussing books on software engineering with colleagues, I got the idea of listing the best books I’ve read in the past 15 years. Because it seems useful, but also because that will allow others to tell me which ones I should have read… Let’s start with some technical books. I’ve never had much taste for books on too specific technology subjects, so there’s no ‘J2EE Internals’, or ‘Jini Programming for Dummies’ books here. Not that I never read anything like that, but those were never books that really influenced how I do my job. Looking at this list it seems that I’m not very imaginative, since most of these are very well known classics. Still:

Larman’s book (though in the first edition, I haven’t read the third edition I’m linking to here) was the book that first really explained Object Orientation to me. I had had courses in OO before that, but I’m pretty sure I didn’t actually understand it before reading this book.

It was also a nice introduction to UML, which I went all meta-meta-model-overboard on for a while before calming down and focusing on code.

There are other books on UML (UML Distilled is a good one), others on Design Patterns (see below), but if you want to learn Object Oriented Design, and get a good introduction to iterative development, UML and Patterns, then this is the book to get.

I think everyone (who is remotely interested in OO) has at least heard about this book by the ‘Gang of Four’. The first approximately 65 pages of the book are a discussion on what patterns are, why they are useful, and how they are sturctured. The rest of the book is a catalogue of patterns.

Reading the patters will give (gave me, at least) a constant ‘Aha-erlebniss’, ranging from ‘So that’s why they did that!’, to ‘So that’s the thing I was doing in that project called!’ to (most often:-) ‘Damn! That’s what I should have used there-and-there!’.

Very much recommended for its obvious and continuing relevancy to anyone writing code. I’ve noticed recently that I’ve been forgetting which pattern was which (not enough coding…), so I suppose it’s time to do a little refresher here.

This one has in my mind always been the companion book the the Design Patterns book. It is structured in a similar way, with a part explaining what refactoring is (‘Improving the design of existing code’, as the subtitle proclaims), and then contains a long list of ‘Refactorings’, which are structured in the same way as in the Patterns book: How to apply in Which situations. This book also introduced the concept of ‘code smells’: those places in the code where you know something is wrong, even in the cases where you don’t know what it is that’s wrong. Again very much recommended. The various descriptions of what is wrong why, and how to fix it, are a great learning experience.

Kent Beck, of eXtreme Programming and JUnit fame, goes into deep detail of the TDD XP practice, by showing step-by-step implementations using TDD. He also explains why TDD works so well, that it is not just a way to increase your test-coverage, how it drastically improves design, and how to use it to write your own unit-test framework.

For some nice links to TDD articles and to Becks (and others) screencasts, see my earlier post. If you haven’t tried TDD yourself, give it a try. The results are surprising…

I haven’t actually read this one yet, but based on reviews, and on the fragments that I did read, it’s another must-read. Which is why it is on my nightstand in the ‘to read’ queue… The ‘Refactoring’ book teaches you a lot of things about improving code, but this one gives often more basic advice on keeping your code clean, readable, understandable en easy to change.

More when I’ve finished reading this one…

One other book that I’m aiming to add to my queue is Michael Feather’s Working Effectively With Legacy Code, which builds on the Refactoring concept, but grounds it in the ugly reality of dealing with legacy systems (defined as code that is not under test). After reading the original article, and recognising the situations he’s talking about, I’m convinced this is a good one to add.

12 thoughts on “Reading Up: Books Every Programmer Should Read”

I would like to add The Productive Programmer (http://oreilly.com/catalog/9780596519544) to the list. Neal Ford describes a lot of small and easy to implement ways of becoming more productive as a programmer. Perhaps not as serious as the above books, but definitely one of the better books I’ve read in the past years.

wouter, thanks for the list. I have to second clean code. Clean code taught me how to write a clear function. Clean code also helped me see that writing good code is like writing a good sentence. I would also like to recommend Pragmatic Programer (http://www.amazon.com/dp/020161622X?ref=servicebrook-20). The Pragmatic Programer really helped me see that there was so much more to programming than writing code.