30k Hours (2019) | Hacker News Reader

30k Hours (2019)

github.com

69 pointsbreck48 comments

My understanding is that “10,000 hours” isn’t a strategy, or rule, or evidence-based observation but rather a catch phrase of Malcolm Gladwell’s to make memorable a finding that he references in his book Outliers. The finding is by Anders Ericsson, it’s detailed in his book The Path To Excellence, along with his evidence, and it says that extensive Deliberate Practice is what makes an outstanding expert, and that instead people generally mistakenly assume that semi-automatic repetition strongly correlates with expertise development, which it does not.

So counting how many hours you’ve been working in a field is the exact mistake that most people make. Gladwell’s book has reinforced that confusion.

IMO the 10,000 hours thing is more of a truism based on the definition of what we call an expert. Its based on the human lifespan more than anything. If we lived twice as long, we would have professionals with much higher times spent practicing on average.

The 10,000 hours is how much solitary deliberate practice the students who were accepted into some acknowledged music conservatory had put in by the age of 18 (or some such). They aren't considered experts. But for the ones that make it through the ordeal of that school, some of them will be what we consider experts some day in the future.

I disagree, an expert isn’t a master. Compare applicants and graduates of these elite conservatory’s and there is real improvement, but most people off the street would have trouble distinguishing the before and after simply by ear.

Part of the point was that you have to be quite rich to be able to afford to spend 10,000 hours on something, you require other people to take up the slack of things you're not doing because you're practisting things, pay for lessons, drive you to practise.

Look, there it is again! You’re implying that 100% of their practice is deliberate practice. Which is, I think extremely unlikely. People like Wayne Goretsky, Michael Jordan, or Dan Gable, likely approached high ratios of deliberate practice in addition to high practice volumes, it’s rare.

I have a theory (very likely not novel) that the number of hours isn't as important as the continuity and the quality. I've seen first hand the tax people pay when they master something and then stop that activity and then rejoin in martial arts, domain specific knowledge, languages etc.

Agreed, 10K hours is not enough to become an expert in coding for example. You need at least 40K hours with many different languages, companies and projects to become a senior developer.

I did 44K hours in 15 years working for around 15 different companies in 6 different countries and open source work on the side for nights and weekends before I became CTO of a small bootstrapped startup.

Maybe mildly off-topic, but one thing I can't help but keep in mind during my day-to-day is this continual unspoken fight I have against the mundane. I'm sitting in the 10-15k hour range right now, and I already feel like many of those first hours were wasted on banal/repetitive things. There are moments in software engineering, no matter how smart we try to be, that can make one feel like a human Turing machine.

In other words, these people didn't spend their 30k+ hours sitting around writing CRUD apps and collecting an easy paycheck. Rather, quality hours really move the needle.

Agreed with the idea that at some point you plateau with the thing you are doing. Its frustrating, because you can't always see a way to change it. Sometimes that is life, I guess - because there is more to life than just being the absolutely best at one thing in life. It is ok to plateau and "collect dividends" (paycheck, nice hours, promotions over time, etc) and focus on challenging yourself in other aspects of your life.

There is always room for improvement. I get what you're saying, and I used to think that way...

What changed my perspective was getting into meditation, and embracing the idea of awareness and deliberation in every moment, trying to do well every single thing I take up, and not just in programming, but also in cooking, eating, sleeping, walking, speaking, thinking, seeing, peeing, pooping, etc.

There is always room for improvement, space and time to do it "just right", what is in Russian called "sovestno", meaning "without shame and in good faith". The closest approximation I can think of in English is "consciensiously".

Once I started thinking this way, my perception of banality and repetitiveness fell away. No task is banal, no task is a repetition, but each one is unique, and must be perceived as such. Once you see it that way, you'll begin to find room for improvement everywhere.

I think it has helped me a great deal in becoming better at programming.

(See also: Bruce Lee, 10000 kicks quote.)

> “I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.”

I have a similar way of thinking or at least intellectually try to remind myself of.

Also somehow this reminds me of a go term "honte". https://senseis.xmp.net/?Honte

Interestingly it seems to mean shame in French.

Isnt what they say: 10 years of experience or 10 times 1 year of experience.

