mgroves

I purchased Clean Code by Robert “Uncle Bob” Martin, and I’ve been reading it as part of a) one of my goals set as part of my mentor program, and b) a book-club that I’ve co-started among a small group of developers in downtown Columbus.  As I am typing this, I’m currently at Chapter 8, but as a review and as a personal exercise, I thought I would go back and blog about one or two specific things, per chapter, that stood out as interesting or important.  Even though I’m not even halfway through, I think I could easily recommend this book to any developer who is passionate about coding, no matter their experience level.

Chapter 1 simply lays out the case for clean code: the whats, whys, and hows.  The most interesting part of this chapter is that Martin gets quotes from various prominent contemporaries about their personal definitions of “clean code”.  I won’t give them all to you, but I particularly liked this part of Michael Feather’s definition: “Clean code always looks like it was written by someone who cares”.  I don’t think any code is perfect, but clean code at least strives for perfection.  It’s not only expertise, but effort that can be seen in clean code.  That’s what I think when reading Feather’s definition, anyway.

The other interesting point that Martin makes is that There Will Be Code.  Which is to say, despite the efforts of model-driven development, domain-specific languages, etc, there will always be a need for programming and programmers.  The reasoning for this is pretty sound, I think: until there is some software that can detect intentions (not instructions), those intensions will have to be translated into formal instructions.  Technology will change,  software will change, computers will change, but someone will always need to be around to program them.  I don’t think he’s making a point about job security, but rather one about the necessity of craftsmanship, quality, and clean code: code is always going to be around, so let’s make it good code.