I've been re-reading a few books lately and in the process it made me start to think of how differently I approach software development than when I first started. It seemed that each time I reach another plateau of understanding one or more books helped me get started on the next level. So in this post I wanted to chronicle my growth (which is still happening!) as a developer using .NET along with the key books that helped me. While I did development before .NET (VB & some Java) I am going to only stick to .NET for brevity.

Phase One: Programmer
When you first learn how to write software you learn the syntax of the language (C# in my case) and how to construct programs using that language. I myself did not go to school to be a developer (I was actually on my way to being a professional pilot) so I had very little pretense on theory or approaches. So I wrote code in a very functional way usually.

When I first started in C# I bought Programming C# from Oreilly. This link is to the fifth edition which covers C# 3.0, but I started with the first edition on 1.0 which is now out of print. I always loved the Oreilly books because they were very direct and to the point. This book was a great help in getting started with the language.

As I started to do more with .NET I bought C# in a Nutshell also by Oreilly. This is not a "how to" book but rather a reference for the C# language and the .NET framework. I turned to this book over and over again to figure out which class to use and how to use it. It was a great companion to the Programming C# book.

Phase Two: Developer
Eventually I was more sure of my abilities that I did not have to concentrate so hard on the coding part of developing software. I had a decent grasp of the language and the framework so I started wanting to write software in a more consistent and productive way. Another consultant told me to pick up Code Complete and it started me on my way to adopting some best practices that I still adhere to today. While it had nothing to do with C#, its content was applicable to any development language.

Also during this time I read (or skimmed sometime) quite a few books from WROX on several areas of programming in .NET which all helped me start to address specific problems in my applications.

Phase Three: Architect (or so I thought)
As I started to get better a writing applications using C#, I was being asked more and more to help design these applications then systems of multiple applications. I was lucky to work with many people who were much smarter than I was and they turned me on to quite a few good resources.

During one design session I was complaining about finding a solution to a particular problem and a colleague shook his head at me and asked, "Haven't you read the gang of four Design Patterns book?" I had to sheepishly admit I have never heard of it and then immediately went out and read it that week. After which I realized I had been describing a picture perfect scenario for an Abstract Factory pattern. I then bought two books on design patterns for C#: Design Patterns in C# and C# Design Patterns: A Tutorial . Using all three books I really started to delve into learning how to write more solid, reusable software.

Phase Four: Team Lead
Once I had been the architect or lead developer on a few projects I was being asked to lead development teams on bigger projects and that when I started to dabble in the project management and business analysis side of the software development lifecycle more. Either I was frustrated by the people in these positions or the project was small enough where the development team took on these duties. Either way I felt there were better ways to do both.

One of the project managers I worked with who was very good at his job loaned me a copy of the Mythical Man Month and it helped me start to think about projects in a wider scope than just the development effort. I was a big help in understanding how to interface with customers and managers and understand how to measure the progress of a project.

I was also given a copy of Software Requirements which gave me a new perspective on gathering requirements and mapping features to coding efforts. At this time I was also introduced to Rational's RequisitePro product which implemented a good deal of the concepts behind the book.

Phase Five: The Reluctant Agilist
By this time I had been leading software development projects for a few years with a good degree of success. I will admit I thought I had it all pretty under control and then a project that went bad started me rethinking how I developed software. Methods that had been tried and true for so long had failed and I was looking for some new ideas. At a new company I was re-introduced to the Scrum process for Agile development. I had heard of this before but to be honest I had dismissed it as the inmates running the asylum. Some of the engineering practices were appealing but overall I was fairly skeptical.

We did a pretty good job of adopting Scrum in all the wrong ways so I turned to Ken Schwaber's two definitive books on the topic: Agile Project Management with Scrum and The Enterprise and Scrum. To be honest I did not come away with much. Not that these are not good books but I tend to learn backwards in that I sometimes need the mechanics of something before I can relate it to the underlying concept. I then downloaded Henrik Kniberg's Scrum and XP From the Trenches and this book helped tie the concepts and mechanics together for me.

Phase Six: Agile Developer
On my next project I took all the things I had learned from our previous rough adoption of Scrum and applied it to our approach. I was lucky in that the management of my new client was very Agile friendly. I now really saw Scrum working and I started to concentrate on how to write my software in a more Agile way.

I attend a local Agile user group and won Practices of an Agile Developer. It was great in two ways because it not introduced some new concepts to me, it reaffirmed some of the lessons I had learned of the past few projects. It was a very easy to read book that provided a lot of information. At the next meeting I won the Art of Agile Development, which built upon everything I had just learned. Both these books made me want to learn Test Driven Development (TDD) better so I then grabbed Test Driven Development in Microsoft .NET.

I recently went back and reread Agile Principles, Patterns, and Practices in C# because when I was first given the book I was still not convinced about Agile and I really only skimmed the material. Going over it now had a much greater impact and there is so much great content that can be applied even outside of Agile that I suggest it to any developer regardless of their approach.

Phase Seven: The Empty Vessel
As I write this I have to say I am a little ashamed at how at some of these levels I thought I really knew everything I needed to know. It has made me really open myself up to learning as much as I can and figuring out the best way to apply that knowledge in my day to day activities. It was humbling to look at the publication dates on some of the books and think, "This has been around for awhile and I am just now learning it!"

There were more books along the way but I wanted to point out the ones that really pushed me to the next level of my development career and I hope to be constantly adding to this list for as long as I write software.