I’ve had to have a bit of a rethink of the word “polyglot” in my tenure so far at Mobility Labs. The word itself stems from the Greek words polu-, meaning “many”, and -glotta, meaning “tongue”.  In linguistic terms, it refers to someone that is fluent in more than one spoken language.  In my spare time, I am actively learning Japanese, Spanish, and French, but I am not fluent in any one of them; I can make out occasional conversational talk, but that’s about it.  In that vein, I would not consider myself to be a polyglot.

However, over the course of my career, I’ve picked up a multitude of programming languages:  C, Python, Java, Bash, Ruby, JavaScript, Clojure and RBDMS languages (MySQL, PostgreSQL, Thrift, and CQL) to name a few.  In that vein, I would very much consider myself to be a polyglot.

In my time at Mobility Labs, I have worked across seven different languages and six different frameworks in four projects.  However, switching between these languages (and even development paradigms) isn’t a difficult thing for me.  In fact, I quite enjoy it – it forces me to think about developing solutions in completely different ways.  Further, it helps me address problems that I couldn’t have expressed before, which is the most exciting part.

But how does the word “polyglot” apply to a software engineer in general?  Just as a traveler learns new languages to thrive in a foreign country, so must the software engineer be capable of translating between languages when working on a project, in order for both the project and the engineer to thrive. 

The way that modern languages have evolved and formed over the years is quite fascinating.  Many of the words that modern English speakers use have roots in Latin or French, and often times, English speakers are coming up with new phrases and new ways to express themselves – portmanteaus being a particular example.

It’s often interesting to go back to the roots of one’s mother tongue and really think about where it came from.  A while back, I was looking for a phrase that meant something similar to Caveat emptor, but applied to a person reading information.   Piecing together what Latin I knew, I figured out that a lectern is something that people in the medieval times used to place books on, and that lectere means “to read” (after looking up “lectern”, of course).  With a bit of help from Google Translator, having the base words in mind, I was able to conjugate and express, “Let the reader beware” by way of, “Caveat lector”.

Much of the same can be said of programming languages.  New languages often based their syntax in more broadly known language, such as Java did while basing itself on C syntax.  While there is a broader variety of languages now which don’t use all of the same conventions or structures that C once did – like Python; it explicitly forbids using curly braces for block statements – engineers are able to somewhat understand the differences between languages based on what they already know.

For most software engineers, working between languages is so commonplace that we often don’t realize that we’re making the context switch.  For a full-stack developer, they may be working in HTML, CSS and JavaScript for one task, Java/Ruby/Python/PHP/Clojure for another task, and MySQL/PostgreSQL/Cassandra for another task.  They may even have to move between all three layers for a single task.

The nuance of expression comes up when switching between different development paradigms, language subtleties, and the differences between frameworks.  Just as there is an often stark difference between Latin and Asiatic languages, there is a difference between a language that is object-oriented, one that is entirely procedural, and one that is entirely functional, and one must adapt their thinking accordingly.  Likewise with frameworks – while the number of frameworks across language ever grows larger, so do the assumptions, nuances, and “automagic”.  Having worked prior in a Java shop, seeing Rails create methods from the way I had named my routes put me off at first, but then I grew to enjoy it.

The one constant that hasn’t changed is the basic ways to express basic concepts.  This is analogous to spoken languages in that we should learn basic courtesies and requests in a foreign language.  As such, declarations of variables across these language may be different in syntax, but it is entirely possible to declare variables in their own vernacular.

The same goes for data constructs, such as lists and arrays, or looping constructs; each language has a different style of expression for it, but the concept is roughly the same.  It is in this that most developers moving across language find their anchor; they look for similar elements in a language and cling to them.  It may help them learn, but in the long run, my experience has been to broaden my horizon and see a more effective way of expressing a problem.

It means the difference between writing this (in Python):

def filter(li, x):
    i = 0
    while i < len(li):
        if li[i] != x:
            li.remove(x)
    return li

…and this much more “Pythonic” expression:

[i for i in li if li != x]

In this profession, I would strongly consider myself a polyglot.  I am able to understand a broad variety of languages, frameworks, and datastores, and I’m able to discern which would be more suited for the job.  As I grow in my career and skills, I’m certain that I will become fluent in even more languages, frameworks, and methodologies.