Mark Needham

An interesting thing that I've started to notice recently with regards to software development books is that I get a lot more from reading the book the second time compared to what I did reading the book the first time.

I've noticed this for several books, including The Pragmatic Programmer, Code Complete and Domain Driven Design, so my first thought was that perhaps I had read this books too early when I didn't have the necessary context or experience to gain value from reading them.

A conversation with Ade led me to believe that perhaps this isn't the case and in actual fact reading the book the first time pushes your thinking in certain directions even though you don't necessarily realise it.

Coming back to the same book again seems like it should be a waste of time, but I think we have different ideas about what is important when it comes to developing software and therefore the book affects us in different ways despite the fact that the content is exactly the same.

With the three books I mentioned above, the first time I read each of them the advice seemed fairly obvious and continuing with this attitude I struggled to get much out of them.

The Pragmatic Programmer was the first one I re-read and the second time I read it I was getting into the idea of automation around build and deployment so the parts of the book which talk about automation really stood out for me. A lot of other places where automation would be useful became apparent to me from reading the book the second time.

I started re-reading Code Complete after a recommendation from Dave but this time my focus was heavily on the expressibility of our code as this is the area of coding that I am very interested in at the moment. Some of the ideas around variable naming are superb and are directly linked to some of the mistakes I have made recently in this area. It was very interesting for me to see this in a book I hadn't picked up for a few years.

Domain Driven Design is by far the most recommended book amongst developers at ThoughtWorks and I am currently reading it for the second time but this time as part of a technical book club. I have learnt how the specification pattern can be applied on real projects thanks to examples show to me by Alex but in particular the idea of bounded contexts has started to make way more sense to me due to the fact that we didn't follow this idea on a recent project and really suffered as a consequence.

I'm sure when I read these books again I will learn something else that I didn't learn the first or second times.

More than just books…

I think this can also apply to the way that we learn other things such as different styles of programming.

For example, I studied functional programming at university but I never really saw the benefits that we could get from it – the lecturer just pointed out that it was 'better' than using an imperative language which didn't really resonate with me.

Having played around with Erlang and F# a bit and seeing some of the problems we cause ourselves in non functional languages by having mutable state I am starting to understand and like it much more.

The realisation for me has been that we don't have to understand or get everything the first time we do it, there are plenty more opportunities to do that.

And on a book specific level, to make sure I read books more than once to see what I get out of them the next time!