Skip to main content

Level Up Your Learning-Fu

Dec 2012 - Grand Rapids

The term “lifelong learner” might as well have been created for the modern programmer. Technology and techniques are evolving so fast, there’s always something new that might make your programs better or allow you to solve problems your existing skill set can’t.

Attending training sessions or even college programming courses is great, but your problems will always be unique to you: the chance of your instructor answering every coding question you ever have is zero.

This means possibly the most important skill you can learn is how to learn on your own. Teaching yourself is the way of the future: here are some ways to level up your learning-fu.

The examples below assume you’re writing in Ruby, but the process should apply to any language with a strong online community.

The Process

  1. Feel Pain
  2. Identify the Symptoms
  3. Research the Cure
  4. Fix the Condition
  5. Capture the Knowledge

Feel Pain

All our problems will begin by writing (or trying to write) code to accomplish a task. Let’s say we’re a pair of beginners and someone suggests we try out the “FizzBuzz” problem.

FizzBuzz is a counting game. We write a program that outputs a number list, but whenever a number is divisible by 3 we output “Fizz” instead. If it’s divisible by 5 we output “Buzz” instead. If it’s divisible by 3 and 5 we output “FizzBuzz” instead.

The simplest solution begins with creating an array of the numbers we’ll be working on. We might try:

my_numbers = [ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ]

…which outputs the following error at runtime:

SyntaxError: (irb):1: syntax error, unexpected tINTEGER, expecting ']'
                   my_numbers = [ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ]
                                     ^
                    from /Users/Bill/.rvm/rubies/Ruby-1.9.3-p327/bin/irb:16:in `<main>'

Clearly something is wrong. We are feeling pain because we can’t move forward until we figure this out.

What if we don’t know what to write in the first place? Don’t worry: we’ll deal with that separately in the steps below.

Identify the Symptoms

Let’s look at the error message and find the most unique elements of it that don’t have to do with the data itself. Several items pop out:

SyntaxError is what Ruby threw in response to the situation it couldn’t handle, and apparently it was expecting something called a tINTEGER. The longer and more-complicated a word, the more specific it is, so focus on these where possible.

We’ll get better at picking out good terms with practice. When in doubt, we could cut-and-paste the entire first line to make sure we don’t miss something significant, though that can give us false hits on unrelated errors that were run in irb or were expecting a value.

We should add some terms to help ourselves out, based on what we know about the problem: we’re using the Ruby language and we’re trying to create an array. Our final search term would be ruby array SyntaxError tINTEGER.

If we don’t know what code to write in the first place, we can go through the same process with the conversation we’re having “I want to parse a CSV file so I can write the data to a database.” Here, the terms that jump out are parse, CSV and file, so our search term would be ruby parse csv file.

Research the Cure

Now that we’ve established the things we want to search on, Google is usually our best friend. The Ruby community has a very helpful attitude, which means that when people fix problems, they often write blog posts describing how they did it. If you do this, including the actual text of the errors you get make your posts more search-friendly.

Let’s try Googling our search term: ruby array SyntaxError tINTEGER

When I run that search, the first result is the Ruby core documentation for the Array class, which should be in our bookmarks already anyway. :-)

If we navigate to the Ruby docs by clicking the link, the first example is how to create an array from scratch, which is exactly what we’re trying to do. When we compare their examples with our example, we notice we forgot the commas between our numbers. Doh!

Another common search result is Stack Overflow, a community-driven site that is a wealth of information. People post problems (always including code plus error messages for searchability) and other people post solutions, including links to helpful resources. The community votes up the best solutions, giving us a good idea which to try first.

If a problem deals with a particular gem (always include the name of the gem in the search term), often we’ll find a hit on the gem in GitHub, which is where almost every rubygem lives. The gem README, wiki page and issues list are all very helpful.

Fix The Condition

We can go back to our code now and fix it up:

my_numbers = [ 1, 2, 3 ,4 ,5 ,6 ,7 ,8 ,9 ,10, 11, 12, 13, 14, 15 ]

…which runs perfectly. Success!

Capture the Knowledge

There are 2 kinds of knowledge: the kind we keep in our heads and the kind we keep in our libraries. In order to make sure we don’t continue making the same mistakes over and over, we need to capture what we learn in one place or the other.

Anki

For specific pieces of information that we’ll use often (which fits our example), it’s important to have the information “under our fingers” so we can just do it when we need it. Looking up how to create an array every time we need one is inefficient.

I’ve found tremendous value in a cross-platform, free flash card tool called Anki. You create a card and Anki reminds you (at scientifically-calculated intervals) when you need to re-test your knowledge of that fact. After one successful test, it might wait a day. After two, a week. After 3, a month. The idea is to refresh the memory just before it disappears. I can confirm from experience that the approach works.

The key for me is making the question exactly what would be going through my head if I was attempting to use the fact in real life. For our example, my “Front” would be

Create an array for the numbers 1 through 5

and my “Back” would be

my_numbers = [ 1, 2, 3, 4, 5 ]

Anki’s “decks” allow you to group related sets of facts together and drill them as a group. I have decks for Ruby, Rails, jQuery, vim, git, etc.

Working with Anki every day has had a powerful effect on what I can do without having to look things up, which is a huge productivity improvement.

Of course, some things are so big you can’t keep them all in your head, which is why I also use…

Evernote and Workflowy

Evernote is a full-blown data capture system with many powerful options but I use it almost exclusively for “cheat sheets”. Something like vim and tmux with their dozens of keyboard combinations, markdown and textile with all their syntax options, etc, belong in neatly-formatted, example-rich documents you can pull up in one spot and find anything you need. “I know it’s a vim shortcut, so it’s here.” You can grab entire webpages, but I find it more efficient to condense their knowledge in my own idiosyncratic way to making it easier to retrieve.

Workflowy is an outlining tool I find useful for short-term storage of links to interesting resources. Whenever I come across a tutorial I want to work through or a screencast I don’t have time to watch at the moment, I capture a link to it in Workflowy, which is always open on my desktop. When I have free time (say over lunch or in the evening on the rare occasion Twitter is quiet) I’ll scan the resources and work through whatever seems fun and useful, capturing the details in Anki cards or Evernote documents.

Browser bookmarks

Finally, don’t underestimate the power of quick access to the primary documentation. My Ruby Resources page has most of the usual suspects, but anything you use on a regular basis should be in your bookmarks bar, keeping many answers only a click away.