A career in programming is a good thing

Learn to program in ten years!

Of Peter Norvig. Teach Yourself Programming in Ten Years.
translated by Stefan Ram.
canonical URI of this page: http://www.purl.org/stefan_ram/html/21-tage


Why is everyone in such a hurry?

Go to any bookstore and you will see how to get the call Learn Java in 7 Days! can follow. There are endless variations of this title that offer Visual Basic, Windows, the Internet and so on in a matter of days or hours to learn. I made the following advanced search query on Amazon.com:

pubdate: after 1992 and title: days and (published after 1992 and "Tage" in the title) (title: learn or title: teach yourself)

I got 248 hits. The first 78 were computer books (number 79 was Learn Bengali in 30 days [Learn Bengali in 30 Days]). I replaced "days" with "hours" and got remarkably similar results: 253 more books, followed by 77 computer books Teach Yourself Grammar and Style in 24 Hours (Learn grammar and style in 24 hours) ranked 78. Of the first 200, 96% were computer books.

The result is that people are either in a hurry to learn more about computers or that computers are somehow amazingly easier to learn than anything else. There are no books to learn Beethoven, quantum physics, or at least dog care in a few days.

Let's examine what a title is like Learn Pascal in Three Days (Learn about Pascal in three days) could mean:

  • Learn: In three days you will not have time to write major programs and learn from the successes and mistakes you have made. You won't have time to work and understand with a skilled programmer. what it is like to live in the surrounding environment. In short, you won't have much time to study. Therefore, you can only speak of a superficial acquaintance, but not of a deep understanding. As Alexander Pope says, learning a little is a dangerous thing [1].

  • Pascal: You might be able to learn Pascal's syntax in three days (if you already know a similar language), but you can't learn much about how that syntax is used. In short, if you were, say, a BASIC programmer, you could learn to write BASIC-style programs using Pascal syntax, but you couldn't learn what Pascal is actually good (and bad) for. So what is it about? Alan Perlis once said, "A language that doesn't affect the way you think about programming is not worth learning." One possible argument would be that you should learn some Pascal (or perhaps rather some VisualBasic or JavaScript) because you need to connect to an existing program in order to do a specific task. But then you don't learn to code: you learn to do the job.

  • in three days: Unfortunately, that's not enough, as the next section shows.

Learn to program in ten years!

Researchers (Hayes and Bloom) have shown that it takes about ten years to develop competence in any of a wide variety of areas, such as playing chess, composing music, painting, playing the piano, swimming, playing tennis, neuropsychological research, or topology . There doesn't seem to be any real abbreviations: even Mozart, who was a musical prodigy at the age of four, needed 13 more years before he began to write world-class music. In another area, the Beatles suddenly seemed to burst into the scene when they appeared on the Ed Sullivan Show in 1964. But they had been playing since 1957, and although they had many fans from the start, their first big and decisive success appeared, Sgt. Peppers, 1967. Samuel Johnson believed it would take more than ten years: "Outstanding achievement in any field can only be achieved through lifelong work; it cannot be acquired for a smaller price." And Chaucer complains: "Life is so short and learning the trade is so tedious!"

