I feel like a total zombie this morning. Why? Because I tried to fit too much into my head last night. In the space of time between finishing my tea and going to bed I managed to: -

1. Install and test a tool for making my new Magic Mouse easier to use.
2. Do some typing lessons.
3. Try my hand at a Ruby Quiz.
4. Try to code in Vim rather than TextMate.
5. Read a few more Apprenticeship Patterns.
6. Fire off some emails.

I achieved, in any real sense of the word, frak all. I did too little of too much. In other words I wasted a night and, at this point in my life, nights spent in front of the computer are a precious commodity.

So, I spent my shower time (hey, the internet is all about over-sharing) putting together a schedule for learning. Mainly so that I can get the most out of the time I do spend at the keyboard, but also so I don’t burn out before Cleatus the Fetus makes his/her grand entrance.

I’ve decided to split it out as follows: -

1. Night 1 - Tools. Currently keyboard and Vim, but there are plenty of other tools that I use that I need to go deep on.
2. Night 2 - Coding practice and soft skills. Basically koans, katas and other exercises.
3. Every 2nd Friday - I work a compressed working week, which is HR speak for getting every 2nd Friday off. I’ll use this day (for as long as I can) to work on portfolio projects.

Why am I telling you all this? Well partly because I need to find stuff to write about ;) but mostly because I find it easier to stick to something if I’ve told people about it. In other words, it makes the cost of failure higher. There’s always the temptation to procrastinate, get sidetracked or just generally bugger about. So, in order to try and counteract this, I’ll post at least one thing that I learn from each of these sessions.

Hopefully this will mean that I can manage my learning outside of work without turning into the walking dead. Brrrrrraaaaaaaaiiiiiiiinnnnnnnnsssssss!!!!!!!!!

The title of this post was the reply Enrique Riepenhausen gave when I asked him and Joe O’Brien, amongst others, how you sold Software Craftsmanship to your clients. I had been wondering for a while how you explained the advantages of software craftsmanship to a non-technical client. How do you differentiate yourself from the the competition in a manner that a non-developer could appreciate and understand?

As a developer, and one that has seen (and to my shame, participated in) his fair share of corner-cutting, I understand the need for craftsmanship. I really get the need for the principles laid out first of all in the Agile Manifesto and latterly in the Software Craftsmanship Manifesto. I understand how they make for better software and better relationships, not just within teams but also with the clients those teams create value for. However, I just couldn’t see how you explained that to prospective clients, nor could I see how you could translate it into something that they were willing to pay extra for (at least in the short term). As Enrique correctly pointed out though, you don’t sell craftsmanship. At the time I thought, “Great! Excellent! That’s the point I’ve been missing.” However, afterward, the more I thought about it, the more confused I got. If you don’t sell your craftsmanship credentials, how _do_ you differentiate yourself from the competition? This week I had an experience that not only gave me the answer, it showed me that I was asking the wrong question!

This month I changed my car insurance from Insurer A to Insurer B. I’d been happily insured by Insurer A for the last two years and was always impressed with their service. The documentation that accompanied their insurance was well laid out and easy to understand, their staff friendly, well-informed and helpful, and the price (whilst not the cheapest on offer) was very competitive. This year, they put the cost of insurance up quite steeply and so I went to look for another insurer. Insurer B were a *lot* cheaper. In fact, they were cheapest insurer that I had heard of on the comparison site. I decided that I would go with having extra money in my pocket rather than sticking with the insurer I knew, and so I moved.

And so it came to pass that my insurance documents came through from Insurer B. So I got on the phone to Insurer A to let them know that I was canceling. They could not have been more helpful. Within a couple of minutes I had canceled my existing insurance, been forwarded proof of my no claims discount and informed of everything I needed to know as we went along. Insurer B, on the other hand, called me at work, tried to sell me features that I’d already explicitly declined on sign up and then tried to sell me various other products that they happened to have.

Now, the point here (and this is crucial) is _not_ that the cheaper insurer turned out to be the worst. The reason I moved to Insurer A in the first place was because my previous insurer had been more expensive. That previous insurer had also tried it on with the “trying to sell me things I’d already declined” shenanigans. The point here is that, even though I was canceling my insurance with them, Insurer A still went above and beyond to help me. Their focus was on me as a customer, even though they were about to lose my custom. That impressed me to the point where I will be taking my insurance out with them again next year, despite the extra cost.