I am honestly shocked at how low these numbers are... I became obsessed with programming in the second grade, and it has been my lifelong passion ever since. Even if I ignore all the sleepless nights I spent in lower schooling (as it is difficult to estimate the time as I had other things I was required to do... not that I often did them) and start the clock only when I left for college--of course, to study computer science--and then even if I only allocated a banal eight hours a day during only weekdays to programming (which is certainly ridiculous--my usual state is to spend all waking hours doing software; I definitely have other passions, but they can't possibly take anywhere near 2/3rds of my waking hours--but like, it is the kind of conservative estimate that I can't imagine anyone would quibble much with: it merely means that this is my job), I am at 45k hours (as of 39 years old)... and I would be shocked if the "true number" weren't twice that. How could Rob Pike--who is older enough than me to have been programming since at least before I was born (when he wrote the first window manager for Unix in 1981)--only have had 30k hours as of 2013? Like, the moral I guess I am taking from this is "I have no life and this is not normal: maybe stop programming for a bit" :(.

I'm 49, and started programming as a kid, I was similar, I spent a lot of time programming (and still do, day job and for fun). working on maybe an average of 30hours a week, my upper bound is around 65k-70k.

I wouldn't beat yourself up about it.

I think they took the practicing part literally. In my eyes, any work related to programming is programming. I'm sure Donald Knuth has spent over 30,000 hours working on "The Art of Computer Programming".

Knuth is a professor - so in addition to coding, he had to teach classes, advise students, apply for grants (and write the Art of Computer Programming too!). Wolfram has to run a 700-person company. Peter Norvig, Lars Bak, and Rob Pike all spent a long time as managers in giant companies - so lots of time wasted in meetings, etc.

Like you, I enjoy programming a lot, and I consider myself lucky that I get to spend most of my time on it without these distractions. It's rare to be in a field where you can do what you love without being forced to take on the other stuff over time.

Ah but that's the krux of the issue. If we're talking about mastery over "programming", can you really only count time spent coding?

> How could Rob Pike--who is older enough than me to have been programming since at least before I was born (when he wrote the first window manager for Unix in 1981)--only have had 30k hours as of 2013?

Seriously I think it's more about you overestimating the actual time you clocked programming than about Rob Pike.

I'm 43, working mostly as an IC since 1997, really doubt I spent more than 15k hours properly programming rather than fussing with customers, estimating, documenting, testing, screwing around with infra or reading.

1) I have always strived to work alone, I eschew meetings, and I solve problems using software. I spent a lot of time doing community management, but remember that the conservative estimate only examines a third of my time: if, during the course of any given day, you haven't spent at least a third of those waking hours programming, are you even living your best life? ;P

2) I mean, if you are doing it "right" ;P, testing is also coding, as is "screwing around with infrastructure", and while I admit reading isn't always about programming... but shouldn't it be? I can recommend some blogs and wikis and mailing lists ;P. Like, the practice of playing tennis involves more than just hitting the ball: at minimum, you also--at least sometimes--have to spend some time retrieving the ball once hit.

These estimates are time spent *thinking* about programming. The average dev doesn't get to code a full 8 hours per day. On average from WakaTime data, devs spend only 1-2 hours per day actually typing code. With 261 working days per year, that would take 26 years to reach 10,000 hours.

For example, the total combined hours spent programming the wakatime.com website over the last 7 years was 4,035 hours.

10,000 hours assumes an 8 hour workday. For coding time like WakaTime measures (actual hands on keyboard time), the goal should be 2,000 hours.

Am I to believe that you think time spent writing code is the hard or main part of software engineering rather than the thought that went behind that code?

Writing the code is the easy part.

Different people in different situations use different ways to refine 'the thought that went behind that code'. Some like to write on paper/whiteboard, some like to draw graphs, some like to research for similar solutions on the web, some like to directly code. Time in IDE/Editor is easy to quantify, time thinking about solving the problem is not. That is strictly individual work, though. Time spent convincing the PM/stakeholder to reduce/change scope is one that is very productive but rarely quantifiable/counted.

> Time in IDE/Editor is easy to quantify, time thinking about solving the problem is not.

That's the key. To find the time thinking just fill in the gaps between the time spent coding. For ex, the GIF in this post https://wakatime.com/blog/27-fill-the-gaps-in-your-coding-ac...

I always have ideas about some questions to my co-workers like this: "do you practice after work ?" "How do you improve? " "How do you balance your life" etc etc. But I think I am too shy to ask them directly. Can you give us an example of your cold mail ?

Life is short. Just ask your coworkers!

For the cold emails, nowadays I'd make it better, but back then roughly the below. This was one of the more long winded ones.

Hi **,

My name is Breck Yunits and I'm a 29 year old software engineer in San Francisco. I have long been a fan and beneficiary of your work, particularly of ***. **.

In hopes of providing better guidance for aspiring programmers, I am collecting quotes from accomplished programmers to the following question: how many hours have you spent practicing programming?

If you had the time to provide a back of the envelope estimate, I would greatly appreciate it! I will post the results to the public domain. If not, no problem, and thanks for reading.

