Learning Language N+1

One of the best books I’ve ever read in my career is The Pragmatic Programmer. It is one of those books that does not go particularly deep on any subject, but it does a great job of filling in a lot of the gaps that are the difference between being a decent mid-level developer and a master of the craft. One of the many tips is to invest in your knowledge portfolio and one specific way to do that is by learning one new language per year. In this post, I’ll talk about the process I take to learn a new language because there is a lot more to it than simply just mastering the syntax.

Step 0: Pick a language

How do you pick a language? A lot of it is a matter of taste. I would recommend finding a language that introduces some foreign concepts that you don’t understand. If you don’t understand the value of macros and homoiconic programming, then picking up a lisp is a great idea. If you have only used dynamically typed languages like Ruby and Python, try out Haskell or OCaml. I’d recommend taking up JavaScript and C as you’ll probably bump into them later on in your career.

Step 1: Hello World

I like to start small with Hello World. Much of the hurdle of learning a new language is getting the tool chain working correctly. Hello world forces you to understand how to run and maybe compile your code. I generally also start by writing a test around hello world, can I make it say “hello Tony”? If so, time to move on to step two.

Step 2: Don’t be too ambitious

One then I’ve noticed about myself, is if I make step two too ambitious, I will get frustrated and quit or decide the language is terrible and rant. Don’t make the same mistake as me, once you have hello world working, start with a smaller, but more complicated program. I like something that can be completed in a few hours. Does your company require a code sample during the interview process? That is a great option. The Bowling Kata or other code katas make good candidates. Recently, when learning Go, I wrote a toy cron daemon. The goal of this stage is to get a decent grasp of things, not become an expert. Your code will probably look like crap and that’s okay. Rome wasn’t built in a day. As far as resources, I found resources like Go By Example to be really good to find specific solutions to my problems.

Step 3: Immerse yourself

During step two, you probably Googled a thousand things. You’ve started to form little islands of knowledge about the language, but you don’t have the full picture. This is when I tend to pick up a book and start reading. I’ve been enjoying The Go Programming Language by Donovan and Kernighan. I find reading a book fills in many of the gaps of the “why” things are done the way they are. For Go, understanding the differences between strings and byte-slices and when to use them, the when and why of pointers, and a lot of the nuance around the type system was stuff I didn’t immediately pick up while thrashing through step two.

Another important step is to start reading open source code. How do people that actually know what they are doing write stuff in your chosen language. I’ll generally look at the trending repos on Github and start poking around to see if I pick up any tips. I’ll look at how they’ve split up their logic. How do they test things? Find a style guide and read through it. For many languages “style” can help you sidestep common mistakes.

Step 4: Write!

Now that you have a better idea what good code looks like in your chosen language, start writing some. Find little projects to build. Who cares if you throw them away? Start building the muscle memory to fluency. This is by far the longest step, but also the most fun. At this point, you’ve gotten over the hump of this new language being hard. Now it is time to put it through it’s paces and see what it can and cannot do.

Step 5: Get real

Have you come across a problem at work that your new found knowledge will be perfect for? Time to use it. Most of the time for me this doesn’t involve actually deploying my newly learned language in production, but using one of the techniques that I was exposed to in whatever language we use at work. The most important thing you’ve built with this process is your own knowledge, not any particular bit of software.

blog comments powered by Disqus