You are on page 1of 14

Teach Yourself Programming in Ten Years

Peter Norvig

Why is everyone in such a rush? Translations

Walk into any bookstore, and you'll see how to Thanks to the following authors,
Teach Yourself Java in 24 Hours alongside translations of this page are available
endless variations offering to teach C, SQL, Ruby, in:
Algorithms, and so on in a few days or hours. The
Amazon advanced search for [title: teach, Arabic
yourself, hours, since: 2000 and found 512 such (Mohamed A. Yahya)
books. Of the top ten, nine are programming
books (the other is about bookkeeping). Similar
results come from replacing "teach yourself" with
"learn" or "hours" with "days."
The conclusion is that either people are in a big (Boyko Bantchev)
rush to learn about programming, or that
programming is somehow fabulously easier to
learn than anything else. Felleisen et al. give a
nod to this trend in their book How to Design
Programs, when they say "Bad programming is Chinese
easy. Idiots can learn it in 21 days, even if they are (Xiaogang Guo)
dummies." The Abtruse Goose comic also had
their take.

Let's analyze what a title like Teach Yourself C++

in 24 Hours could mean: Croatian
(Tvrtko Bedekovic)
Teach Yourself: In 24 hours you won't have
time to write several signicant programs,
and learn from your successes and failures
with them. You won't have time to work with
an experienced programmer and Esperanto
understand what it is like to live in a C++ (Federico Gobbo)
environment. In short, you won't have time
to learn much. So the book can only be
talking about a supercial familiarity, not a
deep understanding. As Alexander Pope
said, a little learning is a dangerous thing. French
(Etienne Beauchesne)
C++: In 24 hours you might be able to learn
some of the syntax of C++ (if you already
know another language), but you couldn't
learn much about how to use the language.
In short, if you were, say, a Basic German
programmer, you could learn to write (Stefan Ram)
programs in the style of Basic using C++
syntax, but you couldn't learn what C++ is
actually good (and bad) for. So what's the
point? Alan Perlis once said: "A language
that doesn't affect the way you think about
programming, is not worth knowing". One Hebrew
possible point is that you have to learn a (Eric McCain)
tiny bit of C++ (or more likely, something
like JavaScript or Processing) because you
need to interface with an existing tool to
accomplish a specic task. But then you're
not learning how to program; you're learning Hindi
to accomplish that task. (Vikash Tiwari)

in 24 Hours: Unfortunately, this is not

enough, as the next section shows.

Teach Yourself Programming in (Marton Mestyan)
Ten Years
Researchers (Bloom (1985), Bryan & Harter
(1899), Hayes (1989), Simmon & Chase (1973))
have shown it takes about ten years to develop
(Tridjito Santoso)
expertise in any of a wide variety of areas,
including chess playing, music composition,
telegraph operation, painting, piano playing,
swimming, tennis, and research in
neuropsychology and topology. The key is Italian
deliberative practice: not just doing it again and (Fabio Z. Tessitore)
again, but challenging yourself with a task that is
just beyond your current ability, trying it, analyzing
your performance while and after doing it, and
correcting any mistakes. Then repeat. And repeat
again. There appear to be no real shortcuts: even Japanese
Mozart, who was a musical prodigy at age 4, took (yomoyomo)
13 more years before he began to produce world-
class music. In another genre, the Beatles
seemed to burst onto the scene with a string of
#1 hits and an appearance on the Ed Sullivan
show in 1964. But they had been playing small Korean (John Hwang)
clubs in Liverpool and Hamburg since 1957, and
while they had mass appeal early on, their rst
great critical success, Sgt. Peppers, was released
in 1967.
Malcolm Gladwell has popularized the idea, (Mehdi Asgari)
although he concentrates on 10,000 hours, not 10
years. Henri Cartier-Bresson (1908-2004) had
another metric: "Your rst 10,000 photographs
are your worst." (He didn't anticipate that with
digital cameras, some people can reach that Polish
(Kuba Nowak)
mark in a week.) True expertise may take a
lifetime: Samuel Johnson (1709-1784) said
"Excellence in any department can be attained
only by the labor of a lifetime; it is not to be
purchased at a lesser price." And Chaucer (1340- Portuguese
1400) complained "the lyf so short, the craft so (Augusto Radtke)
long to lerne." Hippocrates (c. 400BC) is known
for the excerpt "ars longa, vita brevis", which is
part of the longer quotation "Ars longa, vita brevis,
occasio praeceps, experimentum periculosum,
iudicium difcile", which in English renders as Romanian
"Life is short, [the] craft long, opportunity eeting, (tefan Lazr)
experiment treacherous, judgment difcult." Of
course, no single number can be the nal answer:
it doesn't seem reasonable to assume that all
skills (e.g., programming, chess playing, checkers Russian
playing, and music playing) could all require (Konstantin Ptitsyn)
exactly the same amount of time to master, nor
that all people will take exactly the same amount
of time. As Prof. K. Anders Ericsson puts it, "In
most domains it's remarkable how much time
even the most talented individuals need in order Serbian
to reach the highest levels of performance. The (Lazar Kovacevic)
10,000 hour number just gives you a sense that
we're talking years of 10 to 20 hours a week
which those who some people would argue are
the most innately talented individuals still need to
get to the highest level." Spanish
(Carlos Rueda)
So You Want to be a
Here's my recipe for programming success: Slovak
(Jan Waclawek)
Get interested in programming, and do
some because it is fun. Make sure that it
keeps being enough fun so that you will be
willing to put in your ten years/10,000
hours. Turkish
(al Uluahin)
Program. The best kind of learning is
learning by doing. To put it more technically,
"the maximal level of performance for
individuals in a given domain is not attained
automatically as a function of extended Ukranian
experience, but the level of performance (Oleksii Molchanovskyi)
can be increased even by highly
experienced individuals as a result of
deliberate efforts to improve." (p. 366) and
"the most effective learning requires a well-
dened task with an appropriate difculty
level for the particular individual,
informative feedback, and opportunities for
repetition and corrections of errors." (p. 20-
21) The book Cognition in Practice: Mind,
Mathematics, and Culture in Everyday Life is
an interesting reference for this viewpoint.

