Are you a Polyglot Technologist?
As software engineers and architects, we solve problems. We don’t just write code. The problems we solve are to improve the product that we offer our users. Effective system architecture is finding the right balance between those users’ objectives for the system, the technology applied to deliver the solution and the people building and operating the system. The necessary design decisions require a detachment from the technology we use. To that end we are less blinkered about our technology choices and must focus on the right approach to deliver the most compelling systems.
It is always interesting to hear general debates on technology or programming language choice flowing through wider communities, both here within Skyscanner and beyond in the industry as a whole. Some engineers are nervous and raise questions as to what it may mean to them as specialists as our technology continues to evolve. In my experience, this conversation happens many times over any given period, something we experience several times over our careers. Generally it is healthy.
This debate, though, is sometimes, if not often, seen as a competition between cool and uncool, modern versus old. The premise of that argument is wrong. The discussion shouldn't be wasted on the technology or specific language of choice — these are simply the tools we use in the application of our solutions. As an engineer the discussion should primarily be about the fundamental engineering skills with the technology/language/framework relegated to a secondary consideration. In fact, most of us have been polyglot technologists for longer than we can remember, we simply don’t think about it in that way. We do all kinds of things with C#, Python or Java, with Rabbit MQ, MSMQ, Kafka or Couchbase, with SQL Server or MySQL, with Selenium, load balancing or CDN configurations. The list of the wide range of technologies we are exposed to and master is not simply one specific technology or language. We need to recognise that this takes a certain collection of skills. It means we are already polyglot technologists. We need to recognise it and use it to our advantage to effectively enable the delivery of our solutions.
From Monoglot to Polyglot
Prior to many years of focus on .Net technologies and C# particularly, I was a Java developer — doing part time support for a small application that was not doing an awful lot for anybody. I found a start-up web development company who was moving forwards with .Net 1.1 technology stack and had built a SaaS CMS on it. They were partnering with another start-up, a hotel gift voucher company, to build a SaaS e-commerce application for them and their hotel clients. Sharing the costs, the two companies were looking for a ‘cheap’ graduate in order to progress the development of that application. The opportunity the role brought about — the chance to have real influence as an early employee in not one, but two internet and web focussed start-ups — was exciting (and, many years later, that same decision process led me to joining Skyscanner). The Microsoft stack was the technical direction of that company. I had a few months of limited professional Java experience, so at the time the decision to re-train into .Net was a relatively easy one. I was also a recent graduate and had that graduate’s bulletproof belief in my unbeknown, complete lack of abilities, such that I didn’t get the new language fear you sometimes expect.
I bought a book (it was 10 years ago!) to get up to speed with the basics of ASP.Net before the interview process. I remember the interview exercise I had to do — a small application with contact address book of suppliers and some sales. I built it in Java with a Spring based UI. It was simple enough and while I did consider trying it in C# & ASP.net, I didn’t want to risk it. Luckily it was good enough. While training was laid on — videos, exercises, books etc. — I hit the application code to see if I could start to make sense of what was there and didn’t really look at the support materials again. The switch to C# from Java turned out to be a few minor syntax differences. I hadn’t intended to do anything serious but in that first week I found myself doing a bunch of small bug fixes. These went to production manually inside the first month and things snowballed from there. In that first month, I learned one of the most important software engineering and internet economy lessons that I try to apply every day:
This Internet Economy moves so fast, it’s impossible to keep up to date on everything. You are doing very well if you just keep moving forward. And it is forward motion that will lead to making a significant impact.
It is these fundamental skills and the ability to keep moving them forward that I believe is at the core of any good software engineer. Good software creation follows tried and tested paradigms openly but not blindly. Object-orientation or functional programming, tiered architectures, SOLID principles, baked in quality, simple use of design patterns and more recent approaches like Continuous Delivery — these fundamentals have been around a long time. You can find them referenced in the seminal software engineering books such as Code Compete, Clean Code and The Pragmatic Programmer and none are technology specific. New patterns appear over time, but those that cross over the technology boundaries are the key foundations on which to base our decisions not the technology stack. Understanding how they are the key transferable skills between languages should give you the confidence to at least consider the step beyond your current platform of speciality.
While having the fundamentals skills is the first key to effective polyglot-ism, having the right working environment is also key. Working in an environment with multiple technologies allows you to constantly try something new. It gives you the freedom to leverage those skills and learn something you didn’t know yesterday. A software company that is so focussed on Ruby on Rails and nothing else is blinkered and always provides a rails-oriented solution. The team never gets the chance to exploit the alternative options despite the degree of chance that there is something more suited. Having a mind-set that supports adoption of the right tool for the right job — irrespective of underlying technology — enables better design and better solutions. The environment to make that choice has to exist. It can’t and should not be a free for all — for reasons of ongoing support, maintenance and accidental costs — but a freedom to experiment should be the norm.
The language itself is always a secondary consideration. If you get the foundations right, you should have every confidence in your ability to pick up any new language or technology, understand its core principles and move on with it. Often at times it may be a different paradigm or a new approach (functional or parallelism paradigms) but at its core the fundamentals stand us in good stead for whatever is next. If as engineers we get this at the fundamental level, we can have the right approach to problem solving without constraints.
I am still most familiar with the .Net technology stack, the result of a decade of the environment and the language and seeing it change over time. It can become habitual. I am lucky enough that today there is a growing variety of choices I can make. I am more likely to try out a new technology or language; most recently GO, while Objective-C is next on my list.
I have always been a polyglot technologist. Haven’t you?
* I can hear the scoffs at seeing HTML in this. Creating clean semantic HTML underpins web applications both for its usability when combined with high quality CSS and JS but also the art of Accessiblity, SEO and performance. It takes more than a little bit of craftsmanship too. If you would build a definition list with a bunch of <div> tags — then perhaps you should consider it further?