Best regards, Breck Yunits

And how many lines of codes that they wrote (published)? This is also a calculatable number. Dividing this by the hours, you'll see how productive they are.

My guess is somewhere like 10 lines/hour if they're lucky.

> who sent me a Lisp program computing ...

I don't really know Lisp, but how do you get a Lisp to run that expression? I tried it in Emacs Lisp, Racket, Common Lisp.

It runs just fine in Python, and returns: 29760

You must write your own lisp, and that’s the beauty of it.

This is the lisp-way:

(* 48 (+ (* 4 10) (* 2 30) (* 5 20) (* 6 20) (* 6 25) (* 15 10) ))

> # sum(years * (hours/week)) * (weeks/year)

Appears to be Python?

Here's it converted to Common Lisp:

    (defun sum (years hours-per-week weeks-per-year)
        (* (* years hours-per-week) weeks-per-year))

Definitely not LISP. LISP uses a prefix notation, the expression in the post uses infix (like most programming languages).

Simple, but serious questions:

How do you practice programming and how can you tell you're improving?

When can you tell you're 'good' at programming?

it’s based on the size of a codebase you feel comfortable managing. for me personally, due to my emotional regulation problems, it was also based on the point in time about 1000 hours in when I stopped getting really frustrated with a problem I couldn’t solve immediately. when i learned to accept the speed bumps as part of the process and started trusting myself that I would figure it out eventually. which gave me confidence and the ability to enter a flow state more sessions than not, which allowed me to be much more efficient with my time.

When the spec for software you're developing changes after you've finished developing it, what percentage of the time do you need to significantly refactor your logic instead of just making a minor tweak/extension?

Might not be a perfect measure, but it's a very noticeable one that in my experience has been going down sharply as I've gained experience.

Good questions! Well, if it's anything like dancing (and I think it might be), we'll always have a hard time telling when we're good.

Going with that analogy, I'd say you know when it gets easier, when you begin to see forms and patterns, and can use them to tackle new challenges.

Some other thoughts: * When you are solving problems and seeing how to improve your code through testing and refactoring.

* When you can start reading other people's code and understanding the gist of what is going on at a high level without getting bogged down in the details.

* When you start feeling very comfortable with your tools.

* When you feel the satisfaction of solving problems.

* When you help others learn something.

Finally, dance like no one is watching. Enjoy yourself. If it's not bringing you joy, then you are unlikely to progress further. Either way, enjoy the process.

Have you read Peak by K. Anders Ericsson? I haven't found the answers you're looking for, but I'd start with reading that book.

I think this can be measured in how long it takes another capable programmer to get up-to-speed in your codebase (accounting for the overall size/complexity of the domain, of course).

I don't think it's for you to tell; I think it's like (as someone else mentioned) dancing or playing guitar or other creative arts - the only judge is other's feedback on the output you produce, preferably some kind of balanced mix of experts in the field, peers at your level, and the public at large.

We don't really have standard competitions (no, HackerRank and Kaggle don't quite count) but certainly (much like creators) coding in the open, collaborating, and soliciting feedback on the things you've code is probably the most certain way.

One thing that I've always admired about 30k hours high performing folks is their sheer level of output; because they have mastered things, producing new things becomes something almost effortless, and so their challenge becomes keeping psychologically grounded in that high performing zone (avoiding the "yips"); collaborating with others to break new ground; and putting their talents to their most effective use.

I'm only 31 now but it seems I've almost done as many hours as Stephen Wolfram or Donald Knuth. I started coding at 14 and have been coding 8 hours per day on average including weekends. I often code at night too. At least 44K hours total.

I'm working on blockchain tech now and built my own scalable quantum-resistant multi-chain blockchain ecosystem with a DEX from scratch including the cryptographic primitives based on a variant of Lamport OTS with Merkle Signature Scheme. Did it all (including all UIs, modules, etc...) in less than 1 year part time, mostly on my own but with some help towards the end.

Before that, I wrote a distributed messaging system which auto-scales on Kubernetes. I also wrote an off-chain payment system which auto-scales on Kubernetes including the database persistence layer which self-shards across docker volumes and can process an unlimited number of transactions.

The highest salary I was ever offered was $110K per year. Thankfully, I make my own money now so I don't have to deal with crony capitalists. In spite of all this and constantly trying to reach out to VCs and investors, it took a miracle for me to make it to this point...

I think the most surprising thing in the TFA was that DEK answers email. TIL.

Yes, but specifically said next time to write snail-mail (as requests on his website), as it was an unusual hour and he usually sends all emails (other than book corrections) to /dev/null.

Reply on news.ycombinator.com