Blaming your tools

Whenever race car drivers serve up excuses for why they didn’t win they tend to blame their equipment, their team or both. It is never the fault of the race car driver that she or he fails to win. It’s the suspension. It’s the engine. It’s the wrong tyres. In many ways, race car drivers have that in common with a certain class of programmers who blame anyone but themselves for their hardships.

Programmers love to blame their tools. Their code sucks because the language sucks. Or it sucks because the frameworks and libraries they use suck. Or, if they are particularly full of themselves: whatever paradigm the language is built on itself sucks.

I came across a fellow on youtube who spent an entire hour bemoaning object oriented languages as being anything from “pathetic” to “embarrassing”. And yet all I was able to take away from the video was “this person has no agency”. He wasn’t really complaining about the object oriented paradigms - he was complaining about how he himself chose to make use of it to solve problems.

Programmers are prone to dogma and superstition. Most programmers write code as if some judge is looking over their shoulder and awarding points or demerits for their ability to stick to some dogma. Which sometimes leads people to write really clumsy and ugly code because it is what they think is expected of them.

This is probably not a big problem if you are a junior programmer. It can even be useful to not hold too many firm beliefs until experience and a personal portfolio of failures begins to provide some basis for reflection.

But if you are a senior programmer, or aspire to be one, you’re in trouble if you write code like that.

Java and people dreaming of functional languages

I used to program in Java.

A lot of people hate Java - though they can’t always articulate why. I think Java was an okay language with a good runtime and a good standard library. I came from C and C++ where there really wasn’t any standard library to talk of. At least not in terms of what we expect from standard libraries now.

It was possible to find a programming style in Java that worked. The language has good compilers, a good runtime and a huge community around it. Things you really want and need. Sure, there’s a lot of junk in the Java world, but there’s also a lot of high quality stuff.

The law of the land

Initially, when I was new to Java I tried to live by the law of the land. To follow what people liked to tell me were “best practices”. So I tried on lots of “best practices”. From how you structure things at a micro-level to what frameworks and architectural choices you make. A lot of them didn’t really fit me. But at least I tried them.

For some of these areas where I felt discomfort I was able to articulate to myself why I was feeling discomfort and what could be done about it. Understanding why you think something is awful isn’t always easy because there’s anything from your ego to the dogmatists trying to tell you what’s right between what you experience and the root causes.

Evolving

I used that to evolve my own style of how I used Java. I also met, and then worked with, other people who had done the same. And eventually I started re-training Java-developers to adopt some of these practices. I think the style can best be described as “minimalist with elements borrowed from functional programming”.

Yes, I would have hated Java deeply if I had stuck to prevailing dogma. But I didn’t. Because there really was no need to. And it was entirely possible to live with Java without undue suffering.

One thing that has always puzzled me is that the majority of programmers I’ve met who whine to their managers about wanting to use some functional language often show no ability to adopt the practices they presumably long for in whatever language they are already using. And that’s curious.

If you want to use functional programming, yet plaster your Java code with mutable state needlessly, and fail to write code without side-effects where opportunity arises, what competent manager is going to take your suggestions of switching languages seriously?

Why did I switch to Go?

As a programmer, and as a manager, I’m opinionated about programming languages. And I’ll freely admit that there are lots of languages I am not going to touch if I can avoid it. Sometimes because the language is unappealing (like C++), sometimes because they impose a burden on the user (like Python), and sometimes because the culture is too sloppy for my taste (applies to lots of languages, but you can probably guess which).

I’m primarily a pragmatist. I didn’t choose to switch from Java to Go because I read Hoare’s CSP-paper and figured I’d throw away 15 years of experience to start anew because I like channels and goroutines. I switched because I could see how Go could work as a workhorse language. (Something Occam isn’t and will never be).

Rust was a contender at the time, but Go was pointing more in the direction I wanted to go.

Community and knowledge base

My first requirement is that the language is suitably mainstream. Yes, I avoid niche languages. Remember, I’m a pragmatist, I’m not in it for the navel gazing and some deep interest in programming languages. I want to write code.

Languages need large communities to produce a knowledge base and a recruiting pool. Communities that are large are also more likely to develop arenas for more specialized knowledge.

You want to be a bit picky about what the community is like, because learning a programming language that is going to be your primary language is a major investment. You’ll have to get along with them for a while.

Something that hurt, for instance, the Lisp community was the attitude among some Lisp-programmers that it didn’t matter that there were so few Lisp-programmers available for recruiting, because the quality of those who did Lisp was so high so it would be worth it. Only really smart people use Lisp. And if you ascend to their level you might be worthy of hiring them. I’ve known people who were exactly like that.

Of course no sane manager wants to hire anyone with that attitude. It doesn’t even matter what language we’re talking about.

Next aspects such as the standard library and the body of published open source libraries matter. After that come practical matters such as runtime, tooling etc matters a lot because you are going to spend a lot of time interacting with these.

What paradigm a language follows is pretty far down the list, and long before we get there, the language will either have shown itself to be conducive to productivity or it won’t.

But pretty please, don’t blame languages for how you yourself use them.