After reading Jeff Atwoods comments on the fact(?) that programmer’s don’t read books I was a bit upset. Not because I disagree with him; my experience also shows that most programmers, at least of the ones I have met and worked with in the past, neither read nor own books about their profession—I even remember reading the mentioned paragraph in Code Complete years ago and laughing at just how well I recognized this phenomenon.

However, I personally think reading books is one of the best ways to learn new stuff and gain a better understanding of the world, so I feel a bit sad that not more people are doing it. For this reason, I now present you with my must-have list of books for programmers:

Code Complete: A Practical Handbook of Software Construction
by Steve McConnell

If you are only ever going to read a single book about computer programming, this should be the one.

This book opened my eyes to a whole new world of computer literature. Until I found this well of wisdom, I had only read technology-specific books such as the GW-BASIC User’s Guide, Mastering Turbo Assembler and the Beginner’s Guide to You-Name-It. Finally I had found a book that actually gave me pratical advice on how to become a better programmer. I was surprised to discover that there were in fact people out there who had the same thoughts about programming as me, and even better, they were writing books about it!

I have only read the first edition of this book (the 1993 one), but the second edition has been updated with example code in Java and probably more neat stuff, so I assume it’s even better now.

The Pragmatic Programmer: From Journeyman to Master
by Andrew Hunt and David Thomas

If you are only ever going to read two books about computer programming, this should be the second one.

This book is a great collection of software development techniques and practical programming advice. Simply put, if you read this book and apply the techniques and principles described here, you will most likely write better programs and have more fun doing so.

Peopleware: Productive Projects and Teams
by Tom DeMarco and Timothy Lister

Software managers don’t manage software. Project managers don’t manage projects. They all manage people!

In order to understand how to write good software you must first understand the people who write it. This book will help you do just that. If you are anything like me, you will probably see yourself in much of what is described here, and even if you don’t, you are likely to learn some new things about programmers, how they act and how they think.

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
by Frederick P. Brooks

There is no silver bullet.

This book is so timeless it’s scary. Even after more than three decades, the topics covered by these essays are just as relevant today as they were in 1975. The book proves, once again, that people never change. We still do the same mistakes over and over again.

Again, I have only read the first anniversary edition, so I’m not sure what the second edition of the anniversary edition (does that even make sense?) is all about, but I’m sure it can’t be anything bad. Go buy it and find out for yourself!

The Psychology of Computer Programming: Silver Anniversary Edition
by Gerald M. Weinberg

Programming is a human activity. Humans are strange creatures who behave in odd ways sometimes. Programmers possibly even more so than others.

This book explains how programmers think and how they act as human beings. Again, the argument that peolpe really don’t change applies, so the book is just as relevant today as it was in the 1970s. It’s fascinating to read how the problems of punch card programmers on ancient mainframes were exactly the same as the challenges facing software developers today. If nothing else, the book will give you an insight into how programming was done in 1971.

The Design of Everyday Things
by Donald A. Norman

If you are ever going to design anything, ever, you should read this book.

And even if you are not, you should read it for a good laugh. It’s hilarious, although also a bit sad, to see how many flaws in the design of everyday objects that we interact with in our daily lives are almost directly transferable to software development and programming. The mistakes are the same, only the implementations differ. Instead of a buggy program with an inherently complicated user interface you have a door that won’t open or a watch you can’t figure out how to use.