See part 1 here.

Versatility vs Buzzwords

It struck me fairly early when I started working as a programmer that the simplest and (still, I believe) best way to become a better programmer is to become more versatile. I want to make this concept distinct from “just learning a new technology” (or its more pernicious form, “adding a new buzzword to my resume”). There’s really two distinctions. First, it requires much less effort to add a technology to your resume than to really learn it and benefit from learning it. Second, not all topics are created equal for learning purposes (but a new buzzword is a new buzzword).

 Getting your feet wet by programming in Perl for 3 days doesn’t make you a better programmer. Deeply learning 15 programming languages won’t teach you too much after the first five (presuming those five are sufficiently different). Learning the Django framework when you already know Rails isn’t going to make you more versatile. And neither is learning VB.NET after C#, or vi after emacs. It’s not that these adventures won’t or can’t help, it’s just that there are better ways to spend your time if you are interested in expanding your horizons.

Finding holes

Becoming more versatile is about learning entirely new classes of solutions. Find the parts you are truly unfamiliar with (or even scared of) and jump straight in. If you don’t know anything about databases, learn the details of PostGreSQL. If the only programming language you know is C, how about mastering Ruby? Learn how to really use a debugger, or a profiler. Figure out when radix sorts are appropriate. Or you could try perhaps finally reading that book on regular expressions.

Put another way, do you know that aspect of software development that you consider uninteresting or too far away to be of value? I used to think that way about networking. What’s yours? Inline SSE assembly? Compilers? The JVM? Stop pretending it’s not important and dive in. I guarantee it has something to teach you. These types of learning exercises expand the class of solutions to which you are exposed. They put more mental tools at your disposal when faced with a future problem. It will let you see analogies between problems (and later, analogies between analogies). You will be the guy who comes up with an incredibly novel solution to some difficult problem. Except it wasn’t novel at all. It was just borrowed from a far away place.

This entire thought was brought into focus for me when I saw something really simple on someone’s resume. Let’s look at an example line.

Programming Languages: C, C++, Java, Python, Ruby, Lisp, Prolog

What does this mean to me? It means that this guy has dabbled in a bunch of popular languages… and Prolog. Prolog? The odds say he probably knows one or two of these well. I’ll need to talk to the guy to figure out which ones he actually knows and what he actually knows about these languages.

Programming Languages: C/C++/Java, Python/Ruby, Lisp, Prolog

I don’t know if the above line is grammatically correct but I don’t really care. This conveys more information about a person. I still believe he’s dabbled in these languages and probably knows a few of them in depth. It also tells me that this person actually knows something about these languages beyond their syntax. He knows where they fit. More importantly, this guy probably didn’t make the conscious decision to do this. It just felt right for him to group them this way.  It’s almost as if what he’s really trying to subconsciously convey is not the languages that he knows, but the paradigms that he knows.

Now, don’t get the wrong impression. It’s just silly line on a resume. No one is getting or losing an interview because of this. But even still, the programmer part of my brain was drawn to the hierarchy imposed. 

On Aptitude

I’ve religiously seeked out the areas in my knowledge that were completely empty and tried to fill them. That worked great at exposing me to the breadth of computing. But still I wanted to become more proficient. More apt. There’s a difference between being well versed and being ridiculously good. I’m not really sure how much aptitude can be trained, but here’s some thoughts.

First, and foremost, practice correctly. That doesn’t mean writing code often. It means writing hard code often. In much the same way I never really became comfortable with algebra until calculus, nor comfortable with calculus until electromagnetics, equally, you will never become comfortable with hard computer science constructs until you use them frequently. Linked lists cause students problems until they’ve written them half a dozen times. By writing hard code, you internalize the concepts. You’ll be ready to move on to increasingly more complicated mental abstractions. This type of practice builds up your mind’s endurance for dealing with complex mental models. And the good news is that it never ends. There are always extremely difficult concepts just out reach begging to be learned. 

The second way is to learn new languages. This dovetails with much of what has been said above: you need to focus on the languages that are diametrically opposed to your comfort zone. As always, there is a right and a wrong way to do this. The wrong way to do it is to spend a week learning each on the most popular languages, and then slapping them onto your resume. Honestly, no one is going to believe you are an expert on C/C++, Ada, Java, Smalltalk, Lisp, Scheme, Haskell, Erlang, and Forth — even if you are. But if you did deeply knew all of those languages, your perspective on certain problems will drip with your experience.

My advice goes one important step beyond learning the “correct” languages. There are many people who have made arguments about which languages you should learn to “expand your mind”. So I’ll spare you, save this: C and Lisp. Everyone should learn C and Lisp. The interesting part for me is how you know you’ve actually learned a language. Learning a new language doesn’t mean learning how to convert your C code into Python code. Hey look! You know Python! No, you don’t. I’ll tell you the secret: learning a new language is about learning how to think like programmers of that language.  Its about working with and understanding the philosophy of the language. Here is my rule: you’ve truly learned a language when it changes the way you write code in other languages.

trackback