“The only constant is Change.”
— Heraclitus

While it was doubtful that Heraclitus was addressing developers, the sentiment certainly still applies. As developers, we live in a world of constantly changing requirements, code bases, tools, and languages. Once we've found our work flow, it is easy to become resistant to change and to new concepts or tools. Facing a new language can seem daunting at first, but have no fear; adapting to a changing environment is not as bad as it seems, and expanding your toolbox with new languages and idioms will make you a better developer. As software professionals we simply need to keep a few things in mind when approaching these new situations.

Be Curious And Attentive

Genuine curiosity can and should be utilized when trying to learn something new. If you are faced with going from a language like ruby to a functional language like Clojure. It may be a good idea to read up on functional paradigms, the history of Lisp, or on Polish Syntax. Find what interests you and explore.

Sometimes the new language may even come with an existing codebase. Being attentive is imperative when approaching an existing code base. While it's easy to open an existing project and just scan through the files until you think it make sense, it requires digging deep into the code to really understand what is going on. Taking the time to read through the tests, looking at the code associated with what you want to write, and seeing that it's what you expected can save you from suprises later. The time it takes to feel acclimated to a new project depends on the size of the code base and on the developer.

Writing For The Language or Packing Wisely

When moving to a new language, its important to bring our patterns, principles, and the skills we have learned over the years with us, but we need to be mindful not to bring with us idioms and conventions that do not apply. Take for example a simple function that prints a report written in ruby.

def PrintReport(reportObjects)
		i = 0
		while (i < reportObjects.size) do
				Kernel.printf("Object #" + i.to_s + " ")
				Kernel.printf(reportObjects[i].data + "\n")
				i += 1
		end
end

Even though the above code is perfectly valid Ruby syntax, I think any Ruby developer would be sent through the roof if they came across this code while working. While bringing over what we know to a new language or environment is important, it's also important to adapt that to the style or common idioms of that language. For instance, in Ruby, it's normally frowned upon to use loops when you can leverage the Enumerable library to do that work for you. We could write that previous code in a more Ruby style like this:

def print_report(report_objs)
		report_objs.each_with_index do |object, index|
				puts "Object ##{index} #{object.data}"
		end
end

We can leave the debate on whether this is perfectly formatted and styled code for another day, but what we do have here is an example of code written in a style that is familiar to other Ruby designers in this code base. (While both examples are functional, most would agree that one version is more [refined/elegant/simple?)) We don't want to bring our baggage with us from our previous languages or environments. At the same time, that doesn't mean we need to abandon all that we know when we move on to something new.

On Getting Stuck

There will be plenty of times when you'll find yourself stuck; this is simply part of the daily life of a developer. But getting stuck can be especially frustrating when the syntax or libraries you're working in seem foreign to you. In these times, don't fret, and make sure not to stare into the abyss (lest the abyss stare back into you). Write another test — you may be stuck because your test was taking too big of a step and you needed a smaller one to drive you to your next step. Go back and read through more of the codebase and see how others approached similar situations.

With every new project, language, or codebase we bring with us our SOLID principles, TDD, and the patterns and principles that we have crafted over our career. Making the jump to becoming a polyglot developer may seem difficult at first, but each additional language is easier than the last, and you'll look back at all you've learned and be ready for more.