24 December 2020

The Polyglot Developer

Here’s my statement: personally, I’m convinced that every programmer should know more than one programming language. In other words, when it comes to programming languages, a developer should be a Polyglot.

Main vs. Secondary language

To make things easier let me clarify some of the vocabulary used for the remainder of the article.

I believe that at any given point in time there’s always one programming language that one prefers, I call this a person’s “main” programming language. The programming languages someone knows besides his main programming language I call “secondary” languages. Also, during a lifetime, your main programming language could change. I think that is normal and I have seen a variety of reasons that could explain why this happens.

The Expert

A common argument that I hear in discussions about being a polyglot developer is about the price you pay for knowing more than one language. Some people are convinced that learning another programming language comes at the cost of gaining less expertise in their main language. The reasoning behind this argument is that time spent on learning another language can’t be spent on harvesting extra knowledge regarding your main language.

I don’t follow that train of thought. On the contrary, I see another analogy: when practising sports it’s known that practising one sport could make you better in another. Sure, you’re not going to win gold medals in both and probably darts won’t make you a better swimmer. On the other hand, as a climber, I know that yoga helps to enhance core stability and flexibility. So practising yoga can make you a better climber. In summary, learning an extra language often also improves other programming language skills.

A bigger toolbox

Furthermore, I’m convinced that learning multiple languages give you a bigger toolbox. It broadens your horizon and may help you to look differently to certain things.

Screwdriver

Compare it with this everyday life example: if you’ve ever used a screwdriver, you’re familiar with cross headed screws. At first sight, all cross headed screws look the same and it seems that all those screws can be handled with just one screwdriver. From time to time it happens that you struggle a bit to tighten or loosen a screw but most of the time with just your one screwdriver you get the job done.

Then, one day at the tool shop, snooping around all those fancy screwdrivers you learn a new truth: it seems that not all cross headed screws are the same at all. First, you discover that the screwdriver you currently have is a Philips one (PH), secondly, you decide to buy its twin brother the Pozidriv (PZ) screwdriver. All of a sudden you see which screwdriver fits best to a certain screw, although they look quite similar they are not interchangeable. If you were always wondering what PH and PZ meant on your screwdriver, now you know 😉. With this extra knowledge and an extra tool, next time you see a cross headed screw, you know you will do a better job. The exact same is true when knowing multiple programming languages.

There’s no price to pay

So no, I don’t see the price tag on learning an extra language. Will you equally excel in all? Probably not, but I don’t think that should be your goal. Will it teach you something extra about your main programming language? I’m pretty sure it will. Knowing a new language will reveal the differences between them. At their turn, those differences will make you wonder why something is done the other way and what the consequences of those choices are.

Let us conclude with a real-life example. The burden of a small CLI I used and which was written in python was on the installation and upgrade process. On every snowflakes machine, the installation had its own problems and with every new release, another pile of problems surfaced. 

If Go is part of your toolbox, you immediately see its advantage in the above scenario. Go allows compiling its artefacts to a self-contained binary. After compilation, you can rest assured, the binary will smoothly run on every machine you compiled it for. So that’s what I did, I ported the Python CLI to a Go version. With this new version wrapped in a different artefact type, we no longer have to worry about changing runtime environments or third party dependencies. It’s a perfect example of picking the right tool for the job. Being a polyglot developer is one way to get there.

Enjoy and until next time!

Subscribe to our newsletter

We'll keep you updated with more interesting articles from our team.

(about once a month)