The Bookshelf

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. At bottom, you’ll also find a list of books that I’m currently reading. The worthy ones will gradually appear in the main list, while the others will ignominiously disappear.

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: 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?"

Currently Reading (in no particular order)

About James Kovacs

James Kovacs is a Technical Evangelist for JetBrains. He is passionate in sharing his knowledge about OO, SOLID, TDD/BDD, testing, object-relational mapping, dependency injection, refactoring, continuous integration, and related techniques. He blogs on as well as his own blog, is a technical contributor for Pluralsight, writes articles for MSDN Magazine and CoDe Magazine, and is a frequent speaker at conferences and user groups. He is the creator of psake, a PowerShell-based build automation tool, intended to save developers from XML Hell. James is the Ruby Track Chair for DevTeach, one of Canada’s largest independent developer conferences. He received his Bachelors degree from the University of Toronto and his Masters degree from Harvard University.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Colin Jack

    Cool, yeah thats the way I work too but I have been wondering whether re-reading was a way to go.

    As you say DDD, and I’m thinking maybe EIP, is an exception. Plus its not a very good reference book because key points are sometimes made only once. Mind you I guess thats where using the post-it things to tag pages is useful.

  • james.kovacs

    @Colin – I’ll definitely pick up a copy of Uncle Bob’s book as I’ve had so many people recommend it.

    To answer your question… I tend to read books once and then use them for reference on an as-needed basis. The only one I want to re-read cover-to-cover at the moment is Eric Evans’ Domain Driven Design. Now that I’ve had a chance to internalize the DDD concepts, I think I’ll gain a greater understanding and realize some nuances that I missed the first time. At least that’s my hope… :)

  • Colin Jack

    Yeah in my view its a good book and an enjoyable read, right up there with DDD and Enterprise Integration Patterns in my list of books that I really enjoyed reading.

    Here’s a question for you. I’ve read most of these books at least once and feel I have a good understanding of most of them. However memory fades so I’m wondering whether you find value in re-reading them from time to time or do you just look at them when you have a need (as in I have a complex problem and think a pattern applies, turn to “Refactoring To Patterns”)?

    I ask because there are so many books I want to read and I’m never sure if I’m better reading “Implementation Patterns” or going back and reading on the classic texts…

  • james.kovacs

    @Colin – I have heard excellent things about “Agile Principles, Patterns, and Practices” from a variety of people, but haven’t read it myself. Hence it not being on the list. I should probably read it one day so I can add it to the list. :)

  • Colin Jack

    Good list, and I’ve got those last 4 books in my current to-read list too.

    Only book that I think you are missing that people should read is “Agile Principles, Patterns, and Practices in C#” by Robert Martin, really great.