Wednesday, December 31, 2008

No New Language In 2009; New Habits Instead

The Pragmatic Programmer gives a very popular bit of advice: learn a new language every year. When you learn a new language, you learn a new way to think. You discover new strategies and solutions unique to a particular language's particular culture. And that's all well and good - except that it's kinda bullshit.

First, the thought-changing nature of learning a language is based on something Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing." First, this doesn't imply that every language you learn will change the way you think - in fact it implies quite the opposite. Second, Perlis also said "Bringing computers into the home won't change either one," which is at the very least disputable.



Like any other computer guru, Perlis was always opinionated but only sometimes right. But there's a more important objection. You can't learn a language in a year. It can't be done. I've been writing Ruby for three years and I don't really know it.

There's a great book by Douglas Crockford called "JavaScript: The Good Parts." One of the great things about it is that it's a freaking TINY book. But there's a gigantic book by Damian Conway called "Perl Best Practices" which is really just a very verbose edition of "Perl: The Good Parts." Both books say here's a language with a ton of features; use only these features. The thesis explicit in Crockford's book and implicit in Conway's is that the best way to use a language is to carve out a subset of its functionality that is superior to the whole smorgasbord you have on offer. It's how people use natural languages, and it's how a lot of good programmers use programming languages as well.

In the three years I've been writing Ruby, I've carved out a Ruby subset I'm comfortable with and powerful with, but I still haven't mastered it - and it's just a subset of Ruby. Ruby 1.9 will redefine the problem for me before I ever master Ruby 1.8. And if you don't think that's true for you, you're lying to yourself.

This subset thing isn't just the best way to use a language, either. It's the best way to use a computer. First thing I do when I get a new box is I pull the bullshit off. No Spotlight on my OS X box; no spelling correction active in any application I own. I've never in my life seen a spellchecker that could outperform my own perfectionism, or even one that showed respect for my name. No, I did not mean to type "gills," "files," or "geese." Thank you so much for asking. I hate spellcheckers with a passion. Excuse my French, but as an iPhone user would say, they can all go duck themselves.



Back to the topic of languages. I met some guys once, when I was looking for a job. They had an app built in Erlang and were working on building one in Seaside. They wanted to do something pointless and insane with Seaside. I can't remember what, but I remember that it was something you would only ever try to do with Seaside if you had no understanding of what made Seaside different from other Web frameworks. I scratched my head over it, and then I found out the details of the backend app in Erlang. Turns out you could have handled it just as easily with Python and cron.

There were two bizdev guys and a programmer with a beard. I called it - I knew he was a programmer from his beard. I was like, ah-ha! He told me, "yeah, the other guys told me to grow the beard for when we talk to VCs." The bizdev guys had found him somewhere and they had him "come on board as co-founder" (as is the custom among their people). That's when I got it - the programmer was as cynical about these guys as they were about their VCs. He was using them to pad his resume with bullshit projects in exotic languages.

If you do that, Zed Shaw will find you and skullfuck you to death. I'm not kidding. He and I have made a deal with Satan, and this was one of the perks he requested. I can't go into any more detail than that, because Satan made us sign an NDA, but believe me, you'll get what's coming to you.



The only way to learn Seaside is to build a project in it, and not just any project - it has to be a project for which Seaside is a smart technology choice. Same with Erlang. If you write a project in Seaside that has nothing to do with Seaside's strengths, you're not going to learn much.

If you do it right, you'll learn a little. You'll end up with a subset of Seaside you haven't mastered. Beginning to define the subset is as close as you'll come over the course of a single project. But that's still something.

The Pragmatic advice remains great advice, but don't be a monkey about it. You shouldn't always follow good advice, but you should always take it into account. You have other options besides the literal interpretation.

For example, address a new problem space every year. Choose music, robotics, hardware hacking, machine learning, natural language processing, whatever makes your brain pulse. In 2008 I didn't bother to learn a new language, but exploring a new problem space set my brain on fire, and speaking at a lot of conferences taught me a lot.



In 2009 I'm not planning to learn a new language either, although I am planning to put up my first production app in Seaside. In fact, I'm looking to launch a ton of micro-apps and nano-apps. It started when I realized a fundamental flaw with the Rails Rumble: if you can code it in a weekend, why wait a whole year? (The Rumble guys are considering a monthly version, by the way, although nothing is finalized yet.) Frameworks like Rails make you fast, and Sinatra makes even Rails look slow.

I got a head start in December with BoingBoing Minus Disneyland, which screens Disneyland posts out of BoingBoing's feed like a precise inverse of the usual robot goody two-shoes screening out profanity. I'm going for a new app every month, because the other flaw with the Pragmatic advice is that it gives you a big, imprecise goal with a far-off deadline.

That's a recipe for FAIL. You want well-defined goals, tight deadlines, and repetition. Once a year won't cut it. Aim for once a month or once a day. Repetition is key to excellence. Check out the "Quality vs. Quantity" story in Art & Fear, which Ryan Davis recommended at GoRuCo this year, or 5 Steps To Mastery, which derives the lesson from the experience of masters in a wide range of fields, from Linus Torvalds to Carlos Santana.



Repetition makes a huge difference. That's why, for my music, I'm putting a new beat on Twitter every day. But you have to offset repetition with stronger challenges. A year from now, I don't want to be looking back on 365 trivial, meaningless little beats.

The answer's in Dan Ariely's Predictably Irrational, which, at RubyFringe, Obie Fernandez told everybody to read. The research suggests that gating your goals with predetermined deadlines works much better than giving yourself one big deadline way off in the distance (which again clashes with the "one language per year" idea).

I haven't figured out yet exactly how I'm going to use this, but it'll probably look like this: one new beat per day, one new track per weekend. One new app per month, one milestone on the app per week. The goal is not to establish a far-off goal and find a way to hit it, but to establish a series of tiny, immediate goals that keep you forever moving forward. Aristotle argued that virtue was mostly a matter of having good habits; Lao-Tzu tells us that the voyage of a million miles starts with a single step. So the key is to get moving and keep moving.