10 (or so) tips for learning a new programming language

The first time you hear about some new programming language you have a big, empty, black space in your head. That is your ignorance. The new language is foreign, unknown, a dark void. Learning the language is all about dispelling the darkness in your head and to replace it with a mental model of how the language works. You must cast the light of knowledge on the subject. Here are techniques I use:

Get your hands on it

You may have all sorts of intentions to learn something, but if you don’t have it then it is hard to learn. So first go download the thing you want to learn. You need to be able to hold it in your hand, look at it, and then you can consider actually using it.

Make it do something

This is the classical “hello world” program. The point is to make the language do something, anything. The broader lesson is to choose some initial tasks and make the language do those things. You must start to assert control. You don’t need to write perfect code or even good code at this stage. You simply need to make the system do something. This is the first glimmer of light in the darkness.

Study history

Find out where the language came from. Go back and find the original source material to understand the history of the language. Why was it first created? What kind of problems was it designed to solve? This will help you understand its strengths. What languages influenced its syntax? Does it have a C heritage, a Perl heritage? What accidents of history are responsible for you ever hearing about it (how many languages are created that nobody ever knows about)? Don’t be content to read some distilled version of the history. Look for the original, definitive source that puts the language into context. This is a beginning towards understanding the nature of the darkness.

Browse

Google, flip through books, look at the language source code, visit mailing lists, look at different products. Spend some time just exploring all the different kinds of information there are about the language. At this point you can’t remember much of it, but you will pick up some tidbits, you will start to get a feel for some of the main issues, and you will discover good resources to learn more. Many of these sources will give contradictory and just plain wrong advice, so don’t believe everything you read. This is not so much shedding light on the subject as it is shopping for places to get light.

Read the spec

Find the manual. Don’t just read some magazine articles about how an API works. Find the actual spec or API docs. Find the definitive source that says how it works. This is your map in the darkness. Find the definitive reference materials and keep them close at hand.

Identify the masters

Explore the language community enough to find out who the recognized “masters” of the language are. These could be the people who created the language, but they must be the people who are publicly putting the language to the best use in building real systems. These are the people who define the programming idioms that are characteristic of the language. These are the people who are setting the standard for how to best use the language. Find a guide for the journey into the dark.

Read the writings of the masters

Read what the masters have to say about the language. For .NET this means reading Jeff Richter For C this means Kernighan and Ritchie For Smalltalk you need to read Kent Beck

The main point is to read the good stuff. Don’t content yourself with reading some third-hand story on a miscellaneous web site. Once you learn the language better then you will be in a position to sift through such material, but it can’t be your main source. So by all means browse the web and read all kinds of stuff, but you must look to the experts for your primary education. Follow the master guide into the darkness.

Build something yourself

You can read books and tutorials all day. What the author does will make complete sense. “Of course” you will say… to make blue text appear on the screen that is obviously the right command to use. The problem is that your brain tricks you into saying “of course” to the answers you are given. What you need to do is to try and make the language do something of your own design. So what if you want green text and what if you want it to be tilted at an angle? Well… the book doesn’t say how to do that… now your brain has to engage and actually learn how to make the language do what you want rather than simply assent to what it reads in a book. Now you are traveling through the darkness and gaining first hand experiences to truly understand what the language is all about.

Read a complete description of the system

Find a good reference document that broadly covers everything the language can do. You need to have a complete survey of all of the classes of things that the language provides. For example, if you are learning Java, you need to know not just the basic syntax, but you also need to know that it is possible to integrate native code, to decompile Java code, to run on quite different Java virtual machines, to create a security sandbox, etc. You don’t need to learn all of these things in any kind of detail, but you need to become familiar with the range of possibilities of the language. This is an attempt to establish a general border of the big black void in your mind.

Learn some aspect in great detail

Choose some aspect of the language that you are interested in and become an absolute expert in that topic. Learn everything there is to know about it. Explore every last option, leave no stone left unturned. For example, maybe you take on the issue of threading. Explore every primitive the language offers for thread synchronization, learn all of the mechanics of creating threads, study the idioms that capture the communities sense of “best practice” with threads, learn how threads are implemented on different computer platforms, etc.. This is now a thin beam of light that extends all the way to the bottom of the darkness. There is no remaining mystery around the topic. Nothing hiding in the dark.

Study the work of the masters

Find code written by a master. So not only are you studying what the master has to say about the language, but rather you are learning what the master has said in the language. Read lots and lots of code written by the master. You want to just soak in well written code so it seeps into your thinking and into your style in ways that you are not even aware of. For Lisp this is reading Paul Graham’s On Lisp Here the goal is to learn to navigate the language, not just to get to the other side, but to get there in style, to do good work, to be an expert.

Hang out in the community

Find a community of experts in the language. Often this will mailing list archives or some kind of online forum. Browse through the archives. Spend a few weeks getting the latest messages. This is a way of immersing yourself in the culture of the language. So you will learn how such people think, what kinds of solutions are preferred.

Read the critics

Find the clearest thinking critics of the language and read what they have to say. This is a way to discover some of the hidden pits in the darkness.

Look to the future

Learn where the language is going. You don’t want to simply know how it works today, you want to know how it will work tomorrow. To be an expert you need to be ahead of the general adoption curve. For Java this means learning about upcoming JSR’s or just finding a good resource like Alex’s Java 7 page

So that is all there is to it. If you are trying to learn a new language and you are stuck then look back over this list, find something you haven’t done and go do it.

Of course these are just the starting points. To really know a language you need to build a real system and take it to production… and support it… a few times… over the span of several years… but that is another post.