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.