The Talent Code

I read an interesting book couple of weeks ago. The Talent Code by Daniel Coyle. While the whole book is really good I particularly liked the section explaining the "sudden" appearance of extraordinary talents - like Brazilian football players, Bronte's sisters, Mozart, venetian sculptors and painters and so on. How it's believed that all those people were simply born with great talent and their great work just happened. And how the reality was almost a total opposite. The main idea behind the book is that no matter what you do, in order to achieve a world class skill you need to spend 10,000 hours in practice. The skill is basically "neural connections" in the brain. Those connections are created during practice but what determines the level of the skill is the "quality" of those connections. What increases the quality of the connection is myelin by insulating nerve fibers. The 10,000 hours is necessary to create sufficient myelin. What's interesting is that it's not just any practice - the best results are achieved in "deep practice".

The author goes on to explain how any of the great talents already had their 10,000 hours clocked in by the time they were "discovered". How bronte's sisters had written tens of training books before Jane Eyre or Wuthering Heights, how Mozart had his 10,000 hours of practice in very early age and how venetian painters and sculptors got their hours of training in apprenticeship. They were not born great but started from scratch and achieved their greatness by increasingly improving their skills. Interesting thing is that the apprenticeship didn't mean that they would simply paint the whole day and after 10 years became masters. No - they had to do all sorts of things - especially all sorts of "low level things" - like setting the canvas, preparing chisels and so on for their masters. Only after they learnt the basics could they move on to more difficult things. And this is what basically constitutes the "deep training" - choose a goal just outside your comfort zone and keep on failing until you achieve it. Then repeat the process. 

To sidetrack a bit to IT - this is where I think today's system breaks down. Software development is hard. And it only starts with the technical skills - you still need to understand the domain (when working on accounting system you have to have a very solid understanding of accounting), you have to be able to work with people and translate their ideas and feelings about something they've never seen to reality. And there is no magic shortcut - you have to have your 10,000 hours clocked in before you can really do something.  Programming is like writing - just like bronte's sisters - you have to write a lot a lot a lot and about everything you can find - only then your writing will start making sense. Unfortunately, I wouldn't really count any hours spent at school. Maybe it's an unfortunate situation around here - but the IT schools here are set to producing CIO's making decisions on a golf course rather than doing programing or any other actual IT work. To their defense that's pretty much what market here wants - most of the fresh grads from IT will find a good shake-leg work in a bank or MNC paying at least $10,000 per month. I meet quite a few of those people in my trainings or recently, as the banks scale down certain areas, in interviews. 

Anyway, my point here was that only very very few people in IT are willing (or forced) to go through the whole journey - from setting up networks, installing computers, moving to servers, maintaining different operating systems, doing backup / recovery, working with databases, optimizing databases, writing SQL, programming in several languages for several years, understanding patterns going through several releases and so on. And none of that means "I used MS Access in 3rd semester".

Another interesting thing was the difference between masters and beginners. The difference was explained on chess players. The difference between chess masters and beginners is that masters can remember the whole board set up on one look. There is a twist, though. They could only remember the set up from an actual game. If the figures were in random order the chess masters photographic memory vanished. The reason why chess masters could remember the board setup from actual games is because they were not seeing the individual pieces - they were seeing the patterns. 

I picked up the book because I wanted to know more about how people learn - I wanted to understand why after a year of training and working some of my employees are not able to do even a simple task, why is it that they spent a week installing a server without any success while somebody else can do the same work in 1 hour. Why some spend months and months programming a piece of functionality creating a total mess and somehow not "seeing" the simple solution that can be finished in a few hours or days. I used to be especially puzzled about the not seeing part. Even after showing them the simple solution they just couldn't understand it and had to go a big round of all possible wrong ways to arrive at the same solution. I guess some of them see patterns while others see thousands of lines of commands. As a result, in the light of the book's 10,000 hours I start to look very differently at this kind of things. The good news is: it's learnable. The bad news is: it may take 10 years for someone to learn it.

Top 10 Software Development Books for Beginners

