Skim or sink

In my experience, the way to become a better programmer is to:

• write lots of code
• skim lots of reading material, and
• defer answers until you have questions.

To learn why you should skim this post, please read it carefully.

On the Racket mailing list, someone asked the best way to learn advanced programming topics. Folks posted many great answers. I especially liked this advice from Neil Van Dyke:

You’ve read a lot already. I don’t know how much practical programming experience you have, but this reminds me to make a suggestion for anyone reading this email who is learning programming and doing a lot of reading…

If someone has access to a computer, then my suggestion at this point is make sure that they are spending more time practicing programming than they are spending on reading.

By reading books and doing problem sets only, and reasoning about programming in their head atop that, then someone might be able to understand programming theory as a mathematician might. But if they want intuition and insight into how to build and evolve sustainable systems in the real world, then I’m not aware of any substitute for practical experience in programming.

I wanted to +1 that, so I started to write a reply. It grew long and I wandered a bit off topic. So I decided to make it into a blog post instead.

What’s the rule of thumb about becoming an “expert” — it takes “10,000 hours” of practice, with gradually escalating difficulty?

Does learning and study count as “practice”?

Usually my most meaningful learning experience is when I have a question, first, and feel a personal need to learn the answer. The need might be practical and immediate. Or it might be a sense that I ought to know more about X at this stage.

By contrast, with formal education and book learnin’ I often get answers to questions I don’t already have. As a result, although I learn something, I usually don’t learn it as deeply. It feels like a solution in search of a problem.

Ideally I’ll go back and forth, alternating periods of hands-on experience with periods of reflection and study. Otherwise, if I get stuck too long in either mode, I plateau. Ten thousand hours of plateau doesn’t help.

Not to contradict the above, but sometimes I’ve found it beneficial to do a shallow survey above my current pay grade. I won’t understand the material very well. I just dive in. I sort of squint, keep calm, and solider on. Some small residue lurks in my subconscious for months or years. Someday, when certain questions arise, something will click — I’ll be able to recognize that it’s time to return and learn that topic for real. At which point I’m ready and motivated to learn it.

I think this touches on a certain style of learning and memory that is an important survival skill for programmers. In the pre-internet days, I knew a programmer whose daughter sometimes watched him working. She was asked what her dad does. She explained, “He looks things up in books.”

Today the look-it-up technology has evolved. And the amount of information to be known has grown exponentially. But I think the coping strategy is the same. It’s making use of the recognition half of memory (as opposed to the recall half). It’s knowing just enough about a topic, to be aware that it exists, and to recognize a situation where you should look up the details.

That’s why I recommend you skim. Surf. Browse. Whatever verb floats your boat. Because mainly you want to float. Something catch your eye? Sure, dive in. But not too long. Come back up for air, and keep moving along.

If you’re fresh out of school and accustomed to careful study, this will feel … all wrong. Get over it. Adopt a slogan from (gasp) liberal arts colleges: This is about learning how to learn. And in the real world of programming, this is how you learn. In my experience.

In conclusion, thank you for carefully reading this blog post. But next time, skim it.

p.s. Mainly I’m talking about things like APIs, specifications, and languages: All you will ever need to know is impossible for a normal person to memorize and recall. Of course you could argue that the basic principles of computer science haven’t changed much in 50+ years: Pioneering explorers like Alonzo Church, Alan Turing, Alan Kay¹, John McCarthy, and Douglas Engelbart mined that vein deeply. The rest of us? We smelt their ore and craft jewels. We prospect downstream, sifting for remaining nuggets. The core ideas are knowable, and worth more than a squinty skim.

If you were to argue that, I’d agree. Even so, I’d argue that our understanding of those fundamentals will be deeper and richer — less rote — the greater our hands-on experience with gradually more-challenging programming.