Becoming an Expert

I’m going to spoil this video a bit, but it is still well worth a watch: “The 4 things it takes to be an expert” from channel, Veritasium.

Essentially the premise is that not only does it take 10,000 hours of practice alone to become an expert, but the quality of the practice is a factor. Valid practice, timely feedback, and focused improvement are also a necessity to push that skill to professional levels.

Video games are a living example of committing the time without making the progress. Plenty of gamers have sunk 1000s of hours into one game in particular and yet are no where near the level of expert, or in this case a more appropriate term might be “pro”. Typically gaming is used as an escape though, so some of the elements mentioned above are, in most cases, intentionally avoided. I could do without the feedback, I’m here to enjoy the game, not become an expert. As a result, it’s possible to hit a steady-state of being good enough to progress, but not developing compounding abilities to reach top tier performance.

Even still, 10,000 hours is a long time. Clocking that many hours into anything will undoubtedly have it’s benefits. But, if you’re currently not an expert in something, this figure can be intimidating.

By this definition, simple math shows if you practice 4 hours per day, 5 days a week, 52 weeks a year, it would take 9.6 years to become a 10,000-hour-practiced expert.

Starting from zero, this is a monumental commitment. Even aggressive efforts to accelerate that pace don’t offer much of an improvement. Doubling down to 8 hours per day would cut the time in half to 4.8 years, but that’s a full time job of peak efficiency with no vacation days and assumes that those are always 8 productive hours. Mathematically sound, but not realistic.

Interestingly, the 4-hour-per-day model roughly coincides with the timeline of my career - roughly.

I began my career as a professional developer in 2012 and transitioned to a full-time non-coding team lead around mid 2021. Even when I moved to team-lead and eventually manager, I was still fairly engaged in the technical, keeping an eye on code reviews, assisting with troubleshooting, and providing best-practice advice where I could. But when it was my full-time job, on average, I estimate I programmed 4 hours a day. Let’s break it down!

Over the course of 9+ years, we can safely assume that since no 2 work days were the same, and depending on the day, or the project at the time, I might have only coded for less than 3 hours and spent more time in meetings or had the day off, or ended up chatting with people more than working that particular day. But these low number days then would have been offset by stretches of high productivity. I’ve had a number of 6, 8, and in a few particularly rough cases, 14 or 16 hour days of coding to balance out days that were less than productive.

As for days off, I never took a vacation longer than 2 weeks and was typically working with 15-25 vacations days for the year. Even then, I did work some weekend days, depending on the job and project timing, there would have been more stretches of weekend work than others. Additionally I worked the occasional holiday through the years as well so ultimately all of these extra work days would have likely offset the holidays observed on weekdays that I wasn’t working.

All that to say, my stance remains that maintained an average of 4 hours a day actually coding.

There’s some connection to the law of large numbers that could explain this distribution (I’m sure a statistics expert could correct me here), if you want to really dig into the mathematical proof, but I’m going to go with best guess.

And in terms of practice quality of the those hours, that’s a reasonably safe bet as well. Programming offers a surprisingly robust environment in that regard. Writing code is iterative in nature, you repeatedly practice changing the code with immediate (or relatively immediate depending on compile time, environment, etc.) feedback. Continual trial and error built right into the process. And there’s the added privilege of having worked as a member of teams with other developers way smarter than I am that provided direct feedback, both in person or via code reviews. So valid, repetitive, timely and deliberate are all covered in terms of practice quality.

Given all of this, I can say mathematically at least, I qualify as an expert in software engineering. Approximately 4 hours per day, 5 days a week, 52 weeks a year for 9.6 years spent on some form of meaningful coding.

Now if you want to get into the particular tech stacks I worked with, that’s a slightly different and varied story. More on that in the future.

Thanks for sticking around! Let me know what you think @jaypetersdotdev or email [email protected]!