Mark Needham

The Book

Outliers by Malcolm Gladwell

The Review

I came across this book following recommendations by Jason Yip and Steven 'Doc' List on Twitter.

I've previously read The Tipping Point and Blink and I like his easy going style so it was a no brainer that I was going to read this one.

I found that this book complimented Talent is Overrated quite nicely. Outliers covers how the story of how people became the best at what they do whereas Talent is Overrated focuses more on what you need to do if you want to become one of these people.

What did I learn?

• Both this and Talent is Overrated refer to the paper written by K. Anders Ericsson about Expert Performance and Deliberate Practice. This is complemented quite nicely by a discussion on the Software Craftsmanship user group. Gladwell doesn't cover the ideas of Deliberate Practice so much and in a lot of the examples he referred to the need for 10,000 hours of practice to become an expert but didn't focus on the fact that this practice needs to be on tasks just above our level of competence. This type of practice is very mentally exhausting and we probably can't do it for more than 4 or 5 hours a day at the most.
• There are various examples talking about the luck involved in being given the opportunity to practice skills which will make us successful, ranging from Bill Gates and Bill Joy to Canadian ice hockey players. The lessons we can learn from here are that not everyone has the same opportunities and in some cases this can be changed by society. One example of this is around Canadian ice hockey leagues where the vast majority of players tend to be born in the first few months of the year because they had a strength advantage over younger children and therefore got picked for province teams and widened the gap over the others. This problem could be solved by creating 3 intakes so that kids born later can compete against others their size.

  I think it's important to note that even if you get the opportunity it still needs to be seized upon and the hard work put in if you are to achieve something.

• There was an intriguing chapter in the book which talked about the Power Distance Index (PDI) and how this varied in different cultures. To paraphrase, the PDI basically describes the willingness of people to speak up to people higher in the hierarchy than themselves. The higher the value the less likely people are to challenge authority. This proved particularly problematic on airplanes where clear communication is necessary between crew members who are at different levels on a hierarchy.

  I think this idea is applied in software development too – when developing in an agile way I have certainly noticed that there is less hierarchy than in a more waterfall team where the architect would dictate how the work is going to be done and the developers would just follow those instructions. In a way it can manifest itself in pair programming where more Junior team members are afraid to challenge the ideas of the Senior team members although I haven't noticed this so much.

• To again reference the chapter about airplane disasters, it was interesting to note that the planes generally weren't crashing because of technical problems, but because of failure to communicate effectively. This is exactly the same in software development where the ability to communicate effectively is at least as important as having good technical skills. As Ayende points out, a lot of our job is social engineering.
• Meaningful work is described as work which has autonomy, complexity and a clear link between effort and reward. This is the type of work which motivates people to put in the effort to become successful.

  This idea of a connection between effort and reward seems to link to the ideas around Risk/Reward contracts discussed in Lean Software Development in that there needs to be some sort of motivation for improvement i.e. a financial reward.

• There is an interesting discussion around Maths and how quickly people tend to give up if they can't immediately solve a problem. Maths is considered to be a skill that you either have or don't have, but examples are given of a different learning approach taken to the subject which allows students to take their time to grasp the ideas.

  I am trying to temper my tendency to do this in my F# learning. Luckily for me there is no rush for me to learn it so I'm taking my time to try and really understand how everything works.

• Cultured cultivation is described as a difference in the way middle class and lower class families raise their children. Parents of the former give their children a sense of entitlement and encourage them to "customise the environment for their best purposes". This sounds very much like the parents acting as a teacher/coach to their children and guiding them on their journey.

  We can apply this in software development by adapting our principles to different situations. For example we can use OO techniques in many more situations if we take the time to consider the problem we are trying to solve. We shouldn't sacrifice our approach just because the problem seems too different to use it.

In Summary

The book is very easy to read but a lot of it is just providing example after example to back up a point made earlier on. It would have been nice to see more ideas around how we can grasp opportunities that come our way rather than focusing so much on the luck element of this.

There are a few other reviews of the book that I found quite interesting to read. Each review approaches the book from a slightly different angle and takes different ideas out.

The Book

Fearless Change by Mary Lyan Manns and Linda Rising

The Review

I came across this book while watching an interview with Linda Rising on InfoQ. She mentioned some ideas from Malcolm Gladwell's The Tipping Point which intrigued me and a strong recommendation from a colleague ensured this book made it onto my reading list.

I am not currently working on a project where I need to instigate a lot of change so I was going slightly against my own principle of only reading books when I need to, but I recalled several times previously when I have tried to introduce what I thought were good ideas and didn't really get anywhere.

I hoped to learn some ideas with regards to handling these situations more effectively.

What did I want to learn?

• How to introduce ideas when people just want to get things done?
• How to balance pragmatism with improvement?
• Beyond persuasion, what can we do to change things?
• How do these patterns relate to what happens in the software industry?

What did I learn?

• I found that several of the patterns identified could be applied when trying to make individual changes as well as organisational ones. The stand out one in this area was 'Time for Reflection' – this spoke of holding a personal retrospective regularly to see what went well, what you could do differently and what was still puzzling. This can certainly be applied whether you are insitigating change or not, and is quite similar to the idea Eric Feng lays out in 'become twice as good in 70 days'. I tried this out for several months last year and while I eventually stopped because daily reflection seemed too frequent, I could certainly see value in this approach if done at the end of each week for example.
• An idea which I was really keen on introducing onto my previous project was Phillip Calcado's idea of Domain Driven Tests. I failed on this occasion from not applying the 'Just Do It' pattern. I had only briefly tried out the ideas Phillip laid out and was therefore unable to come up with good responses to the possible drawbacks colleagues pointed out. I needed to get experience with the idea before trying to champion it.
• Closely linked to this was the idea of introducing ideas on a temporary basis – the 'Trial Run' pattern. We introduce an idea with the premise that if it doesn't work we can just go back to the old way of doing things. This is certainly a useful approach for getting skeptics of an idea to give you a chance to prove its worth. It is also similar to Steve Pavlina's 30 Day Trial technique for introducing new habits, except the habit in my world might be introducing someone to the world of TDD rather than an exercise program!
• A perhaps obvious but nonetheless important idea expressed was the need to have passion for the change that you are trying to instigate. If you don't care then noone else is going to. I am fortunate enough to have the opportunity to work with some very passionate colleagues who display great enthusiasm to try out new ideas in the desire to find a better way to solve problems. This passion mixed in with some serious technical ability has led to ThoughtWorks generating quite a presence in the Ruby on Rails space.
• The authors describe the way that ideas spread as flowing from Innovators => Early Adopters => Early Majority => Late Majority => Laggards. I imagine Ruby on Rails is probably at the 'Early Majority' stage at the moment, having been promoted early on by the likes of David Heinemeier Hansson, Chad Fowler, Dave Thomas, Obie Fernandez, Jay Fields and co. It is interesting to note that these guys probably applied many of the patterns listed in the book along the way to getting Rails more into the mainstream.
• One idea which surprised me was that of finding a champion skeptic for your ideas. This person would play the role of devil's advocate or realist, pointing out the flaws in our ideas. The natural human instinct is to reject the ideas of people who disagree with us but engaging them can lead to us examining our ideas more thoroughly and allow us to come up with sharper ideas which consider any objections raised.

In summary

While I have pointed out some of my favourite patterns from this book, it contains a catalogue of around 50 of them so there are many other ideas that others may find useful.

I imagine this book would be especially useful if you are working in an environment where you want to make significant changes – it provides a lot of information around the best ways to do so.

The InfoQ interview provides quite a good introduction to what else you can expect from this book.