Talent is Overrated: Book Review
Talent is Overrated by Geoff Colvin
I came across this book on 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 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.
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.
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 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 Uncle Bob for example, analysing where improvement is still needed and then practicing in that area.
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 Apprenticeship Patterns and Pragmatic Learning and Thinking.
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.
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.
Software development wise I’m looking forward to reading Corey Haines’ thoughts on how ideas such as his 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.