In 2008, Malcolm Gladwell’s book Outliers stated that it takes 10,000 hours of practice to truly master something. That is, however, a ballpark figure and the meaning of the statement has been oversimplified. For example, I’ve been programming on and off for over 40 years. I probably have 10,000 hours under my belt, but I am not even a great programmer, much less a master programmer.
10,000 hours is not 10,000 hours if you’re not consistent
There are few reasons for this. First, I’ve focused on 4 different programming languages at different times, plus dabbled in a couple of others. When you switch languages, a number of concepts transfer, but others don’t. And the funny thing is that concepts that a language doesn’t implement may be used in building it.
For example, JavaScript does not have a native linked list implementation, but if you search the src directory in the V8 Github repository for ‘linked list’, there are 76 commits that mention it. They’re using C’s linked lists under the hood even if they’re not implementing them in the language itself.
Each language has its own syntax and implementation idiosyncracies that you have to learn, not just concepts. Each language has best practices that may not be the best practice in another. I’ve NEVER spent much time in compiled languages, almost always using interpreted ones… BASIC, PHP, JavaScript, Python. I’ve dabbled with C# and Java, done Hello World in Rust, but compiling from source in Linux has always been a bit of voodoo for me. I just download the source, follow the instructions in a tutorial, and cross my fingers.
Then there are the other skills
Then you have all the “tangents” of other skills… Besides learning those languages, I’ve learned underlying concepts of server technologies and system architecture, not from a programming POV as much as a network administrator / sysadmin POV. And I’ve done it multiple times, whether building a large scale website for creating vector drawings in Flash and rendering them to bitmaps or studying to pass the AWS Solutions Architect Associate certification. And then forgotten a lot of it. I’ve learned frameworks and libraries built on top of those languages like React & JQuery for JavaScript and Laravel for PHP… and forgotten them because I learned them for a project and then didn’t use them again.
You will forget things
10,000 hours does not mean you can easily switch between languages, and if you do switch, you begin to experience another reason 10,000 hours is not a magic number: memory decay. As I like to say, if I stop using a language or even a feature of it for a while, I forget it like “high school Spanish.” I got through Spanish 3 in high school, tested into Spanish 4 in college, and got an A. I doubt I understand or speak even 10% of what I knew 30ish years ago.
For example, I’ve pretty much forgotten entirely how to conjugate the past tense with regular verbs, much less irregular ones. I do remember enough to know where my weaknesses are, and I could likely get back up to speed faster than someone else who is beginning at the same level of knowledge. But it would probably take a few months of intensive practice to regain it all.
Ten years ago, I was fluent in PHP, working in a bespoke MVC framework (created by someone else), using Doxygen to map class inheritance hierarchies, and building front ends with JQuery for interactivity. But I pretty much stopped using PHP around 7 years ago and switched to Node. It took me 5 minutes and a few syntax errors to write a Hello World correctly in a PHP repl just now.
<?php $baby = ", Baby!"; echo "Hello World" . $baby; ?>
A more recent example… I built five React projects for the freeCodeCamp Front End Libraries certification in December, but that’s all I did. I wasn’t coding React projects after that. I was doing interview question prep. It’s now February and feel like I know as much React now as when I started. If I read my own code, I understand it, but because so much was scaffolded for me and I stopped reinforcing it, I’d need to go back to docs to start a new React project and get going. I’d just get going faster.
This is the difference between knowing something and knowing something. Ten thousand hours can make you a violin virtuoso. It will not necessarily make you more than slightly competent if you’re switching instruments every 500 hours and trying to become a master of the whole orchestra. The practice needs to not only be extensive, but consistent, and designed to reinforce as well as expand.
It does explain something that seems stupid
Think about what 10,000 hours represents. It’s basically 5 years of working 40 hours a week with two years a week off (with holidays, sick days, and vacation days all in that 2 weeks). You know when you see a job description asking for 5 years experience in a 3-year-old framework? Five years is a good shorthand for how long it takes to become an expert. Take ignorance of the framework and this simplified shorthand, and you have that logical inconsistency in a nutshell.
But 10,000 hours at work is not 10,000 hours of practice, is it?
Professional developers. How much of your work day is spent on email and meetings? How much time do you get to actually code and think through coding problems? When I was writing docs at Microsoft, my manager said that for any estimate, you could only really estimate half of your day would be spent on actual production of work product. The rest would be spent on overhead like emails, meetings, progress/status reports, random questions via IM or someone stopping by your desk…
And since I was only writing code about 20% of the time that I was producing work product, because the other 80% was documentation and tutorials, that meant I was writing code about an hour a day on average. I got better at other stuff. I was a whiz at debugging with the dev tools in the browser because I owned the documentation for that and not only wrote it once, but regularly went back to update for new releases. But while I knew all the dev console shortcuts then, I’ve basically forgotten them like high school Spanish in the 7 years since I left Microsoft.
In fact, since I went into Developer Relations, I spend 10-20% of my time writing code and the rest writing tutorials, creating decks for conference talks and webinars, strategizing how to build and nurture developer communities, strategizing the best ways to show off new features, and herding all sorts of cats—product managers, internal engineers, external developers, product marketing managers, demand gen and social media managers, lawyers, PR, and corporate policy enforcers—to get a single project out the door.
Lastly, it’s not 10,000 hours of new things
The last thing to remember is that you don’t spend the whole 10,000 hours learning new things. If you’re learning to play violin, you’ll spend possibly hundreds of hours on a few beginner pieces. You get something down before you move on, and everything you learned from practicing that piece over and over until it was good or even flawless gets carried forward to the next thing. Most of that 10,000 hours is reinforcement.
In programming, that’s like writing the same To Do single page app multiple times. The first couple of times you can refer to the tutorial, but eventually you have to be able to write it without any reference. It’s like slowly playing Ode to Joy while looking at the sheet music, then memorizing how to play it, then being ready to play it at a recital.
But when you’re trying to deliver a project on deadline, how long do you have to do that? You’re expected to do all that on your own time at many companies. Time to code for skill expansion and reinforcement is not provided. Other companies give you 10% time or 20% time to work on independent projects, but few of them want you to spend that time on just practicing.
In the ever-accelerating landscape of new frameworks, new best practices, new languages, new modalities, just getting passable at the new competes with playing Ode to Joy like a pro.
So what’s my point?
My point is that you need to balance reinforcement with exploration, especially if coding is not 40%-50% of your day. You have to keep coming back to the same problems to build that mental muscle memory until you can solve them in your sleep. And you have to realize that the violin has not changed substantially in hundreds of years, but programming changes constantly. Becoming a virtuoso coder in a specific language means sticking with it longer than your job might want you to. You might have to follow your goal of being the best in your off-hours or by taking your expertise to a company that will let you continue on this path.
You can also forgive yourself for not being as awesome as you’d like after even 5 or 10 years, because doing 10,000 hours properly is harder to accomplish than it might seem.