So far, so very “Thought For The Day”. How does this relate to my software craftsmanship question? First of all, it showed me that I was asking the wrong question. I was approaching software craftsmanship from the point of view of selling it. Making more money because you were crafting a better product. This is, I now believe, the _wrong_ way to look at it. We are craftsmen because we want to build better software, because we want to have good relationships with our customers and because we want to further the state of the art in our chosen profession, not because we want to get paid more. Secondly, Enrique is right. We don’t sell craftsmanship to our clients. They come to us because they have heard that we are great at what we do, or they have seen examples of our previous work. Like my experience with Insurer A, those we do business with will sing our praises because we always put them (or at least their best interests) first and foremost. More than that, they will come to _trust_ us. Once that happens the money will follow, only by that point it will be a bonus over the true reward of craftsmanship. The pride of a job well done.

In the spirit of refactoring to keep things clean, I’ve decided to move the book list from the original post to here. This should hopefully make it easier to use. Please add any new recommendations to this list.

Agile Software Development: Principles, Practices and Patterns (aka PPP)

Apprenticeship Patterns (if you’re thinking of reading Apprenticeship Patterns, Hashrocket are covering it in their Bookclub)

Clean Code

Mastering Regular Expressions

Object Thinking

Smalltalk Best Practice Patterns

Software Craftsmanship

The Art of Unix Programming

The K & R Book

The MIT SICP course (aka The Wizard Book)

The Passionate Programmer

The Pragmatic Programmer

The Refactoring book (original) (Ruby)

Working Effectively with Legacy Code

Any book by W. Richard Stevens but Advanced Programming in the Unix Environment and the Unix Network Programming Volumes in particular.

Finally, some great advice given to read through the man pages on your system. This also applies to reading the code for any application/plugin/gem etc. that you use. You can learn a lot from other people’s code/documentation.

Got my copy of Apprenticeship Patterns this morning. I’ve decided, after @chrismcg mentioned it, to follow along with the Hashrocket Book Club. I’ll be blogging my $0.02 here if you want to join me.

I’ve also updated the History Repeating post to include the titles I missed from the original post and to add those mentioned in the comments. Keep ‘em coming and I’ll continue to add them.

The more observant amongst you may have noticed that the blog’s style changed half way through the day today. That was because (apparently) the original style that I used was hard to read on non-Macs. Never one to pour salt on wounds, I’ve changed it something a little easier on the eye ;)

On the Sunday after the Scottish Ruby Conference this year, I found myself hungover and starstruck in the company of some of the smartest developers I know (and some I was just meeting for the first time). I say this not to kiss ass, but to set the scene and lend weight to what follows.

The topic of conversation fell upon the tendency of younger developers in general, and the Rails community in particular, to invent some hot new coolness that is actually just a wheel reinvented. Some were arguing that this was borne of ignorance (willful or otherwise), others that it was because of the lack of willing to use languages other than Ruby. Personally, in my own limited experience, I think that it is probably a mix of both, but leaning more towards the former.

It’s a well-know phrase/cliche in the Unix world that,

“Those who do not understand Unix are condemned to reinvent it, poorly.” Henry Spencer

This is as true in software development as a whole as it is to Unix in particular, and something that I have often wondered how to counteract in my own development. So I (eventually) asked the question I ask most coders I meet that are further along the road than me,

“How do I, as a novice developer, get the knowledge of history that you guys have achieved through living and working it?”.

I have decided to share the answers I received, both from the original question and from the follow-up tweet I sent, as there is some real gold here.

First and foremost, and perhaps to be expected from software craftsmen, was the advice to sit with better coders and learn firsthand from them. However, not all of us have access to such a resource. Furthermore, in Software Craftsmanship, the onus for learning is placed on the apprentice and not the master (or at least on the individual rather than those he/she learns from). As such many books were suggested, the list of the recurring and noteworthy has now been moved to a post of its own for ease of use.

Of these books, I’ve already read The Pragmatic Programmer, which lit the fire in the first place and cannot be recommended highly nor often enough, and The Passionate Programmer, which is an excellent companion to The Pragmatic Programmer. I’ve also read Uncle Bob’s Clean Code book and am now following up with the PPP book (it was recommended to me that I read them in this order). However, I think I’m going to put the PPP book down for just now and read Apprenticeship Patterns first. This book, I hope, will give me the foundation for the rest of the books. The reason that I’m reading them as it were. I then plan on reading The Art Of Unix Programming as it contains a lot of good history as well as good advice. I’ll then return to the PPP book.

Throughout all this reading, I’m going to attempt the SICP lectures as well, as they are supposed to be as much practical as theory. However, better folk than me have tried and faltered, so I’ll need to wait and see how I get on.

Anyway, I hope that you get something out of this. Please post comments with any books/resources that have helped you, or even just argue the merits or otherwise of the suggestions made here.

For my part, I will continue to blog as I go on with these books and related learning.

Finally thanks (in no particular order) go to Steven Baker, Jeremy Hinegardner, Chris McGrath, Alan Francis, Graeme Mathieson, Joe O’Brien, Jim Weirich, Randall Thomas and Bruce Williams for their input and patience in the face of many a noob question.