I'd like to meet the person who would buy a book titled "Teach yourself computer programming in 10 years."
Well according to my wrestling with it, that book is out and called "The Art of Computer Programming" by don knuth.
Teach Yourself Programming in Ten Years (1998)
81–90 of 96 posts
Re: Teach Yourself Programming in Ten Years (1998)
#82I started at age 7. I'm 34 now. Still learning, and still feeling like a noob. Can't get enough of this, though.
I feel like a noob too, mostly because I started at 18! That's to say, I started taking programming seriously at 18. I did write a crappy Visual Basic exe when I was 8, and I dabbled a bit in Flash ActionScript in my teenage years, but I don't really count those years, because I was learning by rote then. I really only started taking programming seriously when I was in college. Writing an RTOS from scratch was one of…
I started at age 7 with BASIC on a C64. Then moved on to reading C and C++ books once I could read English. Yeah, I had to learn English before learning how to program. It makes me crack up every time I think about it. Anyhow, I had a, uh, rather interesting phase were I was into reverse-engineering programs and systems. Luckily, I did not have internet access until the end of that phase. Still remember having some fun learning stuff on IRC. By the time I was 20-ish, I was heavily into robotics. But back then the Arduino was not a reality, so it was mostly using PIC16F84 chips and 555 timers. And then I had another BASIC phase, which led me to discover Python. Then Lisp. Then Visual Basic, C#, and the .NET framework. Had too much fun with Python and Lisp. Love them both. Went back to them. I mostly do Python these days, but love writing Lisp whenever I can.
Re: Teach Yourself Programming in Ten Years (1998)
#83Earlier quoted context omitted.
You can become a programmer very quickly. But if you want to teach yourself to become a good one (something that no one else will do for you), you need to put in the time and effort. The article isnt called 'become an entrepreneur' in ten years. I didnt see it as a response to anything. Its just a good article. One of the 5-6 that regularly get upvotes every year or two.
Agreed on all accounts. This article is just often linked to on "I want to learn coding to build my startup" topics.
Norvig himself commented on one of those type threads in support of a guy who had taught himself to program in 12 weeks: https://news.ycombinator.com/item?id=3271866
Re: Teach Yourself Programming in Ten Years (1998)
#84Earlier quoted context omitted.
Imprecision (one significant digit) + Benford's law (most numbers start with 1) means most numbers needing citation are of the form 10^n. http://en.wikipedia.org/wiki/Benfords_law Interestingly, this would be true even if we had 8 fingers per hand. If we had 16 total fingers, 16 (base 10) would be written as "10" (base 16). 15 (base 10) would be a one digit number in base 16. On the other hand, you'd rather have six…
My favorite part about the imperial system is that a pint of butter weighs a pound. 16oz of butter is 16 fluid oz. A pint is a pound, the world round!
That's not exclusive to the imperial system...
Re: Teach Yourself Programming in Ten Years (1998)
#85regarding 10,000 hours ... from Moonwalking with Einstein "What separates experts from the rest of us is that they tend to engage in a very directed, highly focused routine, which Ericsson has labeled “deliberate practice.” Having studied the best of the best in many different fields, he has found that top achievers tend to follow the same general pattern of development. They develop strategies for consciously keepin…
I've heard it's both - that you need to constantly increase the level of difficulty of your practice for 10,000 hours. The research, after all, says "10,000 hours of deliberate practice", and deliberate practice is what you describe above.
Re: Teach Yourself Programming in Ten Years (1998)
#86Earlier quoted context omitted.
After reading Outliers I think of 10000 hours as approximately five years of full-time work, which is a much easier quantity to think about.
Such a rule-of-thumb needs a crucial caveat (said by others better than I'll say it here): You need N years of steadily, deliberately advancing full-time work. There's a fundamental difference between gaining 10 years of experience, and gaining 1 year of experience 10 times. It's harder than one might think to sustain continual real advancement over such a period; generally the employer paying the bills needs us to o…
The other caveat is that you have to be concentrating and paying attention to your performance for those 10,000 hours.
Very few people, if any, have the metacognition and executive function abilities to pay attention and steadily improve for 8 hours a day. The experts in Outliers and the research it's based upon would typically practice for only 4-5 hours/day and then rest, or do fun stuff like playing through pieces or doing a few flips or easy jumps. A bunch of anecdotal evidence from myself and my friends in Ph.D programs or professional jobs, plus RescueTime's survey of YC founders, also supports that most people can get no more than 4-5 hours of cognitively demanding work in per day. Hence the 10 years = 10,000 hours.
When you're working an 8 hour day, it's usually more like 4-5 hours a day of heavy concentration, plus 3-4 of overhead (checking e-mail, responding to e-mail, doing grunt work like unit tests that you already know how to do, talking to coworkers, sitting in meetings). If you're lucky. For many senior devs it's 8 hours of talking to people and zero coding.
(Although you can turn that into deliberate practice as well. For a while, shortly before and after I made Senior SWE at Google, I was spending the vast majority of my time answering questions from my peers and doing code reviews. I had very little time for coding and my basic coding skills improved very little, but I got really good at being able to dive into an unfamiliar codebase, identify what people were trying to accomplish, and find a way to make it happen in a not-completely-gross fashion. That skill proved invaluable later on, and basically saved the launch of one high-profile Google product.)
Re: Teach Yourself Programming in Ten Years (1998)
#87Earlier quoted context omitted.
Imprecision (one significant digit) + Benford's law (most numbers start with 1) means most numbers needing citation are of the form 10^n. http://en.wikipedia.org/wiki/Benfords_law Interestingly, this would be true even if we had 8 fingers per hand. If we had 16 total fingers, 16 (base 10) would be written as "10" (base 16). 15 (base 10) would be a one digit number in base 16. On the other hand, you'd rather have six…
My favorite part about the imperial system is that a pint of butter weighs a pound. 16oz of butter is 16 fluid oz. A pint is a pound, the world round!
One liter of water weights one kilogram which is IMO nicer.
Re: Teach Yourself Programming in Ten Years (1998)
#88As much as I agree with Norvig here, linking to this article in response to the "I want to learn how to code to build my startup" question is not helpful. Entrepreneurs aren't going to wait 10 years before launching their startup. The difference, of course, is that some people just want to build an MVP, while others want to be a programmer. In that case, I'd rename this essay: "Become a Programmer in Ten Years."
It is helpful. Probably force them to have at least one real programmer and thus save them from google indexing their private data or some other epic fail like that.
Re: Teach Yourself Programming in Ten Years (1998)
#89I am never surprised when this article reoccurs on HN. Don't try to rush it and continue to put in your time, that is the only way to get better at the craft.
But being better at the craft doesn't count for as much as we tend to think. Otherwise, we would not see much age discrimination in this industry.
In some ways that's true - a lot of employers don't care if something is done right or done well, just done fast. Youth and enthusiasm can get you shipping quickly.
It's just that what you're shipping, and how often you have to rewrite whole chunks of the product, can be questionable.
Re: Teach Yourself Programming in Ten Years (1998)
#90Isn't it odd and curious and such like that the chunks of time bandied about are units of ten? Coincidentally equal to the number of fingers on our hands. 10 years. 10,000 hours. I'd be willing to bet my granny's dentures that if we had eight fingers on each hand those numbers would be 16 years and 65536 hours (well, I mean it would still be 10 and 10,000 but you know what I mean). Also, did you know that in many cul…
Imprecision (one significant digit) + Benford's law (most numbers start with 1) means most numbers needing citation are of the form 10^n. http://en.wikipedia.org/wiki/Benfords_law Interestingly, this would be true even if we had 8 fingers per hand. If we had 16 total fingers, 16 (base 10) would be written as "10" (base 16). 15 (base 10) would be a one digit number in base 16. On the other hand, you'd rather have six…
Benford's Law applies because the wider natural distributions tend to be flat in the log space. One example is the log-normal distribution, which is what you get when random variables compound multiplicatively. (When they compound additively, you get a tighter Gaussian.)
So let's say that the values in bank accounts (just for an example) are $10^(N(3.5, 2)). In the log-space, this distribution is relatively flat on [2, 5] so let's focus on [3, 4]. The flatness at the top of the bell curve means there'll be just as much mass in [3, 3.3) as in [3.7, 4); converting back into dollar amounts that means there are as many between [1000, 2000) (10^3.3 is close enough to 2000) as in [5000, 10000). So you have as many leading 1's as you do of all digits 5-9.
I prefer to call it the Benford Effect. It's not a law. You don't get it for all distributions. It's not the case for human height, and IQ's have a hyper-Benford effect (50% of leading '1's) purely on account of how the distribution is defined. You only get it when the distribution is flat in the log space over at least one order of magnitude.