Mastering a programming language takes a long time. The only way to do it is to read and write lots of code — lots of different kinds of code so you have to learn every feature of the language. Doing tutorials and following toy examples in books gives you an idea of what a language looks like, but it’s a long way from mastery. Learning to program probably takes ten years. Mastering a programming language shouldn’t take that long, but it takes longer than a few late nights.
A lot of programmers are language dilettantes: they have played with a lot of languages but haven’t mastered one. Some of them are amateurs who don’t have to make a living writing code. Some are paralyzed by too many choices. It’s easy to think you’re missing something when you see articles about Haskell, Erlang, F#, Ocaml every day. It’s easy to think you’ve already missed something when languages you never learned are revived: Scheme, Lisp, Forth, Smalltalk, and Prolog, for example. Where to start? Which language will be best for getting a job? Which is most fun? Most interesting? Most cool?If you program for a living you probably don’t get to pick the languages or tools for your projects. Where’s the fun in mastering Java or Visual Basic or whatever language you have to use at work? It’s no wonder programmers prowl the web reading about Ruby, or try to get some version of Lisp to run when they should be working. The curiosity and restlessness that makes playing with a new language fun also makes programmers lose interest quickly. Just like people upgrading cell phones and digital cameras before they how to use all of the features, programmers lose interest in languages before they have mastered them.
One way to stay interested in a language long enough to master it is to work with programmers who are already experts, on a real project. Work at becoming an expert, not just good enough to do the job. Play with the parts of the language you don’t understand and figure out ways to use those parts in your work. Memorize operator precedence and scoping rules so you don’t have to look them up or write clunky code to protect yourself. Read the source code for the standard libraries. Take charge of some broken or badly-written code, figure it out, then refactor it. Look at other languages to find ideas you can apply to your own work: functional programming, generics, parallelism.
I’ll go out on a limb and recommend two languages worthy of mastery. They aren’t the only or necessarily the best, but I think it’s more important to master any language than to fuss too much over which one.
Penguin Pete, 22 June 2007 at 6:00 pm
Well, you’ve certainly gotten off to a nice start here. Only four posts in and you’re a staple of SB sites already! I’ll be adding you.
On topic, I am resigned to forever being a jack-of-all languages and master of none. Mainly because code just isn’t my main forte; the most coding I do is web design, where basically you don’t need to master languages as much as you need a scattering of many languages. I agree that ten years is about right for mastery (in C, I come closest) but look at web design over the past ten years – I’ve had to learn one new language or platform per year just to keep up! By the time I’ve mastered those, half of them will be dead.
Slashdot today has an interesting comment on this note: http://ask.slashdot.org/article.pl?sid=07/06/22/1526234&from=rss
…when teachers shy away from teaching anything but proprietary languages, they’re working against code mastery. Trying to channel everybody into Visual ‘sick and .NET – who’s going to learn anything worth remembering five years from now that way?