Talk with other programmers; read other

programs. This is more important than any
book or training course.

If you want, put in four years at a college (or

more at a graduate school). This will give
you access to some jobs that require
credentials, and it will give you a deeper
understanding of the eld, but if you don't
enjoy school, you can (with some
dedication) get similar experience on your
own or on the job. In any case, book
learning alone won't be enough. "Computer
science education cannot make anybody an
expert programmer any more than studying
brushes and pigment can make somebody
an expert painter" says Eric Raymond,
author of The New Hacker's Dictionary. One
of the best programmers I ever hired had
only a High School degree; he's produced a
lot of great software, has his own news
group, and made enough in stock options to
buy his own nightclub.

Work on projects with other programmers.

Be the best programmer on some projects;
be the worst on some others. When you're
the best, you get to test your abilities to lead
a project, and to inspire others with your
vision. When you're the worst, you learn
what the masters do, and you learn what
they don't like to do (because they make you
do it for them).

Work on projects after other programmers.

Understand a program written by someone
else. See what it takes to understand and x
it when the original programmers are not
around. Think about how to design your
programs to make it easier for those who
will maintain them after you.

Learn at least a half dozen programming

languages. Include one language that
emphasizes class abstractions (like Java or
C++), one that emphasizes functional
abstraction (like Lisp or ML or Haskell), one
that supports syntactic abstraction (like
Lisp), one that supports declarative
specications (like Prolog or C++
templates), and one that emphasizes
parallelism (like Clojure or Go).

Remember that there is a "computer" in

"computer science". Know how long it takes
your computer to execute an instruction,
fetch a word from memory (with and
without a cache miss), read consecutive
words from disk, and seek to a new location
on disk. (Answers here.)

Get involved in a language standardization

effort. It could be the ANSI C++ committee,
or it could be deciding if your local coding
style will have 2 or 4 space indentation
levels. Either way, you learn about what
other people like in a language, how deeply
they feel so, and perhaps even a little about
why they feel so.

Have the good sense to get off the

language standardization effort as quickly
as possible.

With all that in mind, its questionable how far you

can get just by book learning. Before my rst
child was born, I read all the How To books, and
still felt like a clueless novice. 30 Months later,
when my second child was due, did I go back to
the books for a refresher? No. Instead, I relied on
my personal experience, which turned out to be
far more useful and reassuring to me than the
thousands of pages written by experts.

Fred Brooks, in his essay No Silver Bullet

identied a three-part plan for nding great
software designers:

1. Systematically identify top designers as

early as possible.

2. Assign a career mentor to be responsible

for the development of the prospect and
carefully keep a career le.
3. Provide opportunities for growing designers
to interact and stimulate each other.

This assumes that some people already have the