Here is my recipe for success in programming

  • Start by getting interested in programming and code something because you enjoy it! Make sure it's so much fun that you want to invest at least ten years in it!
  • Talk to other programmers: read other programs! This is more important than any book or seminar.
  • Program! The best way to learn is learning by doing. To put it more technically: "People do not automatically achieve the highest level of performance in a given area as a result of extensive experience, but the level of performance can also be increased by very experienced people through determined efforts to improve." (P. 366) and "Most effective learning requires a well-defined task of a level of difficulty appropriate to a particular person, helpful feedback, and opportunities to review and correct mistakes." (Pages 20-21) The book Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life (Cognition in practice: mind, math and culture in everyday life) is an interesting example of this point of view.
  • If you want, you can spend four years in college or more in postgraduate studies. This allows them access to some activities that require a degree and gives you a deeper understanding of the field. If you don't enjoy such training, you can (with a little effort) have similar experiences in a job. In any case, it will not be enough to learn from books. "Computer science can't make everyone a programming expert, any more than the study of brushes and pigments can make great painters," says Eric Raymond, author of The New Hacker's Dictionary (in "The New Computer Specialists Dictionary"). One of the best programmers I'd ever hired had just graduated from high school; He's written a lot of great software, owns his own Usenet group, and has certainly gotten a lot richer than I'll ever be from stock options.
  • Work on projects together with other programmers! Be the best programmer on some projects, be the worst on others! If you are the best then try out how you can show your skills in leading a project and how you can inspire others with your visions. If you are the worst you will learn what the masters do and you will learn what they don't like to do (because they let you do it).
  • Work on projects after this other programmers have edited them. Make an effort to understand a program that was written by someone else. Find out what it takes to understand and fix it while the original programmer is away. Think about how you will design your programs to make it easier for those who will maintain them after you.
  • Learn at least half a dozen programming languages. This should include at least one language that supports the following abstractions: classes (as in Java or C ++), functional abstraction (as in LISP or ML), syntactic abstraction (as in LISP), declarative specifications (as in Prolog or C ++ - Templates), coroutines (as in Icon or Scheme) and parallelism (as in sisal).
  • Recall that computer science would not have its significance today without computers. Learn how long it takes your computer to execute an instruction to fetch a memory word from memory (with and without missing the buffer memory [cache miss]), to read successive memory words from the hard disk and to move them to a new location on the hard disk position. (Answers here.)
  • Participate in efforts to standardize a language. It could be the ANSI C ++ committee, or it could be deciding whether your local coding style uses 2 or 4 spaces for indentation. Either way, you will learn what others like about a language, how much they are getting involved, and maybe even a little bit about why they are doing it.
  • Be wise enough to give up standardization efforts as soon as possible.

With all of this in mind, it is questionable how far you can get by studying with books. Before my first child was born, I read all of the counseling books and still felt like a perplexed novice. 30 months later, when my second child was out, did I turn back to books to refresh my knowledge? No! Instead, I relied on my personal experience, which turned out to be far more useful and comforting to me than thousands of pages written by experts.

Fred Brooks described in his essay No Silver Bullets a three-part plan to find significant software designers:

  1. Recognize top designers in a systematic way and as early as possible.
  2. Put responsibility for the candidate's development and careful maintenance of a career record on a career mentor.
  3. Offer designers opportunities to come into contact with one another and encourage one another.

It is assumed that some people already have the necessary qualities to become a great designer; the task then is to guide them properly. Alan Perlis says it succinctly: "Anyone can be taught to sculpt: Michelangelo should have been taught not to sculpt. It is the same with the great programmers."

So go ahead and buy this Java book! You will likely get some benefit from it. But they will not change your life or your overall real competence as a programmer in 24 hours, days or even months.

swell

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

Brooks, Fred, No silver bullets, IEEE Computers, vol. 20, no. 4, 1987, p. 10-19.

Hayes, John R., Complete Problem Solver Lawrence Erlbaum, 1989.

Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.

reply

Times for various operations on a typical 1 GHz PC in summer 2001:

execute single statement1 ns = (1 / 1,000,000,000) s
Get data word from the L1 buffer memory (cache)2 ns
Get data word from main memory10 ns
Read data word from consecutive hard disk locations200 ns
Read data word from new hard disk location (seek)8,000,000 ns = 8 ms

Footnotes

Thanks to yomoyomo, this page is also in a Japanese translation, thanks to Carlos Rueda also in a Spanish translation, thanks to PEAllary also in a French translation, thanks to Xiaogang Guo also in a Chinese translation, thanks to Jason Chen also in a traditional Chinese translation and thanks Çağıl Uluşahin also available in a Turkish translation.

T. Capey points out that Amazon's Complete Problem Solver page now has both Teach Yourself Bengali in 21 days and Teach Yourself Grammar and Style books in the Customers who shopped for this item section also shopped for these items ". I suspect that a large proportion of the people who look at this book will come from this site.

[1] a little learning is a dangerous thing


Peter Norvig (Copyright 2001 [for the original text])


(Translation ends here.) Related pages include: learning to learn