Paul Graham is, among many things, a computer scientist, entrepreneur, and founder of Y Combinator. He’s also an excellent essayist.

The Blub Paradox is a concept from his essay Beating the Averages. You should certainly go and read that, but I’ll summarise it here for completeness of the Motif canon.

For the sake of argument, assume that some programming languages are more “powerful” than others (i.e. more expressive) in some meaningful way. It follows that, all else equal, you should choose to use the most powerful language for any given task. Doing so would give you an advantage over others using less powerful languages.

And yet we don’t. Why would we choose a less powerful language? It turns out that our familiarity with a language colours our perception of its power.

Imagine that you are deeply familiar with a moderately-powerful language called Blub. Your brain works the same way that Blub works. Given any particular problem, you can immediately see how you would use Blub to solve it. Blub seems very powerful!

You can easily look down the ladder of power, and notice that Blub is more powerful than, say, machine languages or Cobol.

But what about a language that is objectively more powerful? If the features or characteristics that make it so are unfamiliar, you won’t comprehend the ways in which it is more powerful. Perhaps it will appear similar with some extra weird bits thrown in.

The paradox is that greater familiarity with a language can actually impede our judgement of its relative power. In order to make accurate judgements about the power of languages, you must first be familiar with the most powerful language. Only then can you comprehend the features that Blub lacks, and formulate qualitatively better solutions to particular problems.

So what’s the takeaway here?

If nothing else, it’s a refreshing reminder to avoid becoming complacent. No matter what languages you use day to day, you’re free to experiment with and learn new ones with those extra weird bits, and kick your brain into a higher gear. Indeed, employers should encourage the practice.

And of course whatever may be said of languages also applies to some degree to other technical concerns, such as frameworks, libraries, tools and processes.

Graham also briefly touches on the messy question of how to choose the most appropriate language for a project. Even with perfect knowledge of linguistic power this remains a hard, multidimensional problem. Yet that knowledge is still valuable in the general case.

Graham’s personal example is that of a web startup: a greenfield project with a small and talented team. This is the best-case scenario, and nothing prevents the adoption of his preferred most powerful language (Lisp). As a result, the team is unbelievably productive and beats all the competitors. Hooray!

It’s a nice story. Of course, rarely is anything so clear cut. So what can we learn?

Working backwards: success came from competitive advantage, forged by wielding the Most Powerful Language, the choice of which was enabled by the environment and made by the talent who was already familiar with said language.

1. Regardless of your environment, the first step is outside of your comfort zone. Explore unfamiliar languages, learn about their features and mental models, and be the talent that can propose that choice.

2.The second is to find — or create — the environment within which such a choice could be made. Seek out or propose greenfield projects, and involve others who are agitating to try new things. Startups get this for free; in the enterprise it’s the concept of intrapreneurship.