I always find pattern books a weird mixture of
- lots of useful information which I can’t wait to try out,
- an overload of information where I’m desperately trying to hang on to what I can
This normally leaves me in a slightly muddled state.
As much as review, I will try to create some order out of chaos or as Daniel Kahneman might put it “satisfy my human desire for consistency”.
This is the first software craftsmanship book I have read. It was first suggested in some discussions of the LSCC meetup group and it then swiftly made it on to my reading list.
Since this was my first formalish introduction to software craftsmanship, I was glad that this book does a great job of explaining (their view of) craftsmanship.
There are – of course – some controversies in the general blogosphere around craftsmanship:
- whether it is a “thing” (i.e. has any meaningful substance / content)
- whether it is a good thing or a bad thing (see e.g. exhibits A and B)
- whether it is opposed to the discipline of software engineering
While I don’t know enough about the wider craftsmanship community or indeed the software development community to comment much on this, the view in the book seems to be very inclusive (i.e. against divisions between craftsmen on the one hand and engineers on the other) and value based.
I very much agree with the values and philosophy that seems to underlie the patterns discussed in the books and would summarise them as (some related patterns in  brackets):
Take pride in and enjoy what you do
[Unleash your enthusiasm; Nurture your passion; Sustainable motivations]
Learn for life: There is lots to learn and practice. Everyone has the aptitude to learn and practice
[Practice, practice, practice; Expand your bandwidth; Read constantly; The Deep End; Confront your ignorance; Breakable Toys]
Individuals are responsible for their own learning and for structuring their learning
[Draw your own map; The Long Road; Record what you learn; Reflect as you work; Create Feedback Loops; Learn how you fail]
We are embedded into a community of professionals
[Be The Worst; Find Mentors; Kindred Spirits; Rubbing Elbows; Share what you learn]
(Of course the craftsmanship community would summarise their views in their manifesto slightly differently themselves.)
These ideals are very inspiring for me and are the kind of values that I would like to align myself with.
The main part of the book – the patterns bit – is based around strategies to help achieving these ideals. As such this is not really a software engineering specific book, but could be used by anyone with similar outlook, aims and struggles.
For me, the most relevant patterns (the ones I’m itching to try out) at the moment are:
Breakable toys is a way of having toy applications and implementations of technologies you come across and problems you’d like to have a go at solving. It is a way of getting experience without having work / production (quality, criticality etc.) associated with it.
For the last couple of years, I have used the main application ecosystem that I work on as my stomping ground: Whenever I learnt something, I immediately thought “how can this apply to that application” and “where can I safely implement this”. (Of course not nearly every idea made it into the released final product…). Over time this also guided what I considered to be interesting problems.
In future, I would like to decouple this a little bit. Build the toy independently of work technologies and considerations first. Then think about whether there is any use for it in terms of work. This approach has a couple of advantages: Those breakable toys are more “my toys” (rather than just stuff I worked on) and they stay mine. It will also expand my bandwidth (play around with node anyone?) and so, ultimately, give me a more rounded view of development technologies.
Kindred spirits / Find Mentors
In my current role, I get to interact with a great bunch of talented, enthusiastic and motivated developers. I have learnt a lot from these guys. Up until now they have been my main source for kindred spirits and mentoring.
However, their background and what they work on is of course very focussed on enterprise application technology and also the particular business domain (i.e. finance).
In future, I hope to expand my horizon by finding a wider net of kindred spirits and mentors.
(That is why the goal is to go to at least one software related talk / meetup / roundtable-y thing a week in diverse communities.)
Read Constantly / Reading List
During my MSc and when I started my job, I rarely stopped reading finance or technology related books. These were mainly on the primary topics I dealt with at the time (stochastic calculus, fixed income, derivatives valuation on the finance side and Effective & Exceptional C++, design patterns, boost, SQL server programming, agile principles etc.).
As I grew more comfortable with these ideas, my reading slowed a little (I guess the authors would call it “retreat into competence”).
Now, as my interests expand, my reading list is expanding at quite a fast rate.
(So there’ll be plenty more reviews like this one I guess.)
Expand your bandwidth
I guess this is the underlying theme of the two previous points. The key point here is for me to take responsibility for my learning and not just to wait until learning opportunities magically appear.
- Record what you learn
At the end of the day, the thoughts behind “Record what you learn” are why I have started this blog. Since there is so much to learn out there, I need a record keeping mechanism as well as a scratchpad where I can digest and grapple with new ideas.
Anyway, back to the book review: The patterns are presented in a useful straight to the point format: first giving a brief explanation, then some wider context, some immediate actions, as well as related patterns.
For all of the positivity in the rest of the review, let me be a little more critical for a moment:
As the authors themselves admit, the idea behind patterns is not to be “new”, but instead to be tried and tested solutions for common problems. This is definitely true here: I found myself more reminded of things I had done before and wanting to apply those to my current situation.
- Patterns as a language device
Patterns of course have a much broader history than the GoF book and there is a whole pattern movement out there. In my mind the benefit of the design patterns has always been to enable communication with others as well as facilitating your own thought process (being able to give something a label as a shorthand). I am not sure whether this communication aspect will really be something I’ll make use of. I can’t really see myself going to my boss or co-workers and talking about “the long road” versus “a different road”. This doesn’t mean the underlying ideas are not useful, but I am not sure (yet) about using these shorthand labels.
Stretching the craftsmanship analogy
I like the craftsmanship analogy for software (or general life). In some senses, they remind me of the four stages of competence. After a little while though the metaphor wears a little thin: rather than just looking at the main point of the metaphor the authors sometimes rely on incidental aspects of it.
However, even given those (slight) negatives. This is a great book to read, if you are looking to
- re-awaken your enthusiasm for programming
- critically re-examine your current practice
you are short of items on your reading list
(reading through this my “outstanding” reading list increased substantially)