Teach Yourself Programming in 10 Years, an essay about the futility of books that claim to teach you programming in 21 days, 24 hours, or a similar timeframe.
Norvig offers some good advice, but I hate the treatment of computer programming as a laborious skill that requires years of monastic devotion to attain. When I attended the University of Texas at Arlington to major in computer science, the department was filled with professors who exuded exclusionary, self-congratulatory conceit about even the most rudimentary aspects of the field. Making the subject they had mastered seem intimidating was more important than relating it to students; I switched majors to journalism even though I had been coding since I was 12.
I take the ribbing about 21 Days and 24 Hours titles in stride, but I support the premise of the titles strongly because they make intimidating subjects approachable.
Computer programmers fall on a wide spectrum from expert professionals like Norvig to casual users who dabble with scripting languages or simple hacks.
For computer science professors and top-dollar developers, Norvig is correct to suggest, "you won't change your life, or your real overall expertise as a programmer in 24 hours, days, or even months."
For everyone else, though, it's terrible advice. Most reasonably bright and diligent people can learn the fundamentals of subjects like Java and XML in a short time, write code to achieve their own personal goals and perform entry-level jobs, and use these achievements as a confidence boost when digging deeper.
Telling someone they can't master something for 10 years discourages them from ever trying it at all. It's like telling a new open-source enthusiast to go away until she's capable of patching the Linux kernel.
Rant ahead. You have been warned. :-)
The problem is: those people that hack together their own private stuff and actually don't have a formal education on programming and often not much experience start to be quoted as "Experts" from other people. I had far too often the experience of stupid managers quoting someone of his family that it's easy to do this or that and that we programmers are just overexaggerating.
After implementing the POS somebody whithout a clue brought up, after being hacked into oblivion by somebody else _with_ a clue and then complaining to _me_ about the broken stuff, I am fed up with doityourself-programmers without experience. Sorry, this might sound harsh, but I won't trust somebody to frickle with the breaks of my car that didn't have the right education to do so, so why trust in those self-learned guys without experience with your software?
I have no problems with self-learning itself - actually that's almost 100% of how _I_ learned programming - but I prefer people without the knowledge to stay out of the way (or better yet, in the backrow, watching as others do their chore) on _serious_ projects, at least until they learned a bit more. You _do_ need experience before dabbling with serious stuff (and all stuff where you cash in on is serious stuff, even if the stuff itself is quite silly).
The reality in software development is that prototypes tend to be implemented as production systems (because managers _never_ grasp the difference between "shows that it might work" and "this is it"), even if they were hacked together by half a braincell under alcoholic influence ;-) (oh, and in my younger years that half-a-braincell was mine, actually, so I am allowed to rant!)
So I am with Peter Norvig on this one. You _do_ need years to get a competent programmer (and some never actually get there, so it is not only the time you need). So a bit intimidating isn't that bad - tells them that serious stuff is ahead. Of course, it shouldn't be too much intimidating - and I agree that often university stuff falls into this category (especially if it's from the software-engineering kind of people - they often ignore the fact that programming is as much (if not even more) a kind of art than a kind of engineering).
Maybe it's good that I am no teacher, as I would scare the kids away ;-)
Because I'm a teacher of sorts, I lean in the opposite direction.
The amount of time to achieve competence in computer programming depends on the subject matter. I don't think it's accurate to tell people they can't devote themselves to Java for a year and become fluent (and useful) programmers with the language. Much less 10 years.
Computer programming is filled with dabblers -- I'm reminded of a homebuilder I met who has become a self-taught Visual Basic coder for applications that run aspects of his business. How's a guy like that going to react if he's told it takes a decade to become a coder?
Also, when I worked briefly as a computer programmer, the job was 20 percent pre-existing skills and 80 percent on-the-job learning. Any hard worker who can be brought to a basic level of competence in a particular area of programming can succeed in an entry-level position. That's what I expect when I read the 21 Days and (especially) 24 Hours books -- give me a solid foundation in the basics, a concept of the scope of the subject, and cover some advanced applications I can master with the basics.
Exactly those "home builders" are a big problem. Their software solves one little aspect. But - as they never really learned how to do serious programming - they overlook many aspects that are important, too. Maybe an area where this becomes more clear is internet stuff: how many "web developers" out there hack together their own stuff in PHP? Sure, it solves their problems, somehow. But allmost every solution by those people has serious security flaws and exposes critical data to the net or can be abused to do things those people never intended.
So one could say, hey let's just ignore that - they are playing in their own turf, so why should we care? We must care, as the compromised machines/data might fire back at us (maybe the machine is used for denial of service attacks, or their software is used by us to buy goods and our credit card data get's stolen).
It's not that people can't hack their private tools together - sure, that's possible and fine. But there is no business I know of where managers accept those hacks as fully qualified solutions that easily as in the IT business. And _then_ it get's a problem.
See it from the other side: what would a craftsman think if somebody told him that his education and his years of experience are worth nothing, as anybody with half a clue and a book could learn his stuff? Do you think they would accept that? I don't think so.
To become a master in your art _allways_ takes years of experience. To become a dabbler is easy. To go from their to professional is hard. And people should know and accept that - otherwise they think their hacks are as good as some professional service. And that is _not_ true.
Hand-coded Web applications by dabblers represent a security problem to those individuals (and in some cases to a small userbase), but the scale of that problem is much smaller than exploits that make use of flaws in well-deployed software written by pros.
I don't think that the desire of a craftsman to feel important about his skills should have any bearing on how his craft is taught. Someone like Norvig (or either of us) knows that our expertise took more than 21 days to fully develop. We don't need book titles to protect our reps.
I can see some of your perspective, but I guess my main point here is that you don't have to code for 10 years to develop life-changing skills or increase "your real overall expertise."