Twelve Tips to Master Programming Faster
breckyunits.com
breckyunits.com
It's not as simple as merely doing something for 10,000 hours and then you magically become an expert.
The 10,000 hours-rules refers to the act of performing 10,000 hours of "deliberate practice" (or sometimes called "deep practice") in order to become an expert.
And that's something very different to simply code 10,000 hours in your day job. When googling for that term, you'll find plenty of studies and other resources. :)
If you are interested in this topic, I can recommend the book "The Talent Code" by Daniel Coyle - yes, the title is cheesy but it's a good book, I've read it in pretty much one sitting. A gentle and entertaining introduction into the whole field of how to become an expert.
"Pragmatic Thinking and Learning: Refactor Your Wetware" by Andy Hunt also spends an whole chapter on deliberate practice. It's a very good book, too.
EDIT: This blog post by Derek Sivers could be considered as an example of deliberate practice: http://sivers.org/kimo Just stumbled about it as a submission to HN, nice coincidence... :D
It doesn't take 10,000 hours to become a master striker in football, they are all young and the older you get, the worse you get. Does it take 10,000 hours to write master songs? No. Look at virtually any modern band. Not many people go through the same gruelling tours as the Beatles did before success.
Also, to pretend the complexity of the task has no bearing on the hours it will take to master it is nonsense.
You don't need 10,000 hours in virtually anything to be an expert. 10,000 hours to be a master of tic-tac-toe? No. Does it take 10,000 hours to become an expert coin-flipper? No. An expert dish washer? An expert waiter?
I also have take umbrage with the word expert. I think if anything it should be something like virtuoso, an exceptional ability, not just an expert. All of the examples I've seen used are people with exceptional abilities, not mere experts.
Ach, I don't know why I get so annoyed at it, it just seems to me that it's trotted out for totally inane lists like this one all the time.
I agree with your point, but these examples are flawed. The "fields" of tic-tac-toe, coin-flipping and dish washing are insufficiently complicated that it makes sense to talk about being an expert in them.
Waitering, on the other hand, is definitely an art. Sure, anyone can, with a minimum of training, take an order and put a plate of food in front of a customer. Knowing all details about all dishes on the menu in a fine a-la-carte restaurant, being able to remember an entire tables orders, deducing taste and matching wines from a huge wine list, keeping an eye on everything and understand the timing, so dishes are served and glasses filled exactly when the customer expects it -- and, by the way, doing this for maybe 5-6 tables simultaneously for 6-8 hours straight, on your feet, without missing a beat -- that takes years and years of hard practice.
Wrong. 25 hrs / week * 50 weeks / year = 1250 hours. So 8 years of football = 10k hours. Most pro strikers have been playing since they were 8y/o; by 16y/o, they have acquired their 10k hours.
I think it's the other way around - 10k hours doesn't really get you to true mastery - it's more like 50-100k hours.
As Mas Oyama, founder of Kyokushin Karate, once said: "After 1000 days (=10k hours), you are a beginner. After 10,000 days (=100k hours), you are a master."
> Look at virtually any modern band
If modern bands don't have to practice so much to be famous, that says so much more about their quality and the record labels that promote them.
And I don't see any "modern band" being as popular and as eternal as the Beatles. Michael Jackson was close, but he wasn't exactly known for his quick and painless path to success.
I think the point I'm trying to make is that they can write high quality songs at the beginning of their career as well as at the end. They didn't need 10,000 hours to come up with a great song, an expert quality song. I bet many had only written 20-30 songs before getting famous, certainly nowhere near 10,000 hours of song writing. You even get bands which then fall into mediocrity after a fantastic debut.
I have no doubt they put in hours beforehand, but they've been at school, certainly not playing for 3 hours a day for 10 years.
Not only that they have some mastery of the instruments, song writing, stage charisma, all distinct skills. Many great guitarists write crap songs.
So where did they get the 30 years to get all 3 skills?
I think the Beatles example is bad because they had an extra skill, the ability to morph their music with the times that many other bands don't (Bowie is another example of someone who was able to do this). They are eternal because they constantly changed, put out great albums, which has nothing to do with the 10,000 hours of practice they put in in Germany.
Innate talent is another requirement and will slow you down or speed you up, but I would doubt that you find any experts who are not greatly committed to their field (even if they hadn't dedicated 10,000 hours to it yet, they fully expect to).
And I don't see any "modern band" being as popular and as eternal as the Beatles. Michael Jackson was close, but he wasn't exactly known for his quick and painless path to success.
Michael Jackson was more than just close, he achieved it.
Not that it matters much ... Michael Jackson's albums are here to stay.
I was just saying that to be great (instead of just acceptable) ... you have to put a whole lot of effort into it. For instance I haven't heard of a single great gymnast who hasn't practiced until every muscle in his/her body was pushed well beyond limits. I actually heard of a few cases where people have passed out, out of sheer exhaustion.
So you're born with a natural talent ... but so are many other people. What makes you stand out is the effort you're putting in achieving your goals.
Second, these minor differences between the two are not relevant ... they amount to nit-picking. My point is that they Michael Jackson and The Beatles are in the same equivalence class. Who sold more records or whatever really isn't particularly important.
You seem to tend to believe that virtuosos aren't made but born, ie nature vs. nurture. I think that practice plays a much more important role. That is, a natural disposition maybe be a necessary but not the sufficient condition.
Really, read that book "Talent Code" I think it's better suited to get that point across. :)
I think the thing about OOP is it's an abstract set of concepts and it's not easy to grasp the benefits until you practice it.
I've been programming for almost 20 years now (some of that in school), and just recently began exploring web programming (started looking at php over the summer).
I found the information helpful, even though I can code pretty massive simulations with complex algorithms in C++ for a desktop environment, I couldn't build simple ruby/rails apps. Slowly learning about the fundamentals of persistent web databases (migrations), http restful I/o, and many languages for data access and views on that data (HTML,php,JavaScript,java,scala/lift,ruby/rails,python/django, along with many APIs). This is probably going to take me more than 10k more hours to learn well.
"Great code is easy to read"
Not at all. JWZ's code challenges me; heck, some of the Rails code baffles me until I sit down and think carefully. A lot of code can be unintuitive to the uninitiated and still be great.
"Use github."
Seems awfully narrowly scoped. Using SCM is undeniably beneficial, but using it to become a "master programmer" seems a bit misguided, like becoming a master hammer swinger will make me a master finishing carpenter.
"Code is surprisingly more like English than like math."
Ruby? Very little code I've read would be understandable if read out loud.
"Learn Linux."
Well, maybe. OP must be a web dev who grew up on Windows (like me). I don't understand how memorizing a series of command line switches will help anyone master programming. While understanding pipes, regexes, ACL, etc... is undeniably useful, there must be better approaches than "learning Linux."
All that said, I must give kudos to the OP. I'd like to master programming, too. I have no formal CS education, I get lost when spelunking through big code bases, I need to "learn Linux." But it seems to me that a better approach is needed.
The most intriguing part of the post was this comment: "You will read and learn more from a good $30 paperback book than dozens of free blogs."
I'm really curious about this. Does this hold true for anyone else? Are books about design patterns really more beneficial than reading the jQuery (par example) source? Dozens of times more useful?
In all seriousness, I highly recommend the Head First series of books. They read so much smoother than other large reference/learning books.
As for Design Patterns, the value in that was not that I learned any specific patterns, but rather that it got me to analyze software design in a systematic way rather than a "I like this" way.
Maybe it should have been "make it as simple to read as possible, but no simpler."?
>"Use github." >Seems awfully narrowly scoped
It is narrowly scoped. The thing I've witnessed with newbies and SCM, is that they are so intimated by it they never get in the habit of using it(until they go to a good shop that uses it). But it takes 1 minutes to sign up for github. And 1 hour of typing "git commit, git add, git init, git push" etc to master the basics. Then building upon that knowledge is easy. But just getting started with SCM is the hardest part, imo.
> "Code is surprisingly more like English than like math."
Kind of the same point as earlier ("clear as possible, but no clearer").
My linux advice was pretty weak, I got some good emails suggesting it should have been more specific, and I agree with that. I should have said "Learn key linux programs". pipes, regexes, vim, etc.
Great feedback, thanks!
Also, being an expert programmer suggests that you've levelled out, that you've reached a permanent high plateau. There is no plateau. It's a slope all the way to infinity.
If you find you've reached a plateau, shift gears and change to a more abstract programming language.
I'm at 30,000 hours, and I'm not an expert programmer. I'm still learning every day, and I like it!
When you love it, you pass on the other stuff to do it. You buy the books and read them purely out of your own interest. You take on projects you don't have time for because they're too damn cool to pass up. Most importantly, you talk to your friends about it all the time, because it's what's on your mind and it's what you want their opinions on.
And guess what, that's not just a "Programming" thing.
*Okay, there's a difference between self-deluded artistes and self-deluded programmers. Artistes can always claim to be before their time, misunderstood, and operating on a whole different spiritual plane. Programmers need, at a minimum, to create something that works in order to claim any success or ability at all. A real genioid can produce code good enough to receive "Works on My Machine" certification, and that can be proven to scale to five or more "simultaneous" users (depending on how many automated virtual machines he can get to hit the server from his laptop, his workstation, and that old Pentium II in the basement).
Also: Find someone who knows how to debug, and sit next to them for an hour or two while they tear apart a problem, fix it, and make sure it's solved. I've had a couple of tough sessions with world-class debuggers, and learned an amazing amount in a very short while.
This is very similar to this Tip #1, take your calendar, find a sport where you have time each week and allocate this time to coding (or to learn coding, you are also allowed to read books about coding in this time, or do your research regarding coding, etc. - but whatever you do, it should be relevant for coding).
I disagree with the mentor one. The Internet has always provided faster better and more complete answers than the "ask a co-worker" method, for me anyways.
My first experience with "coding" was trying to make a website for my tshirt printing business. I spent literally 12 hours a day for 10 days learning css and html and I loved it. So I coded about 10 pages for my website. Naturally I just copied and pasted the layout and menus and common stuff over and over throughout all pages. Finally on the 11th day, through a random search for something I don't remember, I stumbled upon this concept of "include_once" where you could create your website in this "templated" style. You just put "include_once(header)" and then includ_once(footer) and you didn't need to constantly duplicate everything. But it was in some language called php so that entailed that i start googling "php" ...
So you see, a 5 minute talk with a guy that knew about coding websites could have quickly briefed me about the differences between client-side and server-side languages, and why and how to use them. Could have told me to start with a framework like kohana rather than write spahgetti-rific code for the first 3 years of my coding hobby. Could have told me about using things like jquery for quick js development (and why and how js is appropriate). Yes yes, expert "crash courses" are definitely valuable.
Note: I tend to disagree with the term "self-taught". Plenty of people have taught me, it just has not been in a classroom environment. I have learned endlessly from the great teachers that write books, code open-source and take the time out to answer forum posts- so I'm not self-taught, its more like self-motivated.
in other words, i think timing matters. once you're bored with the copy + pasting, you'll either listen to advice, or be on the lookout for a solution while googling.
Just one disagreement: 5 hours fighting against code can be sometimes better than getting it solved in 2 minutes ;)
Programming, as outlined by guidelines as in the linked article, is nothing more than being able to write the code that solves a problem. Engineering requires you to be able to organize the code and the machines, networks and other infrastructure required to allow your client to reach your code.