Archive for the ‘success’ tag
Outliers by Malcolm Gladwell
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.
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.
It’s often said that people who are really good at what they do are so good at it because they have narrowed their focus in their area of specialty until they are only doing the thing that they are good at.
To use a football analogy, Manchester United’s Cristiano Ronaldo – widely acknowledged as the best footballer in the world at the moment – is absolutely brilliant when he has the ball at his feet, taking on defenders, getting in shots around the opposition penalty area. So that is what he does all the time. The rest of the team are happy to do his running off the ball and defensive work because they know how good he is at his specialty.
One of the key concepts when working as an Agile Software Developer is that of being a Generalising Specialist. The idea here is that you would have a specialism in one area but also general skills across several others. For example you might have strong Java skills but also the ability to do some DBA work, a bit of build work etc. This should not be done to such an extent that you become a jack of all trades master of none.
One area where I wonder if this can also be applied is knowledge of different programming languages. Taking myself as an example, I have worked in software for almost three years now. During that time I have worked approximately half the time in Java and the other half in C#.
I enjoy the challenges each provide, but I often wonder whether it would be better for me as an individual to just focus on one language. Although Martin Fowler suggests that design skills are more important than specific language ability, even ThoughtWorks job descriptions are looking for a specific language skill-set. Now clearly in my case there is not a massive difference between Java and C# so the skills are completely transferrable.
I would also be limiting the range of projects that I am able to do were I to restrict my focus. However, I would end up being better at the language I chose to pursue instead of splitting my efforts.
Since languages are always changing and new ones becoming popular it makes me think that a language focus would be considered too narrow an area of specialisation.
It would be very difficult to work in an agile team if you only focused on your speciality. Some degree of skill in other areas is necessary. This week I’ve been focused on setting up the build for the project I’m working on, and despite the fact that I will never be as good as the likes of Chris Read or Julian Simpson in this area, I was able to do it.
To refer back to the idea of the Generalising Specialist. I think it is important to have people on the team who have software development skills beyond just their specialism, but to get the best out of them it would seem obvious that they should spend as much time as possible doing things that they are good at.
When you’re working as a Generalising Specialist, it’s not in the interests of being the ‘best’ as an individual, but more about being part of a team which is greater than the sum of its parts.