Talent is Overrated: Book Review
Date: 2008-12-29 20:52:59

== The Book

http://www.amazon.co.uk/Talent-Overrated-Separates-World-Class-Performers/dp/1857885198/ref=sr_1_1?ie=UTF8&s=books&qid=1230535500&sr=8-1[Talent is Overrated] by Geoff Colvin

== The Review

I came across this book on http://twitter.com/jchyip[Jason Yip's Twitter feed] while the idea of 10,000 hours to become an expert at any given skill was being discussed. I'm reading http://www.amazon.co.uk/Outliers-Story-Success-Malcolm-Gladwell/dp/1846141214/ref=sr_1_1?ie=UTF8&s=books&qid=1230535786&sr=1-1[Outliers] as well and the two books seem to complement each other quite well.

I'm interested in how we can apply deliberate practice in software development, perhaps using the medium of coding dojos, to become better developers in a more effective manner than just normal practice.

== What did I learn?

* The first section of the book is spent dismissing the notion that innate talent is what makes people who are world class in their field so good at what they do. Research is cited showing that it is only through *10,000 hours of practice* that world class performance can be achieved. Although I agree that the best performers do have to put in a lot of practice to become good at what they do, I'm still of the opinion that people have some skills they are naturally better at than others and if these are the ones they chose to practice they are always going to be better than someone who didn't start off with that ability. I think this idea is discussed more in Outliers than in this book though.
* *Deliberate practice* is described as something which is:
 ** Designed to improve performance
 ** Can be repeated a lot
 ** Feedback continuously available
 ** Highly demanding mentally
 ** Not much fun

+
Some examples are given of people who have engaged in deliberate practice and approach seems to entail finding something very specific that you want to improve on in a practice session and then working on that repeatedly while http://groups.google.com/group/software_craftsmanship/msg/ed1e9e4b01261016[maintaining the self awareness to analyse how it is going] and adapt accordingly. Benjamin Franklin's approach to improving his writing involved comparing his efforts to those of the Spectator, the standard which Franklin strived to reach. Software development wise perhaps this could involve picking an area of improvement such as trying to write code using small methods (less than 5 lines per method for example) and then comparing that code to some open source code written by someone like http://butunclebob.com/ArticleS.UncleBob[Uncle Bob] for example, analysing where improvement is still needed and then practicing in that area.
* I am keen to work out whether we can *design coding dojo sessions to be about deliberately practicing in a certain area*. From the http://www.markhneedham.com/blog/category/coding-dojo/[dojos] we've run in Sydney we've found that the more specific we can make the problem to solve the more we gain from the session as the practice is much more focused. Areas of practice for future coding dojos could be: Refactoring a code base, using tiny types, coding in a functional way, and so on. The key with any approach that we take seems to be to ensure that the tasks we're working on are just slightly above our level of competence, an idea I have previously read about in http://softwarecraftsmanship.oreilly.com/wiki[Apprenticeship Patterns] and http://www.markhneedham.com/blog/2008/10/06/pragmatic-learning-and-thinking-book-review/[Pragmatic Learning and Thinking].
* With regards to improving skills, three models are suggested for non-work related practice:
 ** *Music Model* - Break down activity into smaller pieces; analyse each for ares of improvement; repeatedly practice each area. This is a useful approach for practicing presentations and speeches where we know beforehand what we want to do.
 ** *Chess Model* - Study real games; practice the situations from the games; compare what you did vs what happened in the real game. This approach has been applied in business for many years, disguised as the case method.
 ** *Sports Model* - re-learn the basics of the field; simulate situations that may come up in real life.

