The following is a list of excellent books that every developer should read. I have focused on technology-agnostic books as I find them the most valuable. I have read every book on this list and recommend them without reservation. As I read more, I’ll update this list.

Full Disclosure: The book links below are through the Amazon Affiliates Program. If you buy a book through a link, I get more books from Amazon to sate my hunger for knowledge.

Becoming a Better Developer

• The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas
  • In terms of biggest bang for your reading buck, The Pragmatic Programmer tops my list. This book is a timeless classic originally published in 1999. It will introduce you to such fundamental concepts as the evils of duplication, orthogonality, design by contract, testing, refactoring, and more. Many of the core development concepts that agile/XP/lean developers take for granted are laid out in this book.
• Release It!: Design and Deploy Production-Ready Software by Michael Nygard
  • How often have you seen the disclaimer, “This isn’t production code.” Ever wondered what production-ready code looks like. In this book, Michael Nygard clearly documents what it means to be production-ready and how to get there. He discusses common concerns that often get forgotten by developers, such as how is the IT department going to support and monitor the application once it goes live. A must-read for any developer who aspires to have their code deployed into production.

Design Patterns

• Head First Design Patterns by Eric Freeman and Elizabeth Freeman
  • This book offers deep insight into core programming concepts in a playful, approachable way. Although it is written for Java developers, it is equally applicable to and comprehensible by C# developers. It covers the classic “Gang of Four” software patterns, but frames them in within actual problems so that you can see how to apply them. You understand the power of coding to interface not implementation, why we favour composition over inheritance, and how to apply the open-closed principle. Even if you have read the GoF, I would highly recommend this fun read!
• Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides (aka The Gang of Four)
  • Another classic, it provides an invaluable reference, but is one of the worst ways to learn design patterns. Often considered a cure for insomnia, it takes a real geek to read this book cover-to-cover. (Yes, I read it cover-to-cover.) If you’re looking to learn design patterns, you would be better served picking up Head First Design Patterns first (see above).
• Patterns of Enterprise Application Architecture by Martin Fowler
  • This book is a fantastic compendium of patterns for building real applications. It covers everything from data access (unit of work, table data gateway, repository, lazy loading) to business (domain model, null object, value objects) to UI (MVC, front controller, MVP).
• Applying Domain Driven Design and Patterns by Jimmy Nilsson
• Domain Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
  • Domain driven design is all about how to build applications where the most important part of the application is your domain or business logic, not the libraries and frameworks on which it is built. How can we structure our code to shield ourselves from the UI, database, logging frameworks, and other concerns? The purpose of erecting these anti-corruption layers is not to live in an ivory tower, but to allow us to focus on the unique aspects of our application – its business logic. Eric Evans provides valuable insights into how to build better software, but many people find his book a difficult introduction to the subject. Jimmy Nilsson’s book provides a practical guide to using DDD concepts along with patterns from Patterns of Enterprise Application Architecture. I personally found Evans book easier to understand after reading Nilsson’s. I heartily recommend both books.
• Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf
  • If you’re building a distributed system, then this is a must-read book. It doesn’t matter whether it will be based on a commercial EAI product (BizTalk, Tibco, …) or plain old .NET/Java/… code. This book documents common patterns for building distributed applications.

Refactoring

• Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
• Refactoring to Patterns by Joshua Kerievsky
  • Refactoring isn’t a discrete task in your development schedule. It is a continuous activity to improve your codebase as you add features. With a good suite of tests around your code, you can safely refactor it as you add features. If you do not refactor, you build up technical debt where each new feature takes longer and longer to implement as the codebase becomes more and more unwieldy. These books provide a catalogue of refactorings to solve common development challenges. Kerievsky’s book continues on where Fowler’s book left off. Both are excellent reads.
• Working Effectively with Legacy Code by Michael Feathers
  • The one big assumption that both Fowler’s and Kerievsky’s books make is that you’ve got a solid suite of tests around your code. But what if you don’t yet? That is where Michael Feathers’ book comes to the rescue. It provides excellent strategies and patterns for safely implementing tests around untested code, which is crucial in order to make non-breaking changes to an existing application AKA refactoring. If you can refactor your code, you can improve your code.

Agile Practices

• Implementing Lean Software Development by Mary and Tom Poppendieck
  • What a fantastic book! Have you ever needed to convince a management type why iterative development, continuous integration, refactoring, or other agile technique was important? Then this is the book for you. Lean development takes its cue from lean manufacturing as pioneered by Toyota and applies the same ideas to software development. It provides a solid grounding in business principles for agile development without the dogma often encountered in other methodologies. If you’re going to read one book on how to manage agile projects, this has to be it.
• Extreme Programming Explained: Embrace Change by Kent Beck and Cynthia Andres
  • Ever wondered how a development team should work on a day-to-day basis? Then this is the book for you. It provides a list of values, principles, and practices for the agile team. It is light on the overall management of a project, but you can look to Lean or Scrum to fill in the gaps.
• Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
  • A good introduction to the Scrum methodology. Scrum is primarily concerned with providing structure between a project team and management. It doesn’t address how a development team should run day-to-day. So it dovetails nicely with Extreme Programming. The book provides lots of anecdotal success stories, which are fun reads. Keep in mind that it recommends an iteration length of one month, which is too long in my opinion. One to two weeks provides a much better feedback loop.
• User Stories Applied by Mike Cohn
  • Use cases and requirements documents are seldom read and often misinterpreted. Is there a better way? For agile projects, look no further than user stories. User stories are a lightweight technique for capturing and prioritizing end user requirements. Mike Cohn provides a great description of the technique and practical advice on how to apply it.
• Agile Estimating and Planning by Mike Cohn
  • • Project estimation is hard. Very hard. Every project is different from the last. If it wasn’t, you’d just pop a blank DVD-R in your burner and copy the previous solution. This book provides practical advice for how to estimate projects, especially agile ones. One of the big revelations for me was the distinction between absolute and relative size of tasks/stories/epics. Humans are fantastic at estimating relative size, but horrible at absolute size. Quick – order these dogs from largest to smallest: Terrier, Poodle, Great Dane, German Shepherd, Chihuahua. Probably not too difficult. Now how tall is a Chihuahua at the shoulder? You’re probably a lot less certain. Mike makes a convincing argument for using story points (comparative estimates of size) combined with velocity (story points completed per iteration) to drive planning. This is a must-read for any developer who ever has to answer the questions “How long is this going to take?” and “When is this going to be done?”