Thursday, December 22, 2011

“Reading Doth Not A Programmer Make” (or, How To Effectively Learn To Program)

I recently had to quickly familiarize myself with the R statistical computing language for a new job. Being a veteran of the “learn new languages and immediately forget them” school of thinking, I wanted to make sure that this one stuck.

For R, the problem definitely isn’t a shortage of learning material; there are literally hundreds of online tutorials on how to use it. There are entire books that are devoted to individual components of the language. The problem is that, to steal a phrase from some dead Latin-speaking person, “reading doth not a programmer make.” To really become an expert programmer one simply has to program. The best way to do this is to have a project that you’re going to complete in the new language; by going through the planning, coding, and debugging phases, you’ll experience the nuances of the new environment; novel design patterns, different coding conventions, and all those subtle ways that a new language can excite and infuriate you. After you do that first project, you really don’t know that much—after all, you’ve only finished a single project—but you’re familiar enough that you could probably adapt to a new project quickly, and your subsequent questions will be less “what’s the def statement mean?” and more “why did you use design pattern A instead of B in this function?”.

The downside to the “do a medium-sized project” approach is that it may take more time than you have; in my case, I needed to learn a new language in about a week, while working on other projects. At most, I was able to dedicate two hours a day to learning the new language. I spent a good deal of time going through code from previous projects others on my team had written, but I found that it had similar retention to reading; simply reading through code, while helpful for seeing design patterns, is not enough for learning a new language.

For this project, a different approach was needed, and one that has been in use by teachers since time immemorial. A google search for the term “Introduction to R course” unearthed this website, which contained numerous homework assignments meant for the students. The assignments turned out to be written pretty well; each assignment contained what was, in effect, two small analysis projects. The homeworks, in effect, proved a good proxy for my “medium-sized projects” which I needed to learn the R; after completing them, I was by no means an expert, but I was able to converse intelligently about the language, and I was ready to begin really getting into the meat of the language. I had, in effect, progressed beyond the “beginner” phase, which was what I had been hoping to accomplish.1

There are two specific lessons I learned from this. From the standpoint of a student, the best way to learn a new language is to use it. How you use it during the learning phase is not as important—it’s far more important that you simply get real-world experience writing scripts and programs, so you have the necessary exposure to the language. From the standpoint of the teacher, though, the take-home is different; the best homeworks are the ones that get the student to use the language. Even better, have the student use the language for different purposes, to expose them to the many different facets of the language. A well-written homework assignment greatly enhances the overall learning experience.


  1. Note that this is how Schaum’s outlines, an excellent teaching supplement, are structured. Each lesson has a few—often very few—pages about the material, and then many, many pages of review problems. This is a tried and true technique.