qualities necessary for being a great designer; the
job is to properly coax them along. Alan Perlis put
it more succinctly: "Everyone can be taught to
sculpt: Michelangelo would have had to be taught
how not to. So it is with the great programmers".
Perlis is saying that the greats have some internal
quality that transcends their training. But where
does the quality come from? Is it innate? Or do
they develop it through diligence? As Auguste
Gusteau (the ctional chef in Ratatouille) puts it,
"anyone can cook, but only the fearless can be
great." I think of it more as willingness to devote a
large portion of one's life to deliberative practice.
But maybe fearless is a way to summarize that.
Or, as Gusteau's critic, Anton Ego, says: "Not
everyone can become a great artist, but a great
artist can come from anywhere."

So go ahead and buy that

Java/Ruby/Javascript/PHP book; you'll probably
get some use out of it. But you won't change your
life, or your real overall expertise as a
programmer in 24 hours or 21 days. How about
working hard to continually improve over 24
months? Well, now you're starting to get

Bloom, Benjamin (ed.) Developing Talent in Young
People, Ballantine, 1985.

Brooks, Fred, No Silver Bullets, IEEE Computer, vol.

20, no. 4, 1987, p. 10-19.

Bryan, W.L. & Harter, N. "Studies on the

telegraphic language: The acquisition of a
hierarchy of habits. Psychology Review, 1899, 8,

Hayes, John R., Complete Problem Solver

Lawrence Erlbaum, 1989.

Chase, William G. & Simon, Herbert A. "Perception

in Chess" Cognitive Psychology, 1973, 4, 55-81.
Lave, Jean, Cognition in Practice: Mind,
Mathematics, and Culture in Everyday Life,
Cambridge University Press, 1988.

Approximate timing for various operations on a
typical PC:

execute typical 1/1,000,000,000 sec = 1

instruction nanosec
fetch from L1 cache
0.5 nanosec
branch misprediction 5 nanosec
fetch from L2 cache
7 nanosec
Mutex lock/unlock 25 nanosec
fetch from main
100 nanosec
send 2K bytes over
20,000 nanosec
1Gbps network
read 1MB
sequentially from 250,000 nanosec
fetch from new disk
8,000,000 nanosec
location (seek)
read 1MB
sequentially from 20,000,000 nanosec
send packet US to 150 milliseconds =
Europe and back 150,000,000 nanosec

Appendix: Language Choice

Several people have asked what programming
language they should learn rst. There is no one
answer, but consider these points:

Use your friends. When asked "what

operating system should I use, Windows,
Unix, or Mac?", my answer is usually: "use
whatever your friends use." The advantage
you get from learning from your friends will
offset any intrinsic difference between OS,
or between programming languages. Also
consider your future friends: the community
of programmers that you will be a part of if
you continue. Does your chosen language
have a large growing community or a small
dying one? Are there books, web sites, and
online forums to get answers from? Do you
like the people in those forums?
Keep it simple. Programming languages
such as C++ and Java are designed for
professional development by large teams of
experienced programmers who are
concerned about the run-time efciency of
their code. As a result, these languages
have complicated parts designed for these
circumstances. You're concerned with
learning to program. You don't need that
complication. You want a language that
was designed to be easy to learn and
remember by a single new programmer.
Play. Which way would you rather learn to
play the piano: the normal, interactive way,
in which you hear each note as soon as you
hit a key, or "batch" mode, in which you only
hear the notes after you nish a whole
song? Clearly, interactive mode makes
learning easier for the piano, and also for
programming. Insist on a language with an
interactive mode and use it.

Given these criteria, my recommendations for a

rst programming language would be Python or
Scheme. Another choice is Javascript, not
because it is perfectly well-designed for
beginners, but because there are so many online
tutorials for it, such as Khan Academy's tutorial.
But your circumstances may vary, and there are
other good choices. If your age is a single-digit,
you might prefer Alice or Squeak or Blockly (older
learners might also enjoy these). The important
thing is that you choose and get started.

Appendix: Books and Other

Several people have asked what books and web
pages they should learn from. I repeat that "book
learning alone won't be enough" but I can
recommend the following:
Scheme: Structure and Interpretation of
Computer Programs (Abelson & Sussman)
is probably the best introduction to
computer science, and it does teach
programming as a way of understanding
the computer science. You can see online
videos of lectures on this book, as well as
the complete text online. The book is
challenging and will weed out some people
who perhaps could be successful with
another approach.
Scheme: How to Design Programs
(Felleisen et al.) is one of the best books on
how to actually design programs in an
elegant and functional way.
Python: Python Programming: An Intro to
CS (Zelle) is a good introduction using
Python: Several online tutorials are
available at
Oz: Concepts, Techniques, and Models of
Computer Programming (Van Roy & Haridi)
is seen by some as the modern-day
successor to Abelson & Sussman. It is a
tour through the big ideas of programming,
covering a wider range than Abelson &
Sussman while being perhaps easier to read
and follow. It uses a language, Oz, that is
not widely known but serves as a basis for
learning other languages. <

