I would like to make the point that Dr. Norvig nowhere in this article says, "It takes 10 years or 10,000 hours to be a programmer." Dr. Norvig himself refutes that notion explicitly here:
In a brief email exchange I Had with him, he even suggested he may rewrite this essay to address the fact that it is often used (inappropriately, obviously) to bludgeon new programmers into thinking that they're not actually programmers.
I think often on HN this essay is used to create some kind of caste system based on longevity in the biz or number of hours coded, which is horse shit.
I think the broader point is not that you can't call yourself a programmer before investing 10 years of practice -- but rather, that if you're going to learn to program, you should take the long view. You should think of it as a course of lifelong mastery, rather than as a simple skill that you can pick up over a month or two.
Today's self-help culture panders to short attention spans and desires for instant gratification. Everything's "For Dummies," or "In ___ Easy Steps," or "The 4 Hour ___," or "____ in 30 Days." These are all constructs optimized to sell books; they're seldom legitimately helpful for the reader.
While it's indeed possible for an absolute novice to teach himself to code in a short timespan, the endeavor is bound to produce disappointing results. The sort of people who pave new ground, start impressive companies, and generally kick ass in the field, are the sort of people who see programming as a lifelong passion, and not a quick-and-dirty toolset to acquire.
It's about frame of mind, not longevity per se. I don't believe Norvig is implying that you can't do anything cool or useful before you've logged 10,000 hours. Rather, he's saying that the sort of person who does cool and useful things tends to be the sort of person who wants to stick around for the 10,000 hours.
At the very least, the phrase "Teach Yourself to Program in Ten Years" serves as a self-selection gate of sorts. People who see that line can be sorted into two types: 1) the kind who freak out, say "wtf," or think "wow, doesn't seem worth it," and 2) the kind who sort of chuckle knowingly, and proceed anyway. The latter are more likely to succeed, because they have the right mindset. They may not believe they need 10,000 hours, and indeed, they may not. But they see 10,000 hours as an intriguing challenge, rather than a barrier to entry.
I read your link and nowhere does he refute that. In the context of his essay I believe he means it takes 10 years or 10,000 hours (more or less) to be a really good, experienced programmer. You can start playing the piano in a couple of weeks but it will take several years before you get really good. That is the spirit of his essay.
Somewhere between 2 weeks and 10 years you hit a point where you're good enough to entertain people/write useful code and perhaps even make some money doing so. The point being argued against I think is that you shouldn't tell people who are writing useful code that solves real problems that they shouldn't call themselves programmers because they haven't hit the 10 year/10000 hour mark.
>>The point being argued against I think is that you shouldn't tell people who are writing useful code that solves real problems that they shouldn't call themselves programmers because they haven't hit the 10 year/10000 hour mark.
I understand your point. That is not what the essay is doing. It is telling you that to be a true master of your craft it takes years.
Anybody can call themselves an artist if they are practicing art, but only very few get to showcase their work in art galleries. That is how the essay is using programmer in this essay. In the broader sense I agree with you, if you can code then you are a programmer.
Not quite sure if this analogy works. Art galleries are gate keepers just like record labels and calling only musicians with record contracts true masters is at the least "controversial".
The context of his response was that there is this belief on HN that "programmer" is a title reserved for certain people, and that belief is often predicated on an erroneous/incomplete understanding of his writing.
I think this kind of quibbling has more merit around the title Engineer. A lot of people casually call themselves Engineers, including programmers and the guy who replaces your smoke alarm. It is actually a protected title in some regions.
I think this kind of thinking can be demoralising to newbies like me. I do not care that I did not start programming at 14. I was playing with kites and chasing girls. To me they were really fun. Now that I have a lot of time to focus on coding and have discovered how much fun it is I am absolutely loving it. I just got off a five-hour flight and did nothing but write crappy Java. I loved it.
All I can say is that my gut tells me I will feel the same way in 10 years' time. Here's to years.
It was around ten years ago that I first read this article, and I've since followed just about every piece of advice given. I have since come along ways, but am still learning and improving every day.
I think this article gives excellent advice, and it has certainly worked for me. I always recommend it to people just starting out.
Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).
I'd be interested in current opinions on this. e.g. is there something one should look at before Icon if they want to lean about coroutines?
Lua has built-in support for coroutines. Python and Ruby have (limited?) support for coroutines via generators/iterators (via the yield statement).
But why not Icon? It has plenty of neat features on its own, such as goal-directed execution (which I've never seen in another language). Plus it has several pretty solid (and free) introductory e-books: http://www.cs.arizona.edu/icon/books.htm
"Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp)..."
Why learning Java or C++ if you are going to learn Lisp anyway? All Lisps I know of have their object system. If you prefer following the mature route, then Common Lisp is your best choice.
I think Dr. Norvig defends the idea of learning by making a effort and devoting a lot of time against the infra-culture of "learning XYZ in 21 hours" and so on :-)
The "power search" feature of amazon.com used in the introduction no longer exists. It appears they now have an "advanced search" (http://www.amazon.com/b?node=241582011), but nothing that will do a "X AND (Y OR Z)" boolean query. Anyone know how to run the same search today?
Slightly off-topic, but an interesting example testing out the idea of it taking 10,000 hours to become an expert is http://thedanplan.com/. Dan is trying to become a professional golfer and as of this month he's about 2,300 hours in.
The comments seem to back up that the article is from 2001 (so does the copyright at the bottom), but it links to Gladwell's Outliers, which came out in 2008.
What I suspect happened is that the piece has been modified since it was originally published.
As I couldn't find the date it was published, I deduced it must be written in 2001 from copyright at the bottom, as you pointed out.
Also observing the rule everyone does here at HN while referring to old articles, I added the year.
Even I have the same feeling about the modification of the article.
Articles can be resubmitted after a given time. Google shows me several submissions of this article from years ago but none recently, though citations of it do show up often in comments.
Why does it get to the front page? Because it's relevant and good, of course, unlike almost everything that is merely new.
I'm pleased to see more classics turning up on HN; Periodic reviews of the classics are the only way to get new visitors onto the same page as older ones.
One of problems with the resubmission is that it (intentionally or accidentally) ignores prior discussions until someone manually points out. The resubmission itself is not a problem, as you mentioned, however.
I guess a small link to the prior discussions or the HNSearch link to given URL will do a job. I personally prefer the latter, but it seems that HNSearch only indexes the domain name of the URL.
It's certainly more enlightening than arguing about cryonics or libertarianism or feminism or education for the billionth time.
Any forum has reposts, it's just that some of them are literally resubmitting the same article and others are rehashing the same stupid arguments that the Internet has hosted since time immemorial.
I am a newbie here who is following HN for the past 12 months or so. Since I hadn't seen this article in those months and after having read this article I was compelled strongly to submit to HN.
I thought someone who is a newcomer here should also know this and that is the only reason for me to post this.
http://news.ycombinator.com/item?id=3278080
In a brief email exchange I Had with him, he even suggested he may rewrite this essay to address the fact that it is often used (inappropriately, obviously) to bludgeon new programmers into thinking that they're not actually programmers.
I think often on HN this essay is used to create some kind of caste system based on longevity in the biz or number of hours coded, which is horse shit.