One of the difficulties I have in writing blog posts is feeling as though I lack the ability to say something conclusive, some wit or wisdom that can wrap up my thoughts in a clever, prosaic bow. Perhaps it was all those years of papers that needed to be written with an intro, body, and conclusion.

But on the question of Next Big Language[1] (in a personal sense) I admit I’ve been tossed to and fro over the years in my attempts to improve as a programmer. Many people I admire recommend trying to learn a new programming language each year. I’ve pursued this model or something like it, using the aspirational punch of New Year’s day to resolve to take up something new. As the year develops I move from basic syntax to contrived problems to some form of personal project. By the end of the year I’m starting to lurk within the community, reading the more heavily trafficked blogs and checking on events and conferences (never going of course). Given my propensity to look for heroes, I’ll seek out the more vocal thought leaders, all of whom have used said language and availed themselves of the community… for years.

The irony is that in my attempt to improve as a programmer I reach the fledgling stages of using a new language and then abandon it; the year ends and I’m fatigued by overcoming the really hard transition from understanding syntax to understanding idioms and techniques that make the language really different.

My team is switching to Git so last week I dug up the infamous Linus Torvalds talk at Google on the story and thinking behind it as a source code management system. In between calling users of CVS (include yourselves, users of Subversion) who disagree with him “stupid and ugly” there was a little gem in there: that he thought he could write his own system, better than CVS, in a couple of weeks. It kind of blew my mind but after thinking about it a little it seems (whether it took two weeks or longer) that Torvalds succeeded because he had defined a good problem and conceived a solution for it[2]. It wasn’t that he used a special language or tool, it was because he had a good problem set.

This year I am going to try something different. Instead of seeking out the new in my toolset, I’m going to turn back to what I know and use on a daily basis. After more than a decade, it’s easy to fall into old habits and use time pressure as an excuse for ignoring newer, better techniques that exist today[3]. Rather than gaining my novelty from a shiny new language, I’m going to try to shift my focus to problems: finding tough ones, coming up with good solutions and being persistent about getting them solved. Some problems are solved quickly (and oh how so many of us like to brag how quickly we got something done) but a lot of them take a long time on the order of years of accretion[4]. And out of the years of accretion and persistence real expertise is born, the kind where you can make a meaningful presence with something to offer in the programming community to which you belong. Or so I would hope: this is my present thinking.

I wish I had some conclusion, some form of wisdom on learning new language sand becoming a better programmer. Instead I am limited to anecdote, experience, and personal experiments. This is the 2013 version where my resolutions as a programmer are directed at problems before solutions.

 

[1] Homage to Steve Yegge who wrote a lot about the Next Big Language.

[2] Some might discount the fact that Linus was really writing his own version of a distributed version control system modeled on Bitkeeper – hence it wasn’t really that big of a deal. This brings to mind a Picasso quote:

“Good artists copy, great artists steal.”

Porting an idea is a good problem to work on and even if Git was inspired, it does have meaningful differences as this old email from Linus indicates. I can only imagine how different they are now, 7 years later.

[3] I can think of countless examples: in C# I often use iteration where I could take advantage of LINQ. I often misappropriate CSS style definitions and don’t take good advantage of combining CSS classes with JavaScript.

[4] Although this should be self evident, how about the language of C# itself? Very useful from the get go but trying to revisit code from the past without generics and LINQ is quite painful. It bears mention that there is a balance of a solution getting better and then when the solution begins to get bloated from unnecessary features aka “creeping featuritis.”