This topic has been boiling inside of me for quite some time now. In fact, ever since I hired my first employee in my first job in Asia. I've been always reading a lot of books – even when I had no money I would spend Sundays in MPH or Kinokuniya :-). Even though I've had Safari Books Online subscription like forever (actually since my master's degree thesis) hardly a month goes by that I wouldn't buy a new book.

Anyway, my problem is to select a “reasonable” number of books for my new employees / trainees to read so as to give them essential (really basic and necessary) information and still not overload them to the point when the loose the sight of why they're doing it. Here I must point out that 99% of all people I've interviewed and around the same percentage of people I eventually hired had never read (and pretty much never heard of) any of my top 10 essential books. Most of those were computer science graduates from Singapore, Malaysia, Germany, India, Slovakia, Myanmar, etc.

The books to start with are especially tricky because of a different learning style for different people. Another issue is to avoid (or undo) possible bad habits. I may not be able to stress this enough...but this is realy not about book "reading". Our orientation process means working with those books daily - working out the examples, trying them in different languages and putting the concepts to work first on testing projects and later on real projects.

Put together, Top 10 that my employees / trainees have to bite through looks like this:

1) Test Driven Development by Kent Beck – this is definitely the first and the last book of software development for me. I think without this book made all the agile methodology possible and it pretty much defined way of programming today.

2) Learn To Program by Chris Pine - this is quite a recent addition – in May 2006 when it was clear that most of our development had moved from Java to Ruby, this book replaced Head First Java by Kathy Sierra and Bert Bates. It may sound a bit strange to include an actual programming book so early in the process but it sort of provides a tool or media for further learning.

3) Head First Object-Oriented Analysis and Design by Brett McLaughlin, Gary Pollice, David West - what the hack took you so long guys? This book finally filled in the spot shared by several books on OOP. Even though OOP has been a standard for more than 20 years I still find it one of the most difficult part for people to understand. I even like that the book uses Java for all the examples, because doing those examples in Ruby gives you plenty of opportunity to see Java and Ruby code side by side and to really see the differences between dynamic and static languages.

4) Head First HTML with CSS & XHTML by Elisabeth Freeman, Eric Freeman - what to say...after real hard work with book no 3 this one reads like a comic book. It's really a pleasure to read and I would make it required reading for all web designers.

5) Head First Databases – by I wish Unfortunately, this spot is still open. At this point I would need some down to earth, fun to read, easy to understand non-reference database book. Please let me know if you know of anything

6) Agile Web Development with Rails by Dave Thomas and David Heinemeier Hansson We're getting serious :-). For some of you it may seem like a long time to wait but only around this point I usually feel that my new hires are ready to not only understand but to really appreciate the beauty of rails. With rails simplicity and generators (we use custom made generators that generate pretty much everything besides the business logic) it's just way too easy to slip to monkey coding without actually understanding it.

7) Pragmatic Version Control: Using Subversion (SE) by Mike Mason Again something that universities (and many small companies) should look into. Nothing else to say...required reading.

8) Extreme Programming Explained (SE) by Kent Beck It's really hard to understand and appreciate this book without at some working experience. Everything seems so obvious and natural and yet it's so rarely done that way. At least around this part of the world. Most of the time I hear people say that Asian boss wouldn't approve of agile principle, that Asian boss wouldn't stand two people sharing a computer, but in my experience that's rarely the case. More about it in some other blog...

9. Refactoring by Martin Fowler - after having written some code, you're ready to change it. This book provides not only solutions to common code smells but it also helps you to train your nose for those smells.

10. Beyond Software Architecture: Creating and Sustaining Winning Solutions by Luke Hohmann - this may be a little different from the rest, but it very nicely sums up all the 'other' questions regarding software development and actual deployment. Even though it's not platform specific some sections would deserve a small update...but overall a very complete reference.

okay...so that's my top 10 learn to program (business applications) list. If you didn't find your favourite in there don't worry - it's most probably because this list is meant for beginers. In fact, I cannot believe how much this list changed since only year and a half ago.

what's next? My intermediate top 10 will follow soon :-)