Back in 1993, psychologists K. Anders Ericsson, Ralf Th. Krampe, and Clemens Tesch-Romer said that 10,000 hours of deliberate practice of a specific skill will make one an expert. Fast forward 15 years, and Malcolm Gladwell’s Outliers made the 10,000 hours rule famous. And in 2012, Macklemore solidified it’s fact status: it officially takes 10,000 hours to be an expert at anything.
How does this rule correlate to coding? If you’ve been working full time as a dev for five years, you’d be considered an expert by the parameters of the rule. I don’t know many devs that would consider themselves experts, however, and I know several that have been doing this for decades. I know even more that got degrees in computer science and have steadily worked their way up the food chain. Yet I haven’t met anyone that embraces the title of expert.
Let’s say you started tearing apart computers and building websites when you were ten years old or younger. Are you an expert then? That questions begs another one: what makes someone an expert coder? Before we attempt to answer this question, let’s look a bit deeper at the 10,000 hours rule because people have been questioning it for over a decade.
The problem with the 10,000 hours rule to excellence is that most domains aren’t static. Unlike golf, chess or similar activities where the rules aren’t going to change much – if at all – over the course of time, tech is ever changing. Companies are producing new hardware annually, and software updates happen more often than that.
To reach that required 10,000 hours, one must practice and complete the same activity with the same set of rules consistently. Want to reach that as a dev? How about we look at Laravel’s framework as an example. Laravel released its beta in June 2011, with Laravel 1 released a few weeks later. The latest update, 5.3.9, was released just over a month ago. Many other languages have the same timeline.
According to the 10,000 hours rule, no one using Laravel – or any other framework – will become an expert because changes happen regularly and swiftly. This fact wasn’t blind on scientists, and the pushback began.
A 2014 Princeton study on what it takes to become an expert somewhat debunked the rule that Gladwell popularized. The study conducted a meta-analysis covering all major domains that have been either suggested or proven to need deliberate practice. The scientists found that practice counted for, on average, a 12 percent difference in performance – and in some cases, much higher. Other factors also made a difference in how much of an expert one can become at something no matter how many hours they practiced the skill. Things like starting age, personality and baseline smarts play a major role in our abilities to become experts. Bottom line: though important, deliberate practice isn’t as much of the foundation for expertise as once marketed.
So if you can’t become an “expert,” what does it take to just be good? And by that, I mean good enough to get your first job as a developer? Or your second job as a dev? Or to branch out on your own to start your own company? Author Josh Kaufman says 20 hours. In his TEDxTalk The First 20 Hours, he breaks down the four-step process to going from incompetent to proficient.
First, deconstruct the skill. By this, he means to the most crucial parts of this new skill and learn those first. Next, self-correct yourself so you know exactly when you are making mistakes and how to fix them. Third, remove barriers to learning. Shut down Netflix, close Twitter and stay far, far away from that abyss of an inbox. Focus. Finally, practice for 20 hours.
Let’s translate this to software development. The most crucial parts of coding that cover the most ground would be learning PHP, HTML, CSS, GIT, and the MVC pattern. For Laravel specifically, getting an understanding of the framework is also necessary. Stage two is easy for devs; self-correcting is a major component of software development. Most coders are doing this anyway, and everyone will tell newbies to get used to making this a part of their process.
Removing the barriers to learning, though, is where a lot of people falter. The great thing about the internet is that it connects us all through social media, email, Slack, chat and so many other channels. The bad thing about the internet is that we are constantly connected and given many opportunities to be social over being productive. Removing those barriers of focus (turn off the Slack notifications, folks) will make you a better, more precise dev. When you have all of the basic tools – and the determination – 20 hours of practice flies by.
So what next? Greatness? How long does it take to get great at something? How long does it take to be a great dev and not just a functional one? Though this is an open-ended question, we can all agree that deliberate practice is a necessary component. That also takes incremental exposure and consistent engagement in things that push your limits. It is possible, however, that we’re focusing on the wrong end goal.
Maybe the real question here is instead of trying to be an expert software developer, what aspects of your job can you improve in 20 hours of practice? Maybe the focus shouldn’t just be on the code; after all, your job is more than just staring at glowing screens all day. Identifying specific areas of weakness that you can devote time to strengthening every week may be the key to becoming that expert that you desire to be.
Sharon is an empathy consulting, public speaker and writer. She has over a decade of experience creating and managing content for businesses. A lifelong stutterer, she utilizes her experiences with her speech along with her background in marketing to help companies communicate more effectively both internally and with their target audience. She writes and speaks about improving communication through empathy. She lives in Pittsburgh.
