The Buckblog

This is the third article in a series titled “There is no magic, there is only awesome.” The first article introduced the “four cardinal rules of awesomeness”. The second article discussed knowing your tools.

Opening A.—Pass index finger of right hand distal to the little-finger loop, and passing round the ulnar side of that loop, bring it up from the proximal side into the thumb loop, and with the index finger pointing downard, take up with the back of the index finger the radial thumb string and return.

Even to string figure adepts, it can be challenging to parse those instructions. That paragraph is an extract from the instructions for an Eskimo Caribou string figure, written in 1903 by Dr. A. C. Haddon and published in American Anthropologist (you can read the whole thing on Google Books if you’re really feeling sleepless).

The original string figure notation described by Drs. Rivers and Haddon in 1902 used very technical anatomical terms to identify each finger, and the location of the string on each finger. As in that paragraph, you’ll see terms such as proximal (closer to the base of the finger), distal (closer to the finger tip), radial (closer to the thumb), and ulnar (closer to the little finger). These and other terms are used to describe locations relative to the fingers, as well as to name specific strings (“radial thumb string”) on the hand.

The strength of this notation is that it is very precise, and can be used with little need of external illustration. However, it is also fairly verbose, making it hard to parse without very focused attention and (potentially) multiple read-throughs. Also, the use of the technical anatomical terms makes the descriptions hard for novices to pick up.

To make her book more accessible to a larger audience, Caroline Furness Jayne (or “CFJ”) modified this notation so that “proximal” and “distal” were replaced with “lower” and “upper”, and “radial” and “ulnar” were replaced with “near” and “far”. (She left dorsal/palmar alone, for the most part, although in some figures she referred to the “front” or “back” of a hand or finger.) Her modifications introduced ambiguity, though, and required even more verbosity and copious illustrations to counter.

For example, she described the same movements (from the Eskimo Caribou figure) as follows:

First: Opening A. (The left palmar string must be taken up first). Second: Bend the right index away from you over the right far index string and over both strings of the right little finger loop and down on the far side of the right far little finger string; then draw toward you on the near side of the right index both right little finger strings and the right far index string, allowing the right near index string to slip over the knuckle of the index and to the far side of the finger. Now put the right index (still bent and holding the strings on its near side) from below into the thumb loop, by pressing the near side of the bent index toward you against the right far thumb string, and putting the tip down toward you over and on the near side of the right near thumb string. Pick up, on the far side of the bent right index, this right near thumb string, and lift it and the former near index string up by turning the index away from you and up to its usual position.

(I ommitted the illustrations for brevity’s sake, but if you want to see them, you can view the complete instructions here.)

The lack of technical terms is definitely an improvement, but the (significantly!) greater quantity of text means that the instructions require even more effort to parse. To combat this, the ISFA (International String Figure Association), in its publications, uses an abbreviated notation, numbering the fingers 1 (thumb) through 5 (little finger), and using other one-letter abbreviations for right (R), left (L), near (n), and far (f). They retain the use of proximal/distal in some cases, but also use “below”/”above” and “lower”/”upper” where it isn’t too ambiguous. The ISFA notation reduces the above text to this:

Opening A. R2 rotates away from you, over all strings, around 5f, then back under the strings, and proximally enters R1 loop. R2 hooks up R1n and retraces its path. (from http://www.isfa.org/arctic/30.htm)

This is much more concise, and is easier to scan. It settles on standard meanings of terms like “rotate away”, “hook up”, and “release”, which reduces verbosity, but also requires the reader to know how those words are defined in this context. Also, it is concise at the cost of specificity; there is often ambiguity that must either be resolved at “runtime”, or be countered with more verbose descriptions.

Two other notable attempts at describing string figures are SFN (String Figure Notation) by Eric Lee, and Mizz Code by Kyoichi Miyazaki (“Mizz”). The former is a variation on ISFA notation, employing various abbreviations to reduce verbosity, while the latter is an entirely new take on describing string figures that simply denotes how the string needs to move, without specifying finger movements at all. Both of these are much more concise than any of the others described above, but are also quite specialized and require some study before you can really make heads or tails of them.

So, that gives five different ways of describing string figure construction! How do you choose which one to use? Ultimately, the ISFA notation is the most widly used, as well as the verbose prose of CFJ (thanks to the popularity of her book). But a string figurist will benefit from knowing as many ways to describe a figure as possible, because each notation’s strategies reveal different insights into the techniques, and has different strengths in different situations. CFJ’s prose (if accompanied by a modicum of illustration) is good for beginners, because it does not require any specialized knowledge. The ISFA notation is a good general tool that allows people to quickly learn figures, with only a little training. And notations like SFN are great for quickly jotting down a figure as you learn it from someone else, or as you invent it yourself.

Really, as a string figurist, the more string figure languages you know, the more power you have.

Computer Languages

Thus, the second rule of awesomeness: know thy languages.

As a computer programmer, you’re faced with an even greater flood of languages than string figurists are. Even if you use primarily a single language, you might be surprised at how many incidental languages you use on a regular basis. Are you a web developer? Odds are that you dabble in both HTML and CSS, and probably Javascript, too. SQL is almost mandatory for most interactive systems. Furthermore, if you do anything at all in a text console, you probably know a little bit of shell script. Building your application and deploying it to production probably require a specialized DSL or two as well. And regular expressions are practically everywhere these days.

Despite there being more computer languages than string figure languages, the advice is the same: the more you know, the more power you have. And “knowing” is not merely “knowing about”. Look back at the four “knowledge gauge” questions from Part 2:

1. What does this do best?
2. What does this do worst?
3. Why should I use this in particular?
4. When was the last time I learned something new about this?

Take a minute and try to list all the languages you use on a regular basis. This includes even languages you use only tangentially, like SQL, regular expressions, Javascript, HTML, XML, CSS, and so forth. Try to answer each of the four gauge questions for every language in your list. If you struggle to answer any of them, consider that a jumping off point for further investigation.

If you aren’t really sure what a particular language is best or worst at, it may be because you aren’t familiar with enough programming languages to compare it with. You’ve probably heard the old saying, “to a man with a hammer, everything looks like a nail,” and that surely applies here. You may be at the pinnacle of guruship in your chosen programming language, but if that’s all you know, then you can’t give worthwhile advice on when that language should be used. You’re living in a house with no windows, and no matter how well you know that house, and no matter how big it is, you can never tell callers what’s just outside.

It’s been suggested by people much smarter than me that you should learn a new programming language every year. I can’t recommend this enough. I won’t deny that there have been years where I haven’t followed this advice, but every time I’ve spent a few months tinkering with a new programming language I’ve come away with my eyes open that much wider. It’s like having a lever, and finally discovering a fulcrum to use it with.

Learning a new language

Now, it’s all well and good to say “learn a new programming language”. It’s also remarkably easy to download the development kit for Ruby, Python, Java, Erlang, Haskell, or just about any other language you want to learn. And once you’ve started learning a language, the learning effect tends to snowball, so that’s not really a challenge either.

What’s hardest (for me, at least) is discovering a good “entry vector” into the language.

Here’s what works for me:

1. Find the documentation for the language. Look for a page or two that give you a glimpse into the syntax. Not every language provides an introduction like this, but when you can find one, it’s a great way to get a “feel” for how the language expresses things.
2. Next, look for a “hello world” example, or tutorial. Generally, these things are useless, but as an introduction to the language, it’s a good way to see what’s involved in a fully functional program. How much boilerplate does a program need? How is a program compiled or interpreted, and run? The “hello world” example is also a good place to start experimenting. As trivial as it sounds, try changing the string that gets printed. Try displaying an additional string. Hold on to this file; you can use it to play with as you progress through the next steps.
3. Now, look deeper. Try and find a more advanced tutorial. Look for examples that demonstrate writing procedures, objects, conditional branching, and so forth. They will almost certainly include concepts unique to the language, which will be new to you, but that’s the point! Work through those tutorials. Find additional documentation to clarify concepts that are unfamiliar to you. Go beyond the tutorials and experiment with these concepts, to solidify their meaning in your mind.
4. Once you’ve finished some tutorials, look for actual production code written in that language. GitHub is a fantastic resource for this kind of exploration, as are similar sites like SourceForge. Individual languages may have their own project “forges”, like RubyForge. Just find a project that looks interesting and read the code. This kind of “code spelunking” in a new language will give you valuable experience with the practical, day-to-day idioms used by experienced programmers, and will also give you solid examples of the concepts you read about and played with in the tutorials. (I intend to talk a lot more about “code spelunking” in the fourth article in this series.)
5. Lastly, think of a program or library you’d like to write, and write it in this new language. Nothing else you do will teach you the language as well as this step. You’re going to run into road blocks, but don’t get discouraged. If you need to do something that wasn’t covered in any of the tutorials, consider it an opportunity to read more documentation! Look at other projects and see how they accomplished similar tasks. Your first couple of programs in the new language will be very “unidiomatic”, but that’s how you start. Find someone experienced in the language and ask them to review your program, and point out better ways to do it.

By the end of the process, you won’t necessarily be an expert in the language, but you’ll know enough to compare it to other languages you know. You’ll also know whether you enjoyed the language enough to keep playing with it. Who knows? Maybe you’ll discover your new favorite language this way! I certainly wasn’t expecting to fall in love with Ruby when I started tinkering with it, but here I am, eight years later, and still tinkering.

Learning more

If you are already familiar with a language, the steps described above are not going to be as effective for increasing your knowledge. You’re probably in a rut, comfortable with what you know and able to accomplish almost everything you need to with it. That’s no excuse to stop learning, though; if you push yourself and learn even just a little more, you’ll almost certainly be surprised how useful that extra knowledge can be, even on a daily basis.

But how do you push yourself out of your comfort zone? This is probably harder than learning a new language, in many ways, because when you’re in the rut, it’s hard to see what the benefit of more knowledge would be.

One way is to find a good reference for the language, electronic or otherwise. Spend a little time each day (even just 15 minutes!) skimming that reference, looking for something you didn’t know before, or weren’t as familiar with as you would like to be. Once you find something, spend a little time playing with it. Find a way to add it to a project you’re working on. Blog about it. Tweet it. Just do something with it! Then, try to do something with it on a regular basis, so it stays in your memory.

Another technique is to find a library or program that uses concepts that are new to you. Unfamiliar with socket programming? Look for a networking library to read through. Want to be more familiar with threading techniques? Look for something that does a lot of parallel processing. Even if you have no specific learning goal, a good starting point is to select a programmer you admire, and find projects that they’ve worked on. You’re sure to find idioms, tips, tricks, and language features you’ve not seen before.

Ultimately, though, the game is not about “who can learn the most programming languages”. No one is keeping score. There is no tally scratched into the bedpost of your career, here. The goal is to educate your opinions. Awesome people have opinions born by experience. You want to be awesome? Then you need to be willing to keep pushing the envelope of your knowledge. Never settle for what you already have, even if you’re otherwise content. Keep looking. Lift the curtain on the unknown. If you want to be awesome, you need to explore.

Know thy languages.