The fundamental premise of “Coder to Developer” is to provide a starting point or practical guide to becoming a well rounded Software Developer. To transcend the basic title of “Coder” and become someone who has a full understanding and command of the entire software development life cycle. Mike Gunderloy, following in the footsteps of authors such as Andy Hunt and Dave Thomas of The Pragmatic Programmer fame, tries to give an insight (opinionated but practical) into what has gone into making him the developer that he is today.
Who is Mike Gunderloy?
Before I go onto to tell you what I thought of this book and what you might get out of it. Let me just tell you a thing or two about Mike Gunderloy. At the time of writing this book, Mike was a .NET developer working as a software consultant for “Larkware” his company which is still around. At the time Mike had many years of experience as a professional programmer. So he definitely knows and knew his stuff. In more recent times (2006) he has moved on to be Ruby on Rails developer.
He keeps a personal blog which it’s tag line describes it as being “Notes on Rails and other development”. I’ve pop by there a few times and found some very interesting links. If you pop over to his professional website you can get his email address to contact him and you can also find him on Twitter as @MikeG1.
Overview
The book tackles practical topics that are rarely emphasised in technical books, but are of extreme value and importance in real world production applications. Dry and boring ones such as logging, requirements, schedules, intellectual property. Of course you may be into that kind of thing, but I know that I don’t find them the sexiest of topics.
The book is broken down into 15 chapters which goes to varying levels of depth. At times Mike talks in very specific terms about technologies and concepts from Windows development and the .NET framework. He also provides us with an example application (a download tracker) which he tackles from time to time while moving through the book and its development life cycle.
Stand out chapters
- Planning Your Project
- Organising Your Project
- Using Source Code Control Effectively
- Coding Defensively
- Preventing Bugs With Unit Testing
- Pumping Up The IDE
- Digging Into Source Code
- Generating Code
- Tracking And Squashing Bugs
- Logging Application Activity
- Working With Small Teams
- Creating Documentation
- Mastering The Build Process
- Protecting Your Intellectual Property
- Delivering The Application
Above I’ve listed the chapters in Mikes' book. I want to talk a bit about some of the chapters I found quite interesting while reading this book. There are a lot of valuable insights to be had throughout, but here are a few of my highlights.
Tracking and Squashing Bugs
For all of my professional career to date, I’ve work in large organization with defined processes around bug management and tracking. In fact much of what is discussed in this book from a process POV I’ve never given any real deep thought too because of that fact. In one sense this chapter didn’t tell me anything I didn’t know, but in another it was incredibly revealing. Of course different organization have different processes also, so the one Mike was detailed did differ from what I’ve been used to. Hence, it made me sit up and pay attention.
One of the areas I don’t have much exposure too as a programmer where I work is “Risk Management”. The way in which Mike talks about risk; how it factors into his work flow and the way in which he managed it (through statistically probabilities) resonated strongly with me. In the same way as risk management caught my attention, so too did Mikes take on “Zero Bug Goals/Mentalities”. I suppose at the time the time I was on had just committed to a zero bug goal from that point on, the quote that hit me hard was this:
Microsoft on Windows 2000 "Rather than focus on a zero-bug goal, they focused on having zero unfixed bugs that required fixing"
Finally, the main reason I really enjoyed this chapter was Mike would go into detail about his own particular independent software development set-up. For instance, when advocating for robust testing for your application, Mike describes his own test set-up (a lot of PC in his home office). I guess I just loving hearing about that kind of thing, a developer going out there and making it on their own!
The thing that absolutely rocked this chapter for me was Mikes advise for lone developers, and how they might go about testing their software without a dedicated QA team.
Logging Application Activity
Honestly, I would never have thought that anyone could say so much about logging. What Mike managers here was astonishing. Now some people out there will find nothing new here, and this is a chapter where Mike goes into specifics about Microsoft Windows development tools such as the Microsoft Windows Enterprise Instrumentation Framework (EIF). But you see, there were some concepts in here that I had never encountered. Some of the frameworks that exist for .NET development sound quite incredible and of course this is an old book so I could only imagine what kind of cool technology exists now.
I’ve read a bit about logging as a concept before and Mike just hammered home some of the ideas I’ve been reading.
Creating Documentation
I don’t know how it was possible to write so many interesting things about documentation, but Mike did it. I suppose on one level it might be down to where I work, and having those kind of concerns taken care of for me by other engineers. Mike explores first the importance of documentation, both from the POV of the customer using your products and to the engineers working on with your API (if you are on a small team, or producing an API for someone to use). What interested me the most was the idea around information architecture, how do you make good documentation (for the end user), how can you avoid make something which is based on “Mystery Meat Navigation”. Who would of thought that information architecture was something that would give me kicks? I know I didn’t.
In another chapter, “Generating Code”, Mike explores the idea that you might be able to automatically generate a certain amount of your documentation as well. Which, though not a new concept/idea, is always a good to remain engineers that it’s a possibility.
Criticisms
One of the criticisms I’ve seen levelled at this book on-line is its heavy use of specific technologies while discussing various topics. On one level I would agree with these criticisms, it would of been nice to know I was getting myself into a Microsoft Windows/.NET take on becoming a better developer. Outside of that though I don’t think it’s completely valid. Using platform/technology specific examples exposes you to possibilities. I’m not a .NET developer, but when exposed to the types of ideas that can be found in that stack; as a result I wanted to know if the same was available for the systems I use and believe for. I believe you should always be exposing yourself to new ideas and concepts. It is true that a book might not be the best place to be exposed to those kind of ideas, but I didn’t think it took away that much from the experience.
Conclusion
Would I recommend “Coder To Developer”? It’s a well written book attempting to tackle very complex topics which at times get sidelined but reveals very interesting nudges of information all the same. I enjoyed the book and feel I was able take away a lot from reading it.
To purchase Coder To Developer head on over to Amazon and grab yourself a copy.
References: