My sons violin teacher made the point to him after observing him practice (paraphrased):

"What you are doing is playing, not practice. When you play through a piece like that, you spend most of your time on the bits you already know, and just a little time on the parts you find difficult, and you end up not repeating the hard parts very often. To practice, you should stop when you find something difficult, and repeat that part until you can do it well, and then move on to the next."

You will improve through simple repetition (edit: of a whole piece, or anything else where you know large parts of it well), but you will waste a lot of that time cementing things you already know very well.

And this is what marks the difference between time spent "executing" work in an area and practice in an area. Reaching the top in most areas will for most people mean shifting the balance between amount of time worked in that area and the amount of time spent on deliberate practice towards more deliberate practice and less towards performing.

That's very insightful. It's not the time you spend on something, it's the time you take working through the hard parts that determines success. I read before that they believe character determines success more than talent, with perseverance being the most desirable character trait. Your idea aligns nicely with this.

Get out of your comfort zone, the more time you spend out there the more comfortable it will become.

I realised this first when learning to snowboard, I found I progressed the best when I did the hard runs. An easy day going down some green runs didn't really help me progress. It was when I pushed myself to try the harder runs that I seemed to progress the quickest.

I think you and a lot of other people here are missing one very important point. It is not "10K Hours" that does the magic it is "deliberate practice" for 10K hours. Most in the profession of programming can't do 10K hours of deliberate practice because that would mean planning your career and skills like an Olympic Runner. Realizing what you are bad at and leaving everything to work on it. Say you realize that you are great at algorithms but not good at reading huge pieces of code written by others.

The majority of your programming is not with the intent to deliberately improve. Thus it doesn't count towards that 10,000 hours. That's the biggest misconception of the 10,000 hour metric.

Granted, but while things like data structures and relationships come naturally to my mind, I am frustrated by the fact that I have to keep looking up syntax for particular loops or method calls.

A large factor in this situation is that I regularly jump between several different languages, but nevertheless, it is frustrating to have to pause my flow and look up things so regularly.

Perhaps it is a patience thing with my older age, but I find nowadays the biggest thing putting me off starting new projects is just all the sheer mundaneness of setting up repositories and working folders, getting third party assets together, configuring project management tools etc.

You would think that familiarity and practice would make these sorts of things automatic and fluid over time, but the opposite seems to be true.

It happens to me as well and i decided to do a few things about it:

1. Not switching languages that often anymore. Fullstack? Yeah i could hack around in JS, PHP and whatever but i'm trying to stay in my field java to become really good in it.

2. Not using code comletion much/often. I write often a class file from scratch just to exercise it. I write Classnames out, i sometimes write my own imports.

3. Repeat it: When i forget how to write a for each loop, i do it once, and delete the code the next second and just write it again, than a third time.

No one cares when i need 30 seconds longer to write that one loop and the next time it sits again or much etter than before.

Syntax is not programming. Programmers are usually reasonably good at remembering standard software structures, algos, architectures, and problem solving strategies.

But unlike human languages, computer languages have no conventions and they're misleadingly similar-but-different. So it's quite usual to forget Python syntax if you've been using PHP for a while, and vice versa. It's a very common problem.

It's not unlike trying to learn French and German but only practicing one for a few months at a time while ignoring the other.

Repetition and spaced reinforcement are essential for learning. Learning takes consistent, applied, reliable effort, preferably within a timed strategy. Start/stop practice won't do it.

I think Gladwell is an absolutely terrible science writer. He's good at writing books that sell, and good at creating the illusion of psychological insight. But if you want psychological tips that really work, don't go anywhere near his books.

>But if you want psychological tips that really work, don't go anywhere near his books.

Just curious, what would you recommend in terms of psychological tips/books that do work?

> I am frustrated by the fact that I have to keep looking up syntax for particular loops or method calls.

Have you ever tried to deliberately memorize the syntax? Just repeating the same action for 10k hours doesn't make you an expert.

It's like how sportsman don't improve by competing constantly. They improve through deliberate practice. Work is like competing, you aren't trying to improve, you are trying to get stuff done.

Given how poor science reporting usually is, the "10k hours" rule as understood by the general public is almost certainly not what the original research had shown. That said, IMO to first approximation the rule's not wrong. It's just that you hit diminishing returns fairly quickly, i.e. your skill grows logarithmically, and 10k hours is roughly where the linear-ish part cuts off for most people. Of course second-order effects ("talent") affect how quickly you reach the cut-off, or how ahead / behind the curve after 10k hours. So take it as a rule-of-thumb, rather than some fundamental law.

Another sentiment you touched on about "guys who have been alive less time than [you] have been programming who can run rings around [you]": you are that guy for some other people. At the minimum, you might as well be a wizard compared to people on the other side of the threshold (and IMO that's one reason why pop-culture representation of "hacking" looks so ridiculous). In Go (as in AlphaGo, not golang) I was encouraged to play against opponents that's slightly weaker, at my level, and stronger. I forgot the proportions, but the idea is that if you only play against weaker opponents you would never improve; only against even opponents you wouldn't improve as quickly; only against stronger opponents you would lose confidence and quit.

To close off with a Naruto analogy (b/c why not, I've already rambled for this long): you're like Rock Lee: he's clearly outclassed compared against the likes of Naruto, Sasuke, etc., but he's still one of the strongest jounin in Konoha, arguably the strongest hidden villages. I'm probably Shikamaru...