Code Obsession

TL;DR - If you care about software development at all, read this book now! This book is a condensation and distillation of more than 40 years of industry experience. It is an amazing read. The book expresses the concept of professionalism in the clear, simple (not simplistic,) unapologetic style that Bob uses in all his writing. At a short 204 pages, you can read it in a weekend (like I did.) Having been involved in Agile (XP, XPish, ScrumBut) projects for several years and recently in the software craftsmanship movement, many of the concepts in the book were familiar. The chapters on Saying Yes, Saying No and Estimation really spoke to me. I have had many experiences where I have agreed to "try." Now I see the danger of that statement clearly. I have also had experiences where I have stayed firm on my estimates and been encouraged to feel as though I was not a committed team player. I now have additional tools to help me combat that feeling and take professional actions desp...

I read it, I liked it, Blogger ate my post. First, it helped inspire me to try Linux, which is no mean feat for a die hard Windows guy like me. (I haven't even turned on my iMac in the last year.) Second, the management essay added at the end was the most important part to me. The main point being that OSS works well because the participants self select and are passionate about that they are spending their precious time on. Cube dwelling devs may not be so passionate or skilled, and their output reflects that.

Chad Fowler's book is all about building a successful career in software development.  When I read that sentence, 2 questions immediately come to mind: what's in it for me (as a developer)? and what's in it for me (as a business owner/manager/project manager/etc)?  Well the answer to the first question is pretty obvious: what I get out of a successful career is happiness, money, purpose, etc.  What does my employeer get out of it?  Well, a happy, motivated, driven developer.  Why does that matter?  Happy, motivated people produce more and better work.  So now we have covered the most rudimentary of why, let's look at how this book helps. There are 5 sections in the book: Choosing your market Investing in your product Executing Marketing... not just for suits Maintaining your edge Choosing your market talks to the importance of being aware of what you do and how it related to the larger picture.  Are you .NET developer?  Why?  Why aren't...

This book, available for free download on InfoQ.com, is an excellent intro to/summary of Evans' DDD book. What I really appreciate about this book is that at 104 pages it is short enough I can recommend it even to my near-illiterate developer friends who would never attempt to tackle Evans' 560 pages. ;-) The definitions of the key terms in Domain Modeling are clear and concise. The examples are short and simple which forces them to cut straight to the heart of the concept they demonstrate. While this book doesn't go as deep as Evans' book, it is excellent as a review or intro. I intend to have my entire team read through it asap during our ongoing training. Key to Domain-Driven Design is the concept of the Ubiquitous Language. This book helps define the terms used in the Ubiquitous Language of software development. Communication is the key to success in our industry and having a common language facilitates quick, clear communication between developers. Read the ...

Robert Glass' Facts and Fallacies of Software Engineering was an interesting read because it focuses so much on the research that has been done in our field. Contrast that with the much more common anecdotal teaching style and this book becomes very valuable for the industry. Honestly, most of the facts are well known, they just may not be accepted as facts. This is a quick read and worthwhile. The emphasis on research and evidence alone is worthwhile.

I recently read Pete McBreen's Software Craftsmanship: The New Imperative. This was a pretty interesting book and it was excellent timing because I finished it just before Dan North published his post that set off an avalanche of debate about the topic. What can I say... Hmm. After all the debate, I still consider myself to be a craftsman. Why? That is an interesting question. I think that there is misunderstanding about the movement. I think craftsmanship is all about building maintainable software and training the next generation of programmers to build maintainable software. As a professional, ROI is king. Everything I do, from personal study to TDD to CI to leading group discussions about the craft is so that my team can produce better, more maintainable software that produces long term business value. This is what makes me a craftsman. I have seen too many projects lose focus and become unmaintainable piles of crap. I have seen too many failed rewrites. I have se...