Ten Thousand Hours

Chances are, you've heard of the idea that it takes 10,000 hours to become a master at something. This was popularized by Malcolm Gladwell's book Outliers.

Nowadays, those 10,000 hours tend to be treated as 10,000 hours of doing the thing, rather than 10,000 hours of deliberate practice. These are not the same.

Let's say you have a basketball player with a killer 3-point shot (Steph Curry, anyone?). Curry didn't get that good by playing games; he got that good by running drills. By deliberate practice targeting his areas of weakness. By analyzing his shots. By being self-cricital and looking for areas of improvement. And by thousands and thousands of hours of invested time.

All of this happens outside of the game. That's not to say that you don't need to play to get better; practicing being in the high-stakes environment is also deliberate practice, if that's what you're focusing on. But simply playing game after game is not enough to achieve mastery.

Interestingly enough, when athletes talk about needing to practice, nobody bats an eyelid. "Of course", they say. "That's what it takes to play at your best. Playing isn't practice."

Now swap basketball for your area of discipline. Mine is software development.

Is your opinion on deliberate practice the same? Or does the idea of deliberately practicing make your stomach churn enough that you're now tasting that grande Americano you just chugged an hour ago?

Simply knowing isn't enough. It must be absorbed into the muscles and the body. It must become part of us. Or we risk losing it the second that we experience stress or difficulty.

– Ryan Holiday, The Daily Stoic (May 19th)

With software development, the line can get a bit more blurry, but I still strongly believe that the time spent in the office working on your current sprint task does not count toward your 10,000 hours to mastery. The sprint task is to the developer what the game is to the basketball player. And if we are to agree that doing the thing is not the same as practicing the thing, then all of a sudden the idea of using "years of experience" as a metric for capabilities becomes much more nebulous.  

And so as a developer, how do we practice? How do we grow? Practice, training, coaching.

Time spent in in-depth code reviews with a mentor is your time with a coach. It is the broad-strokes, macro view of your current state. It's the time to analyze your code. It's the time to be be self-cricital and look for areas of improvement. (Hot take of the day: if your code review has any reasonable amount of code to commit and your reviewer doesn't challenge you on anything, no alternative approaches are discussed, or you didn't get any recommendations, you didn't get a review. You gave a TED Talk on your code.)

Time spent practicing in a homelab, doing challenges on LeetCode, or kata on CodeWars is your time in the gym. It's the deliberate practice of the microskills required for you to excel. It's running drills. It's deliberate practice targeting your areas of weakness.

Growth comes from these two points: analysis and practice, then applying it. And by thousands and thousands of hours of invested time.