Teach Yourself Programming in Ten Years

Sure, let’s do a deep dive into Peter Norvig’s classic article:
“Teach Yourself Programming in Ten Years”
(Original: https://norvig.com/21-days.html).

🧠 Context and Motivation

1. The Trigger: Misleading Titles

Peter Norvig was reacting to the popularity of books with titles like:

• “Teach Yourself Java in 24 Hours”
• “Learn C++ in 21 Days”

These books sell the illusion of fast mastery, suggesting that programming can be learned quickly like assembling furniture or memorizing a few phrases in a new language. Norvig sees this as harmful because it trivializes what is actually a complex, deep skill that requires time and persistence.

📚 The Real Path to Mastery: 10 Years

2. Research and Patterns Across Domains

Norvig references work by researchers like:

• K. Anders Ericsson (expertise development)
• Herbert Simon (cognitive science)
• Malcolm Gladwell (popularized the 10,000-Hour Rule)

Key observations:

• Expertise across many disciplines (e.g., music, chess, math) follows a consistent pattern: ~10 years or 10,000 hours of deliberate practice.
• “Natural talent” plays a role, but focused effort and feedback loops are far more critical.

🔁 Deliberate Practice: The Core Ingredient

3. What Is Deliberate Practice?

It’s not about writing code casually or building simple apps endlessly. Instead, it’s:

• Tackling increasingly hard problems.
• Failing, reviewing, and adjusting.
• Getting regular, honest feedback.
• Learning from mentors and peers.

“Practice doesn’t make perfect. Perfect practice makes perfect.”

🧩 Norvig’s Practical Guide to Becoming a Good Programmer

Norvig lists concrete, long-term steps you should take if you want to become truly skilled:

A. Love Programming, Not the Idea of Being a Programmer

If you’re not driven by intrinsic interest in building things and solving problems, you’ll likely burn out before year 10.

B. Program Consistently

“The best way to learn programming is to write programs…”

Write a lot of code. Solve real-world problems. Explore bugs. Refactor. Rewrite.

C. Work on Projects with Other People

You’ll gain:

• Exposure to better practices.
• Code reviews that challenge you.
• Insights into how large systems evolve.

Being a lone wolf limits your growth.

D. Read Code – A Lot

Studying other people’s code—especially open-source projects—helps you learn:

• Style
• Architecture
• Idioms
• Design trade-offs

This mirrors how aspiring writers read great literature.

E. Understand the Underlying Computer Science

Knowing how memory works, what makes an algorithm fast, or how compilers parse code gives you deeper leverage. Norvig suggests learning:

• Algorithms and data structures
• Operating systems and networking
• Hardware basics (e.g., CPU instruction timing)

F. Work at Varying Levels

Be the:

• Beginner among experts (to be challenged)
• Expert among beginners (to reinforce your knowledge by teaching)

Shifting contexts accelerates your depth of understanding.

G. Learn Multiple Programming Languages

“You should learn a programming language every year.”

Each language shapes how you think. For example:

• Lisp/Haskell: recursion, functional purity.
• Python/Ruby: rapid prototyping.
• C: memory, pointers, low-level control.
• Prolog: logic programming and declarative thinking.
• Java/C++: object-oriented design and abstraction.

These shifts in paradigm expand your problem-solving “vocabulary.”

H. Understand Language Design

Try writing a toy language or contribute to language tools. This teaches:

• Syntax vs semantics.
• Parsing, compiling, interpreting.
• Trade-offs in language expressiveness vs performance.

🧠 What Norvig Isn’t Saying

Norvig isn’t saying:

• You can’t build apps in a few weeks.
• You’re not allowed to enjoy tutorials or short-term progress.

He is saying: don’t expect mastery (or a rewarding programming career) from shallow study or shortcut mindsets. Real skill comes from depth, not quick wins.

⚠️ Critique of Fast-Track Materials

Norvig suggests that books like “Teach Yourself C++ in 21 Days” may:

• Teach you syntax, not software design.
• Give you false confidence.
• Set you up for frustration when dealing with real-world systems.

He compares it to learning to play piano by memorizing keystrokes without understanding rhythm or scales.

🏁 Summary Takeaways

💬 Final Norvig Quote

“So go ahead and buy that Java book—just don’t be in such a hurry.”