Mark Needham

Thoughts on Software Development

Talent is Overrated: Book Review

with 12 comments

The Book

Talent is Overrated by Geoff Colvin

The Review

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.

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 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.

  • I am keen to work out whether we can design coding dojo sessions to be about deliberately practicing in a certain area. From the 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 Apprenticeship Patterns and 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 learning organisations which I came across while reading Lean Software Development. A failure to create this type of environment in a consultancy, for example, would result in it effectively being a 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 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. 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, 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 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 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.

Be Sociable, Share!

Written by Mark Needham

December 29th, 2008 at 8:52 pm

Posted in Books

Tagged with

  • Pingback: Talent is Overrated: Book Review at Mark Needham : Alljobs.com.au resources()

  • Regarding feedback, you may want to take a look at “Abolishing Performance Appraisals”, http://www.amazon.com/Abolishing-Performance-Appraisals-Backfire-Instead/dp/1576752003

  • Pingback: Arjan`s World » LINKBLOG for December 30, 2008()

  • Pingback: Frank Carver’s Punch Barrel / Deliberate Practice and Talent is Overrated()

  • Pingback: Outliers: Book Review at Mark Needham()

  • Pingback: What would you do with 10,000 hours? | Coffee Shop Journal()

  • Pingback: Notes on Geoff Colvin’s Talent Is Overrated -- Hoover’s Business Insight Zone()

  • Pingback: Book Club: Promiscuous Pairing & Beginner’s Mind (Arlo Belshee) at Mark Needham()

  • Bruce Salem

    I just glanced through this book and I take issue with its main idea and its audience. I think that it overstates the role of a conscious goal and understates the compelling role of abilities that appear very early in life. It is true that such talents must be recognized by people close to the young child; but read bios of people we know to have genius or talent after the fact and it is clear that they had that support. We don’t hear about the far greater number of people that “coulda been a Contenda!” because their parents or the school or the Great Depression, whatever, spoiled their chances to develop at a critical time.

    You do software, and so have I. I know that writing good code requires hard work and practice, but I also know that it is much easier for some people to write working programs than it is for others? Can the “talent” be taught? Far more important is how to we get people to find out what they are good at early enough so they can develop skill and without distractions having to do with pragmatism. A big criticism I have of American values is that people here focus too much on what will get them attention and not enough on what unique abilities they bring to the world. I think that the focus on short-term investment in skills will hurt this country and that other regions of the world will displace us as the place to come to create the future because they are more patient about the development of ability.

  • Pingback: “Outliers” by Malcolm Gladwell | 21tiger [新代老虎] books. biz. asia.()

  • Rubens_modeler

    One great thing that I felt that is lacking behind these books is the
    MARKETING and the PUBLICITY these “Great Performers” recieved knowing
    that there are a lot of people out there, that are way better. The team
    and the vision they have for themselves and the imagery they sell for
    others can have an effect on people.

    Also they lack strongly on
    the TEAM they have caring abour them. This books talks about only about
    ONE single person with planned practice, although it talks about
    coorporations, it doesn’t deepened strongly on the fact that these great
    performers have an entire team behind them.

    If the 10 year rule
    is strong enough, then at 40 years anyone (that have more than 10 years
    working on a planned basis) could be a great performer, when we already
    know it is not true.

    So the book, is great for having a partial
    view of what great performance means and have scientific approach which
    is good, but in the reality, not everyone was born is the talent to
    perform it, not even working extremely hard

    Cheers

    Rubens

  • Thanks for the informative post on Mockito. If you are willing to discuss more on unit testing with mockit and unit testing for other languages can check out Mockito Mock forum which is exclusively for unit testing for different languages. It is a upcoming forum and needs support to make it strong so we can have forum where people can share their knowledge on Testing.