6 Books That Should Be On Every .NET Developers Bookshelf

As I’ve been working on my current project, I’ve found that many freshman developers who want to get better often have a hard time navigating the huge amount of resources out there to improve their skills.  It’s hard to commit given the cost of some of these books (usually at least $30 a pop) and the time it takes to make it through them if you don’t know where to begin.

IMO, there are six books which are must reads for any serious .NET developer with aspirations for architecture (I’d probably recommend reading them in this order, too):

  1. Pro C# by Andrew Troelson which covers just enough about the CLR and the high level concepts in .NET programming with enough readability to not put you to sleep every time you crack it open.  Even if you never use some of the features of the platform, it’s important to know what’s possible on the platform as it influences your design and implementation choices.  While the “bookend” chapters aren’t necessarily that great, the middle chapters are invaluable.
  2. Framework Design Guidelines by Cwalina and Abrams which provides a lot of insight into the guidelines that Microsoft implemented internally in designing the .NET framework.  This is important for writing usable code, in general.  I tend to think that all code that I write is — on some level — a framework (even if in miniature).  Many otherwise tedious discussions on standards, naming, type/member design, etc. can be resolved by simply referencing this book as The Guideline.
  3. Design Patterns by GoF all too often, I come across terrible, terrible code where the original coder just goes nuts with if-else, switch-case statements…basic knowledge of how to resolve these issues leads to more maintainable and easier to read code.  At the end of the day, design patterns are aimed at helping you organize your code into elements that are easier to understand conceptually, easier to read, easier to use, and easier to maintain.  It’s about letting the structure of your objects and the interactions between your objects dictate the flow of logic, not crazy, deeply nested conditional logic (I hope to never again see another 2000+ line method…yes, a single method).
  4. Patterns of Enterprise Application Architecture by Fowler My mantra that I repeat to clients and coworkers is that “it’s been done before”.  There are very few design scenarios where you need to reinvent the wheel from the ground up.  For business applications, many of the common patterns are documented and formalized in this book (to be paired with Design Patterns).  This and Design Patterns are must reads for any developer that is seriously aspiring to be a technical lead or technical architect.  As the .NET framework matures and we diverge from the legacy programming, understanding design patterns is becoming more important to grasping the benefits and liabilities of designs and frameworks.  For high level technical resources, it’s important to understand how to write “clean” code by designing around object interactions; design patterns document these commonly recurring interactions.  It is also a vocabulary and set of conventions by which programmers can communicate intent and usage of complex graphs of objects.
  5. Code Complete 2nd Edition by McConnell While not C# or .NET specific, it delves into the deep nitty-gritty of the art of programming (and it’s still very much an art/craft as opposed to a science). Too often, we lose sight of this core principle in our software construction process in our rush to “make it work”, often leaving behind cryptic, unreadable, unmaintainable code.  Some of the chapters in this book will definitely put you to sleep, but at the same time, it’s filled with so much useful insight that it’s worth trudging through this behemoth of a book.
  6. Pragmatic Unit Testing in C# by Hunt.  This book, perhaps more than any of the ones listed above, gives a much more practical view of the how’s and why’s of good objected oriented design.  Designing for testability intrinsically means creating decoupled modules, classes, and methods; it forces you to think about your object structure and interactions in a completely different mindframe.  Test driven development/design is good to learn in and of itself, but I think the biggest thing I got from reading this book was insight into the small changes in code construction for the purpose of testability that yield big dividends in terms of decoupling your code modules.  I think that once you read this book, you’ll start to really understand what it means to write “orthogonal code”.

Good luck!

You may also like...

8 Responses

  1. I would also recommend "Design Patterns in C#" by Metsker.

    Specifically for C# folks, of course. 😉

    Great post!


  2. Bob Saggett says:

    I’ve got most of these though Code Complete is first edition. I have to disagree on Pro C# though. This is a terrible book that was a complete waste of money. There are far better C# books out there.

  3. Chuck says:


    The Troelson book has its strengths and weaknesses, but I like that it covers a broad spectrum of the .NET framework and I think that the middle chapters are particularly important/significant as it covers just enough of the nitty-gritty of the CLR and .NET including somewhat advanced topics like reflection and dynamic assemblies. The chapters on eventing and multi-threading are also well written, IMO.

    There’s also something subtle about the examples. I like that changes from one example to another are highlighted with bold. I the end, you could probably substitute this book with another .NET/CLR book, but I chose it for its readability and breadth of content.

  4. Mark Rendle says:

    I have 5 of the 6 (haven’t got Pragmatic Unit Testing) and I agree that they are all essential. The one book I would add, and this is regardless of your language or platform, is Uncle Bob’s "Clean Code". That book has had the greatest positive impact on my coding in 20 years.

  5. Jef says:

    Great books list, thanks for the post.

  6. Rob Bowley says:

    5 massive books missing in my opinion, all actually dealing with more real world situations and application of knowledge:

    1. Agile Software Development, Principles, Patterns, and Practices by Robert C Martin
    2. Refactoring by Martin Fowler
    3. Working Effectively with Legacy Code by Michael Feathers
    4. Refactoring to Patterns by Joshua Kerievsky
    5. Clean Code by Robert C Martin

    All of these are much more likley to inspire and improve a junior developer’s skills than something like GoF which, whilst a seminal work, is frankly quite dry and difficult. Patterns, when incorrectly applied are worse thanusing none at all.

  7. Eric Smith says:

    I’m surprised that no-one has mentioned The Pragmatic Programmer by Andrew Hunt and Dave Thomas.

  8. Chuck says:


    While I’m also a big fan of the book, I think that it’s a bit less practical and immediately useful.

    Perhaps a bit of context is necessary for this list: Since about the middle of April, I’ve been dispatched to a client to clean up a mess of a project that was supposed to be delivered in January. Part of the reason for the failure is that the project was staffed with three, fresh out of college, _business majors_.

    It’s pretty amazing that they’ve made it this far and completed what they have, but this list was really a result of me trying to figure out the next steps for these guys if they planned on staying in the implementation side; this was meant to be a guide for their professional development and to prepare them for future projects to stave off failures and missed deadlines.

    Now of course, this reading list isn’t just for junior devs; in fact, it’s probably even _more_ important for senior devs and technical architects. I think that a lack of understanding of basic software construction techniques, language/platform features, and design patterns (which would have been particularly useful in this case in terms of untangling the web of spaghetti code) would have helped in terms of leaving the client satisfied, delivering the project at least a bit closer to the scheduled release date, and creating a more maintainable codebase.

    — Chuck