"10,000-Hour Rule" to master a skill

[I D Shukhov]

In another thread Unix made reference to the "10,000 hours to master a skill" rule.

The rule was mentioned in a recent book:  http://en.wikipedia.org/wiki/Outliers_(book)

It has to depend on what the skill is.   I can't believe that it would take 5 years of consistent 40-hour weeks to learn how to repair electric cars or to develop Android apps.   OTOH, it would take longer than that to master organic (chemistry) synthesis.

Whatever the amount of time it takes, though, it's going to take a long time of consistent effort.

[David Randolph]

That rule was not mentioned back when I was looking at  career, but the same effect was talked about. For example, even back in school, I heard about how companies would need to train a newly minted BS EE for 5 years before he could really be productive.

I submit that we have the same effect happening in software development, but we haven't really recognized it. It takes several years of immersion into a job after college before someone really knows what it means to properly design software.

[Richardk]

I think it depends on how smart you are and how hard the problem is.

As noted that doesn't work for mastering a computer language since it will be obsolete before you put in 10,000 hours. On the other hand it might take that long to become a good overall programmer.

With that said, how does that apply to the general public? Sure, if you put in enough time, you'll get better but today it seems that 'good enough' is just that and it can be accomplished in far fewer hours.

It's interesting to note that mastering a skill and money have a strange relationship. Compare ID's organic chemist to our high school level roofing contractor (another thread). The roofer could earn more than the chemist.

Just having read a review but not the book, it seems that the author identified some factors but I don't think that's enough for the success's that he lists to be repeatable. And if they're not repeatable then who cares?

[David Randolph]

Crucial to this discussion is another issue:
The important skills in today's world are the soft ones.

For example, for people on this board, the most important skills are those about how to make money, not the technical skills. Those skills might be how to find a contract without a broker, or how to run a one person marketing organization while trying to keep the technical skills up to date. My trucker friend doesn't have the skills of how to make good financial priority decisions and keeps making wrong choices for his business.

This is why so many people take several years to switch from FTE to running a business.

[John Masterson]

Let's not forget that the "10,000-hour Rule" is a conjecture made by Malcolm Gladwell based on his personal conclusion from research he did for the book.

Like so many things driven by Internet viral spread, it has currently achieved "commonly-accepted truth status".

I think there is something to it, but as is being discussed here, it very well could apply differently to different skill areas.

[Walter Mitty]

It took me a lot less than 10,000 hours to master the skill of assembly language programming.

Of course,  this depends on the skill involved as others have noted.  It also depends on the level of mastery you use as a criterion.  The criterion I'm using is that had the respect of my peers at a research lab at MIT. 

I've learned a lot about programming since then, however.  Some of that is stuff that master programmers using other languages knew way back then.  some of it is stuff nobody knew back then.

I'm going to say that it takes more hours today to get to the top of your game in programming than it did in 1960.  This is mostly because there is so much more to learn.

[unix]

I totally believe the 10,000-hour rule, in any discipline, whether it's assembly language or auto repair.  To master a skill, there are many nuances, plus you need to have repetition for it to sink in.

When I was in the computer science program, one thing that bothered me was how little time they dedicated to something: A semester or two of Pascal, then C, then assembler, then Ada, then compiler design, software engineering, etc.

[TRexx]

When I was in the computer science program, one that bothered me was how little time they dedicated to something: A semester or two of Pascal, then C, then assembler, then Ada, then compiler design, software engineering, etc. None of it really sunk in long-term.

What problem are they trying to solve?

When I studied computer science, the goal was not to master proficiency in a particular language or technology, but to learn concepts. Different courses used different languages primarily to demonstrate how a particular language was better suited to that subject. For example the course on Numerical Methods used FORTRAN and the one on Management Information Systems used COBOL.   One of the best courses was Comparative Programming Languages where each week we had to solve the same problem in FORTRAN, COBOL and PL/1, thus demonstrating each languages strengths and weaknesses.

The course spent little time on the actual language. It was assumed that the student could learn enough on his own to get by.  However the department sponsored non credit workshops run by experts (IBM sent us one of the guys who developed PL/1)  for those who really wanted to learn all the details. 

[PhilFromNY]

You're not spending time just doing a repetitive task. You're also being exposed to uncommon situations. You need to learn what to do when stuff hits the fan. I think calling it mastering a skill is a misnomer. I would call it becoming a complete professional instead.

It also depends on the size of the problem domain. If you're a plumber working on single family houses then you see most situations in a small time period. However if you expand your business to include buildings of three stories or more then you have to start worrying about such things as the energy carried by waste products going down a straight waste stack. You're a plumber in both situations but it takes longer to be a master if the problem domain is larger.

[David Randolph]

Let me add some (un) real world data:
Second Age:
   c. 500 Sauron begins to stir again in Middle-earth
 c. 1000 Sauron, alarmed by the growing power of the Númenóreans, chooses Mordor as a land to make into a stronghold. He begins the building of Barad-dûr.
    1200 Sauron endeavors to seduce the Eldar.Gil-galad refuses to treat with him; but the smiths of Eregion are won over.
 c. 1500 The Elven smiths instructed by Sauron reach the height of their skill. They begin forging the Rings of Power
 c. 1590 The Three Rings are completed in Eregion.
 c. 1600 Sauron forges the One Ring in Orodruin.
Return of the King, Appendix B

I submit that this timeline looks like it took more than 10,000 hours to gain mastery.

 

[Walter Mitty]

One of the things that I imagine Pascal was well suited for was the learning of programing.  Not the learning of a particular programming language, but the learning of programming itself. 

Pascal was really the only language that I enjoyed learning.  The other languages were ones where I put up with the learning in order to obtain the power.  I came along too early for my teachers to use Pascal in their programming courses.

[TRexx]

One of the things that I imagine Pascal was well suited for was the learning of programing.  Not the learning of a particular programming language, but the learning of programming itself. 

I remember reading that as you mentioned, it was developed to teach programming. Apparently the authors were quite surprised and a bit dismayed when people started using it for real work.

Pascal wasn't around when I learned programming. We used PL/C, a variant of PL/1 developed at Cornell for the same purpose.

[Walter Mitty]

I came into contact with Pascal in about 1980.  That was ten years after the first Pascal compiler, and eighteen years after my first programming course.  After learning a little on my own,  I was fortunate to attend a one week course called "Pascal as a Second Language".

It was taught by Kathleen Jensen, co-author of the Pascal User manual and report.  I don't recall her being dismayed at people using Pascal for real work.  You have to mess with the language a little bit in order to make it library friendly.  And a language has to be library firendly to do any significant work without reinventing the wheel every time.

I enjoyed it as a utility language.  I learned Pascal for the VAX and as a consequence I never learned the VAX debugger.  Kind of a shame.  One of the best debuggers in the DEC world. 

In retrospect, I would have stayed in the mainstream better if I had learned C instead.  I sure liked reading Pascal better than I liked reading C.  Maybe that's just the choice of authors I made. 

[I D Shukhov]

I programmed in Fortran from 1978 (first software job) until 1989.   I bought a MS C compiler in 1987 when I bought my first PC.  I did some hobbyist projects using C and was well prepared when I got my first professional C project in 1989.

[Peter Gibbons]

I also bought my first PC in 1987.

Started with Turbo Pascal but quickly switched to Power C.

Unfortunately for me my first paying gig came only in 1994.