Esteem-Oriented Programming

I enjoyed reading an article from a fellow named Ben Northrop. About 90% of the posts I find by way Hacker News, et al, are crap; in a roundabout way that’s actually the topic of this post.

I am vastly more cynical than Mr. Northrop. I stormed through his essay and was annoyed that the programmer motivation I’d been spending the past few months thinking about was missing from his diagram. I stewed overnight, ruminating about my own post, the re-read Ben’s post, and realized my mistake.

I felt Ben’s diagram was missing a corner- the one I’d been thinking about myself. In my first read of the post though, I’d skipped the first sentence where he describes being technological motivation as being for the love of learning. A cynic might call this adopting technology for the sake of adopting technology, although that’s not always a bad idea. I think this idea makes more sense in the hardware world, where it’s very easier to measure improvement in terms of cost or efficiency. In software, I usually think of technology-for-its-own-sake in the context of a suggestion that we change a language or a library along with a vague promise of improved productivity or reliability. It’s usually hard to prove.

Anyway, my first take on Ben’s essay was that he meant that technological motivation was a sort of righteous march out of one paradigm-age into the next. I’d been thinking a lot about the current that is driving the adoption of Functional languages in industry. The functional idiom is one of my favorite aspects of programming, but having witnessed the rise and fall of Object-purism during my college years, a lot of the software pop-culture surrounding FP is I think being promoted by same breed of hot-house flower that aimed to encode the world as an object or a design pattern.

At this point, I should pause and offer you my sincere promise that this is not a slag piece on the functional paradigm, or it’s languages. At my new gig I’m knee deep in Scala and Erlang, and I’m enjoying them tremendously. Also, I don’t have to remind you that FP is absolutely not new, nor has it remained unpopular until today.

What has bothered me though is the trend where developers acknowledge the shortcomings of the paradigm (chiefly the learning curve) vs the strengths (ease of concurrency, or whatever your favorite benefit is) but then ignore those factors and go ahead and use the functional tools anyway. There’s a kind of tacit acknowledgement that these tools represent the new thing, and that settling for the old thing would be embarassing.

The argument that I am going to make is not advanced very readily down this avenue, so I’ll apologize and take an abrupt turn.

The other habit that I notice now is programmers talking a lot about whether the code they are writing is idiomatic or not. Whether code is idiomatic or not is subjective, and programmers who go to any length to achieve idiomatically-correct constructs in their programming are, ultimately, striving to satisfy someone else, whether they recognize it or not. It is the same as trying to please your conversation partner by speaking a foreign language with a correct accent.

Who could fault a person for trying to speak with the local accent? At worst, the person might be trying to blend in to the culture. More practically, he or she might simply be trying their best to be understood. Really, it doesn’t matter, because people do this all the time and nobody thinks its wrong. Regardless, its still a thing that people do for their esteem; we want to be understood, and to fit in.

The same is true for idiomatic style in programming. Although people like to claim that programming “idiomatically” has advantages unrelated to esteem, reading code is nothing like participating in a conversation. In order for a programmer to recognize that a construct in a program could be simplified, he must have to understand it first, otherwise he couldn’t possibly know how to substitute a more idiomatically-correct improvement. You might argue that time is wasted by not using the most familiar constructs from the idiom, but I think you’d be wasting your time, because programmers delight in using constructs that trade obviousness for conciseness, and other programmers are willing to accept these clever constructs as a kind of cost-of-doing-business. And then they repeat them.

This is not a habit that programmers adopt in an attempt to be more clear; it has everything to do with being seen as clever by other programmers. It is purely an effort to boost one’s esteem in the community of programmers who read the code. I can’t think of a single instance in which I saw a Perl programmer use the so-called Schwartzian Transform in a program where there wasn’t a corresponding comment above the block that pointed out the fact, lest it go un-noticed. I think of this as esteem-oriented programming, and I feel that it is the missing vertex of Ben’s polygon.

Alright now I’ve said it. I can hear the cogs whirring, the arguments being formulated, outlines of lengthy comments clattering into emacs. The jokes on you since I haven’t bothered to add comments to my blog. The thing is, there’s nothing wrong with doing things for your esteem. I do it constantly. I tell stories in order to show how much I know about obscure subjects. I comment in meetings to make it clear that I understand a thing. I make jokes to make it clear that I can draw analogies from the topic at hand. I’m fine at it, but I understand that I’m far from being the most clever person on earth but that there is still value in managing my esteem as a programmer, including trying to adopt the idiom of a given language when writing code.

What programmers need to understand, however, is that in the workplace the decisions that they make, whether by trying to find opportunities to substitute idiomatically-correct but perhaps less than intuitive constructs into a program, or when they select Haskell to write a program that might as easily have been a shell script, is that their choice comes with a cost. If the program is very short but difficult to understand, years later a junior developer might be tasked with fixing it, decide the program was unreadable, and rewrite it. If your program is written in a language that attracts other esteem-oriented programmers, they may be unable to fight the urge to rewrite it in the latest popular language. When you write intensely clever programs, other esteem-minded programmers often look upon the program as a challenge; how can I improve upon this?

In every decision you make as a programmer, you must acknowledge the role that esteem plays in your life, and consider that your own esteem and the esteem of others may play in the future of your work, and the work of others. Do you want your work to endure strictly because it was clever, or because it was thoughtful to the organization you wrote it for, and to the people who might be tasked with supporting it? Now consider these same values in the context of selecting languages, tools, or any other piece of technology. The point I’m trying to make is that there’s no shame in considering one’s own esteem. You just need to treat it like any other cost when evaluating options.

Ultimately, the way you make a lot of money in this business is by making money for the people you work for. It is difficult to to measure the amount of joy esteem brings a person, but the number of programmers that I’ve personally observed to have become wealthy by getting things done, as opposed to getting things done in a clever fashion, is lopsided. Ultimately, I think that a programmer who can get things done efficiently, and siezes upon the opportunities to be clever in the process, is the most successful.