Hacker News new | past | comments | ask | show | jobs | submit login

I feel like you might be hinting that software is one such field.

IMHO software's problem is not that it doesn't take 10,000 hours of practice - it is that it takes much, much more. It can be months (or years!) before you receive feedback on your decisions. Given this, boldness and originality can go far not because it's easy to be an expert, but rather because almost no-one is an expert.




But hardly anybody in software does deliberate practice, everybody learns on the job by just trying to solve the problems they are faced with at the time.

Nobody considers what their weaknesses in programming are, invents a program of exercises to remedy that specific weakness and then does those exercises every day for a year. That's what deliberate practice is.

The book was about 10,000 hours of deliberate practice. As long as nobody in software does that, it's simply not applicable to software.


> But hardly anybody in software does deliberate practice,

As a largely self-taught programmer, I've struggled for a long time with certain algorithms and certain data structures. I got sick of it about a year ago, and decided to do something about it.

Since that time, I've come a long way using a "kata" technique for algorithms and data structures. Each morning (at least, ideally each morning), I worked on a group of related algorithms: trees on Monday, sorting Tuesday, graphs Wednesday, etc. And by "worked", I specifically mean that I would memorize algorithms related to the topic I was working on, and then each day re-write it from scratch. Often, I didn't fully understand the algorithm in the beginning, but after multiple days of re-writing it, I'd begin to understand it. After several months of this, I'd gained a much better understanding of all the areas I was working on.

I got busy and stopped a few months ago, but when I was doing it daily, I found I was gaining significant insight into the algorithms, and was able to then apply them in new and innovative (to me) manners. In fact, I started doing them again a few weeks ago because I noticed I was losing some of the insight I had gained. Reading this article has only reinforced my resolve.

So these "katas" I do are really nothing more than deliberate practice. And I know that I'm far from the only one doing these. They seem to be quite popular among some programmers.


When you're young and relatively inexperienced, every day you have to figure something out you don't yet know how to solve. I believe this does the same thing as the deliberate practice of a musician. Five years of 40 hrs a week or ten years of 20 hrs a week comes down to about 10,000 hours.

Now that I'm a veteran, I find that at work I spend most of my time at work solving problems I already know how to solve. I spend some of my spare time on pet projects doing things that are new to me, but unless they find a cure for the need to sleep, I'll never have 20 hours a week to spare for this again.


As a programmer and a musician, I feel that deliberate practice is much different than the day to day practice of working.

Sitting down and playing scales / etudes / method books every day is very hard, but it's the only way to get better at a quick pace. You can't really pay attention at that level for more than 4 hours (or, rather, I and most other humans can't).

Similarly, I've made concerted efforts to refactor procedural code into functional code, and while that is very difficult conceptually (for me, maybe not you) it felt very much the same way as doing scales.

Deliberate practice is not the same as just doing work, and just doing work doesn't make you better as quickly or in the same ways as deliberately practicing.


  >But hardly anybody in software does deliberate practice
I sure do, and you should, too. Every time I write a bug that gets released to customers, I ask myself, "how did that happen, and how can I prevent it in the future?"

As a result of doing this for many years, by now I rarely have bugs in code that gets released.


The trouble with using software as an example is that software is so damn fluid and ever changing whereas notes on saxophone will always be played in the same fashion within the same tonal range. It;s measurable; software is always a work in progress.

You can go to a pool and master all four swimming strokes: backstroke, breaststroke, butterfly, and freestyle in about a year but you would not be a Michael Phelps. However you would be able to swim better than at least 80% of all of humanity and be considered a master.

The word master needs to be better defined. You can quickly master many things in a year or less.


case in point: NPM and Left-Pad: Have We Forgotten How to Program? - https://news.ycombinator.com/item?id=11348798




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: