How to Cheep in Many Programming Languages (not a tutorial, but a spiritual journey)

I have a small problem.

The first part of the problem is that I’ve been a Perl developer for the past decade—

That came out wrong. Let me start again.

I have a small problem.

The first part of the problem is that I’ve been enjoying Modern Perl for the past decade while not learning any other programming languages. Don’t get me wrong: I love Perl, and I love programming, and I love learning new things. But since 2006, I’ve mostly been focusing on personal growth.

I’ve been trying new things. I learned to write. (At least I believe I did.) I studied psychology, philosophy, and religion. I sank into a van-Gogh-sized depression and didn’t know why, clawed my way out of that into paralyzing anxiety and boredom, lost almost all of my friends, discovered psychotherapy, made new friends. I learned how to be a father and lover, and am now learning how to be a mentor to two young adults and how to be single. I tried my hand at being an indie author for a while, which earned me just enough money to double the loose change I found under the cushions of my couch.

In the end, that wasn’t really about money. None of it was. It was about rediscovering myself, or maybe discovering myself for the first time— That’s a story I’ll no doubt tell on my personal blog, which I believe currently has a readership of my parents plus three random strangers who stumbled onto the site by accident, and I may have pissed off my parents.

Anyhow, the bottom line is that the list of programming languages in which I feign expertise is a little out of date, and I’ve been working hard at expanding it. I’ve taken a liking to Python—a low-hanging fruit for a Perl expert, which I’m sure upsets both Perl and Python devotees. I’m falling in love with Django (and that’s not an exaggeration of how I’m feeling about it). I have a personal project in mind that I think Flask will be good for. I’m intrigued by Dart and Go and should refresh my Java skills. I’d also like to do something substantive with Perl 6, and although I know JavaScript, I’d like to play with Angular, React, and Node. And AngularDart! All of these are on my short list.

The second part of the problem is that all programming languages are the same. Boring. Okay, let me backpedal a step. Yes, there are differences, and sometimes those differences even matter.

For example, you’ll note that I did not mention PHP anywhere, not among the languages I’ve used nor among the languages I’d like to use. At this point, I need to confess, I’ve been dishonest by omission. I’ve probably done as much PHP development as I have JavaScript. But PHP is one of the worst programming languages ever invented. It’s right up there with Brainfuck, except that no one has ever even attempted to develop an enterprise CMS in Brainfuck. PHP is the lowest common denominator of programming languages. It’s a broad path among a variety of narrow gates. PHP makes it easy for amateurs to start down the road to implementing bugs. The plethora of PHP web systems out there is the bane of my professional existence. [1]

So language design does matter. But I think in practice it matters a lot less than many people seem to believe it does. And most of what matters is preference and prejudice born of personal experience. Once you elevate your code above beginning PHP, naïve JavaScript (the not-Good Parts), and 1990’s-era Perl (the kind used in 10,000-line CGI scripts), the differences become more nuanced. Language wars are a notch below sexism and racism: the category differences are minor or may not even actually exist, and they’re some of the most significant factors in our choices.

And in that realm of programming languages and practices… Boring. I really don’t need to learn a dozen different ways to print “Hello, World!” To me, that’s about as engaging as sexing chicks. (Hence the title of and photo at the head of this blog post.)

I need interesting challenges to tackle. And this is the third part of the problem. Or just a (single, solitary) interesting challenge to tackle umpteen times, although I can also imagine that becoming boring. [2]

“Another technical journal, Scotty?”

“Ay.”

“Don’t you ever relax?”

“I am relaxin’.”

I think this is part of my personality. I’ve heard that there are people who can pick up a list of to-do items and just do them, in priority order, until each one has been checked off. I think I may have even worked with a team lead who was like that. He and I did not get along too well, and this personality difference may have been a contributing factor.

In any case, I need to find a motivator, some aspect of the task that sparks my interest, or else I simply can’t focus. My eyes glaze over, and my mind leaves, goes somewhere else—anywhere else that’s more interesting.

If I have a task to do, it helps if I remind myself of the significance of the task. Why I’m doing this is sometimes more important that what I’m doing. It also helps if I’m working with another person, especially if we’re pairing on the task. But more than anything else, it helps if I can choose the characteristics of the project such that working on it helps to meet my emotional needs.

I’ve been going over the qualities of such projects. Here are some that I’ve considered:

• It should challenge me intellectually. It should be complex enough that I need to figure out how it works. At the end of the day, I should feel like I’ve accomplished something new. That probably means it shouldn’t be something I’ve done exactly before, although it can be a variation on a thing done before. It’s possible that implementing the same solution in a different programming language or framework might be a different enough variation to hold my interest, if the problem has enough moving parts and interactions.

• It should give me choices to make. This is related to the point above, but it targets a different need. I want to have some control over the solution. If I’m just following a script, that’s a tutorial, not a programming project; it’s a rote exercise, and the choices have been made for me to start with. Part of what I love about being a software developer is that I get to create a solution that in some measure expresses who I am.

• It should be something that others can also understand. I want bragging rights. I want to be able to publish a post here sharing the fascinating intricacies of the problem and how significant it is. And I want average Joe programmer to immediately grok why I find it fascinating and significant. I don’t just want to be heard, for example, by those who (like me) find behavioral economics fascinating or those who (like me) would totally read a scholarly dissertation on machine learning using neural networks, just for the fun of it.

• It should be a problem that others are also working on. No, more than that. It should help establish a sense of community. This happens when, for example, I contribute to an already-existing open-source project. I’ve been a little disheartened by the high barrier to entry and low process quality of many such projects. (That’s a different post.) However, there are a few I have my eye on, to contribute to interesting open-source projects that use technologies that I’m not currently familiar with.

• It should make the world a better place. I’m not talking about eliminating world hunger or curing cancer—although those would be great. But I would like to feel like I am part of society’s solution, not part the problem. Part of this is living within my integrity, within my values. The other part is making a difference. This does not need to be a purpose of the software itself, just part of my overall goal in working on the software. And it doesn’t have to be a grandiose purpose. The purpose could be as simple as making code beautiful again or spreading the gospel of test-driven development.

As I was writing out these bullet points, I realized that these are exactly the qualities I want—or need to make—in a paying job as well.

This post took an unexpected turn. When I started, I intended to ask for suggestions of programming problems that might excite me. Now I see that the issue goes much deeper than just finding a fun set of things to work on.

(That’s been my life for the past several years, unexpected turns. I should be used to it by now.)

I’m going to leave that unexpected shift in the blog post, unedited.

And I’m going to start making fun and meaning in my day.

Still typing…
And may all your bars turn from red to green.
Tim

[1] That said, I could imagine a development organization that has processes to patch PHP the same way we patch JavaScript and Perl, by assuring that we’re only using the Good Parts and using idioms and practices that help protect us should we accidentally step on a programming landmine. It stretches my imagination, but yeah, I could imagine it.

[2] One might argue that learning all the exceptions to the exceptions to the rules of a language is what makes learning new programming languages intrinsically interesting. And while I can understand why someone might feel that way, that someone would not be me. I am of the mind that good programming languages have a relatively small set of orthogonal rules. If I have to learn a long list of exceptions to the rules and exceptions to the exceptions to the rules, that feels frustrating, not interesting. This is one the issues I have with some Perl code, honestly, and why I think we find that, in production, we use idioms that restrict the expressiveness of our code, in favor of clarity.