T. Capey points out that the Complete Problem
Solver page on Amazon now has the "Teach
Yourself Bengali in 21 days" and "Teach Yourself
Grammar and Style" books under the "Customers
who shopped for this item also shopped for these
items" section. I guess that a large portion of the
people who look at that book are coming from
this page. Thanks to Ross Cohen for help with

Peter Norvig (Copyright 20012014)


1 Login

Sort by Best
Recommend 55 Share
Join the discussion



Eric-Wubbo Lameijer
3 years ago

Thank you for this post! I was trying to help someone learning to program (though she does not plan to
take only 24 hours for doing so...)
Two remarks content-wise though:

1) learning by doing is not necessarily the best or even the fastest way to learn, even though it denitely
has its place. If I would teach anyone programming, I'd strongly recommend to study and try to
understand good code; this would be the technique of 'worked examples'. So far, lots of 'worked
examples' and a bit of problem solving seems to be better than one example followed by lots of problem-
solving. (see for example

2) The 10-year rule (or 10.000-hour rule) very much depends on the eld; it used to be about 6 years for
painters, but can be over 25 years for musicians. (Sternberg, Handbook of Creativity, around page 230) It
tends to depend mostly on the competition in the eld - the author of 'Moonwalking with Einstein' became
an US champion after about 1 year of training!. Assuming that a majority of programmers work hard at
deliberate practice (which I doubt), it may indeed take 10 or 15 years to become a top programmer. But to
be functionally literate and 'worth hiring' may not require that many years. Besides, one could denitely
ask who is a 'top programmer': someone who can write code that is superbly simple and clear? Someone
who can solve a complicated problem with a snazzy new polynomial algorithm? Someone who can keep
track of a project involving millions of lines of code? Someone who knows hundreds of language
functions and libraries? Someone who actually understands what a non-computer-scientist customer is
talking about and can transform it into a solution? Not all programmers will be equally good in all of those
things, being the 'best' programmer may therefore be like comparing apples and oranges.

For the rest, excellent post! It denitely contains material that I want to mull over some more...
64 Reply

jigar singh rathore > Eric-Wubbo Lameijer

a year ago

And your comment just provided me the vision on what a good reading actually means. we should
think about not just accept it as the ultimate truth. add something according to your experiences
throughout your life. think before believing
4 Reply

Amit Jha
3 years ago

I am referring to AI book these days and its just amazing to come to these pages.
19 Reply
zejian ju
3 years ago

Great article, learn much from it, thank you very much!
17 Reply

3 years ago

thanks for sharing this great article

18 Reply

3 years ago

I have been wondering how to become a programmer in 21 days using these books, but this great article
has cleared my misconception of becoming a programmer in just over two weeks!!!.
10 Reply

3 years ago

Bullshit. You're putting a lot of people off programming. What if you can already program before you
`learn`? Your mind already works that way, and someone showing you the basics it just makes perfect
sense and you're coding in say 15 to 30 minutes. You'll probably not sleep that night, of excitement. Just
absorbing the functions and APIs methods just t.
Ok there's tons to `learn` to memorize like a parrot - but, the basics are also very simple - and it all was
built on basic principles. It also makes sense as if someone has already done much the work for you to
achieve your creative ideas.
Programming is also un-learning, the tech changes very rapidly. Very humbling. Can be very theoretical
and mathematical. Philosophical. And very fun. An incredible eld and science.
Some program like lling in a coloring book, the lines are already there. For some it is painting a blank
canvas, innite.
So it takes 15 minutes, to 10,000 hours to a life-time, decades and you're still learning every day.
Oh, and to put in 10,000 hours into programming can be done in 2 years, even faster do the maths.
Kids master this. It can be as much taught as teaching someone to love.
There you go, don't take much of what people say for granted - you write the code, you write the rules you
29 Reply

This comment is awaiting moderation. Show comment.

Joey Joeseph Michaels > Francesco Basenghi
3 years ago

You obviously don't know who Peter Norvig is. Maybe just Google the name for the sake of it. I'm
sure you'll be enlightened even if just a little...
1 Reply

yr2091 > Joey Joeseph Michaels


2 years ago
I hate people who appeal to authority. Great Article!
25 Reply

Eyjlfur Kri Frijfsson > Joey Joeseph Michaels

2 years ago

He was not talking about Peter Norvig. He was replying to TheTaoOfProgramming

4 Reply

Francesco Basenghi > Eyjlfur Kri Frijfsson

2 years ago

thanks, sometime pointing out the obvious becomes necessity.

