A commitment to polyglot programming was an intentional decision I made early in my career as a developer.
(so, earlier than now…).
What did this (naively) mean at the time?
I’m going to know all the languages, so when a problem arises that needs solving, I’ll solve it with the most perfect (obscure) technology choice. Achieving a solution with the clearest and correctest code base.
During my last round of job interviews, I can hear myself speaking like this. I can just hear “the right tool for the job” rolling off my tongue.
Maybe it’s just me, but this seems like pervasive wisdom propagating through our industry right now, especially to new comers in the field. That it’s important to know a lot of languages and technologies so that you can use the best of all the things, to solve problems perfectly.
Sometimes this mantra can easily reek of our generations fear of commitment. Jumping from language to language, framework to framework.
I wrote a rails app, therefore I know rails.
I wrote a thing in node, therefore I know node.
I wrote a python script, therefore I know python.
This sort of aggressive polyglot programming is like a boy scout in search of merit badges. A classic jack of all trades, and a master of none.
The little bit of experience I’ve gained has shown me that while it’s good to be comfortable learning new things, it’s far more valuable to gain mastery in a few things. To spend a significant amount of time with a single technology, or family of technologies. Learn the quirks and demystify the magic. To not be satisfied by breadth, but to seek out depth.
“The right tool for the job”
I’ve also learned that “the right tool for the job” seldom exists, and when it does it slaps you so hard in the face you cannot ignore its existence.
The truth (and beauty) of our field is that you can solve the same problem 10 different ways.
Within any successful organization there is a core technology focus, and it’s highly likely that 1 of the 10 possible solutions involves a technology everyone on the team is familiar with. As much as “the right tool for the job” is a unicorn, as is a master of all trades, let alone a team of them.
What happens when you (are allowed to) choose a technology that you know (dabbled in), and the perfect solution starts breaking?
You go find the resident expert on … oh wait… you are the resident expert.
There are many places in life where the theoretical world and the real world clash so harshly. This is one of those places. This is one of those fields.
This resounds so clearly in the talk I posted recently about Scaling Pintrest. In which the overarching lesson learned is that a simplified, familiar, mature architecture will likely be more resilient and maintainable, than one that contains a grab bag of the latest and greatest (immature and unfamiliar) solutions.
So be ignorant of other technologies?
Having said all this I still believe
in polyglot programming that polyglot programming is useful in its place.
Running with weekend projects in foreign languages teaches you a lot. Not just about the technology in use, but it breaks you out of the logical
rut path your everyday technology ingrains in you. You will begin to use your everyday technologies in ways you hadn’t yet thought of.
Gain exposure to general programming idioms and patterns that you wouldn’t otherwise be exposed to. Learn new ways to solve problems with your everyday language by learning the idioms of others.
Enjoy the new, but remember to respect mastery, familiarity, and maturity.