+
I think some parts of each of these models can be applied to software development. From the sports model we can take the idea of re-learning the underlying principles of computer science and how our code is actually working behind the abstractions languages create for us; from the chess model we can take the idea of considering different options when we have a choice to allow us to select the one which will best solve our problem; and from the music model we can take the idea of identifying specific areas of improvement in our work and relentlessly working on these.
* *Domain knowledge* is identified as being one key area where experts have a very important advantage over everyone else. Having a mental model of the domain that we work in provides a framework for learning new information and allows us to learn new information in context rather than on its own, making it much more likely that we will remember this information. I think this is particularly applicable in software development and is something I've forgotten about lately. Knowing the industry that you're working in makes you much more effective when it comes to understanding what users need and what features will be the most valuable to them.
* Closely linked to this idea is *chunking of information* to allow us to hold more data in our memory. The example given is around expert chess players being able to remember the positioning of pieces on a board much better than novices since they see the moves which have happened rather than memorising the absolute positioning of the pieces. This can be applied when reading code bases - I've noticed that people more experienced at doing this than myself are able to notice patterns more easily and can separate noise and signal much more easily.
* I found it quite interesting that the author speaks about *creating organisations which are all about building people*. This is a very similar idea to that of creating http://blog.scottbellware.com/2008/12/learning-organization.html[learning organisations] which I came across while reading http://www.markhneedham.com/blog/2008/12/20/lean-software-development-book-review/[Lean Software Development]. A failure to create this type of environment in a consultancy, for example, would result in it effectively being a http://dahliabock.wordpress.com/2008/12/10/bodyshopping-is-it-a-dirty-word/[body shopping operation]. The problem is that putting people into the roles that best allow them to improve mean that they won't be working in their strongest role and therefore the organisation is not getting the benefits of those skills. Ideas expressed around creating a balance include encouraging employees to take part in communities and giving them additional 'growth projects'. I guess the equivalent in the software world would be to contribute to open source projects and participate in user groups and mailing lists to gain skills and insights that we would not otherwise gain.
* The *importance of feedback* is also emphasised in helping people to achieve great performance. I'm not convinced that the typical approach to reviewing performance is the optimal approach and my current thinking around this is that it might be useful to measure out progressing skills in different areas against the http://pragmaticstudio.com/dreyfus[Dreyfus model] and then work out ways to progress to the next level. Retrospectives on agile projects are a way that we share feedback at a project level but I think we need to create shorter and more effective feedback cycles for individuals to help them to get better.
* The idea of *letting employees choose their own projects* is raised as one which can help lead to greater innovation inside organisations since people will be working on something they are passionate about and are therefore going to do a much better job at it. http://googleblog.blogspot.com/2006/05/googles-20-percent-time-in-action.html[Google's 20% time] is an example of this idea proving to be reasonably effective. I don't know how that would be achievable at a project level but certainly on agile projects an approach which lets developers choose which stories they want to work on tends to be the most effective approach from my experience.
* The myth that innovation comes about by accident is addressed and instead an alternate theory, that *"the aha moment comes out of hours of thought and study"* is proposed. The majority of innovations are shown to have been derived from something that previously existed but was modified to be even better. I think this is true in software too. For example, http://code.google.com/p/mockito/[Mockito] is the predominant Java mocking framework at the moment, and although it allows mocking/stubbing in a different way than was previously possible, that idea would not have been possible without JMock and EasyMock having been invented first. It is also suggested that creating an environment where time is available for people to try things out is important if we want innovation to actually happen.
* The idea of motivation is touched on - the suggestion being that *intrinsic motivation is predominant* in people who are prepared to put in the practice necessary to become world class at something. It is also suggested that for some people practicing skills puts them in a state of http://en.wikipedia.org/wiki/Flow_(psychology)[flow], meaning that practice is actually enjoyable and not hard work as had been suggested earlier.

== In Summary

This area of study still fascinates me and this book certainly gives a great deal of insight into the way that world class performers have made themselves so.

Software development wise I'm looking forward to reading Corey Haines' thoughts on how ideas such as his http://programmingtour.blogspot.com/[pair programming journeyman tour] can help us to improve as developers and seeing how our understanding of the value of coding dojos continues to develop.