4 Reply

dcofjapan > Francesco Basenghi

2 years ago

You missed the point of this entirely. While it's good to let people know coding isn't as easy as riding
a bike, people that deter others from doing what they want to do is wrong regardless. How many
times have I been told game or web development is some stupid pipe dream whether vocally or
without saying a word. People are doing both successfully whether freelance or working with an
actual company and degree or no degree. Will they be a pro in 30 days from reading a book meant
for beginners? No but it's a start.

Tour de France rider in 24H > dcofjapan

8 months ago

The comparison to riding a bike is silly: becoming a procient bicycle rider takes years of dedicated
practice. Sure, everyone with some practice can ride a bike in the park or maybe commute to work,
but that is the "hello world" equivalent of bicycling, or chapter 2 of any 24 hour programming book.

Eric MacLeod > Francesco Basenghi

2 years ago
I think he's just trying to help people get in to it, this article comes off very strong and you don't need
to be in the deep technical to be able to do some useful things with coding. You can't assume he's
not a programmer though.

aaronpeacock > Francesco Basenghi

2 years ago

I don't agree with your expressed sentiments. I really take issue with your rst statement. No it's not
obvious, nor is it correct procedure for you to jump to this conclusion as a reaction to
TaoOfProgrammings expressed opinion. If anything, it shows that YOUR brain requires more
discipline and perhaps YOUR brain has a natural tendency to assert things it has no clue about.
(whether TaoOfProgramming is a programmer or not, which I would tend to assume is a possibility
until proven otherwise, especially given his/her name...)
until proven otherwise, especially given his/her name...)
In other news, appeal to authority is still a logical fallacy. One can certainly disagree with Peter
Norvig and still stand upright...

TheCreepyCrow > aaronpeacock

2 years ago

I'm guessing the reason he said that he is not a programmer is. Well
nd one programmer that will ever say "What if you can already program
before you `learn`?" .... Find me anyone who can do something and its a
99.9% chance they'll never say, "Oh yeah, I just tried swimming and now
I'm a professional swimmer after 15 minutes", or a professional painter,
ect. You might understand the basics better then others, but becoming
procient and effective with said tool or skill will take a long time,
no matter what it is or who you are. Then to top that off, people sell books by making people think
they can literally "Learn (any language) in 21 days!" I agree its good to get people into it. But that
could also be why so many people stop coding. When you realize you wont be coding that game or
making that impressive website in a month a lot of people become discouraged.

What I think the OP ment was that some people are more inclined to learn certain
things over others. I might be able to understand programming easier
than you, it could just click with me, but you can understand other things better than me.

and 10,000 hours is 416 days and 16 hours.... so If you wanna get those
10,000 hours in two years isn't that like 15 or 16 hours per day 7 days
a week?

Marcel Valdez > TheCreepyCrow

a year ago

To be honest, the rst time I programmed at 13 years of age, it just clicked, it was as if programming
was the perfect vessel to express something I had in me.

As soon as I knew what the basic idea of programming is (series of instructions with ow control)
and did some examples, endless abstract ideas came to my mind and were automatically converted
into pseudo-code in my head, it was effortless and could not be stopped.

I remember coming back to my father that day and telling him during dinner: "I can do anything you
can do" (he owned a software company, and no, he never sat down to teach me). Even though I only
knew two ow control mechanisms IF and JMP, I could not think of a problem (lack of creativity
probably) I could not solve with the tools I had (IF and JMP).

I've been stoked with programming ever since.

While I was not a master programmer at 13, learning a language's syntax and basic functionality
triggered a lifetime of coding. I am a 31-year-old software engineer now and plan on being one for
few more decades.
In my opinion, anything that gets you closer to becoming an expert is a Good thing, specially if it is a
book that gives you a concrete set of tasks and schedule that will get you closer, since many people
get stuck wanting to learn but never know where to start. However, I agree with Norvig that those
books should be renamed to: "Learn basic <language> syntax and functionality in 21 days" (but that
isn't a catchy title that would prompt many sales ;).

Finally, Norvig should also consider that whenever you have a large goal (mastering C++), it is
always good to start with a small concrete task to work towards to (i.e. a 21-day plan to learn syntax
and basic functionality!). Agile methodologies became popular precisely because they allowed
small incremental deliveries towards a larger goal (a nished product).

Conclusion: 21 days books are a great starting point (so long as the book is well written).

rururu > TheTaoOfProgramming

3 years ago

I agree. Also I think the basic premise "a little learning is a dangerous thing" of this blog post is
awed. Or does Peter Norvig think that teaching calculus in high school is
dangerous because most students don't become professional
1 Reply