I’ve been analysing a bit the current landscape when it comes to technology, areas where several things may fit and whatnot. Things have changed a lot and are still moving around quite quickly.
How were things a few years ago when I’ve started working (let’s say, give or take, around 15 years ago)? Quite easy:
|
|
There was this habit of staying with only one language. (or at least in my bubble) Always up-to-date with your niche; always should know it’s quirks; always should know how to get past the compiler’s warnings. So, whenever you were starting with game development in C, that was to be your area - people weren’t experimenting too much and still didn’t have the need to do so. Software development was following back then some closed principles as everything was siloed and complex solutions as we know them today weren’t part of any business plan due to several factors. (even internet’s spread was one of them, alongside other factors)
So, where did things change? Simple, we started having (cool?) options, we started gaining more and more usage for our projects, we started needing better performance on each aspect of a sort-of-called product. Why? Because competitors will do so, therefore their product will run smoother and will get more clients. As the products’ landscape widen up, this cannot be said about (good) programmers - nope, they haven’t multiplied. Even worse, the IT world is now dominated by artifficial numbers as a big pile of us have no trigger nor passion on this field. Still, demand was and it still is here. And whoever is living under these roofs will have to adapt as well - being forced to do so or just by choosing it themselves.
Polyglot programming - the practice of writing code in multiple languages to capture additional functionality and efficiency not available in a single language.
Where to now? Well, it’s pretty common to jump into n languages in order to get your hands dirty. But does it make any sense? Well, it still depends on your “silo”. As I’ve been coding web services and mobile apps mostly, at least in this area there are countless options - programming languages, protocols to use, frameworks built around these bytes of technology and so on.
How to choose your way around it? Simple - look over your objectives you need to meet. Is it delivery speed of the project you’re looking for? Great, then test your scenario and see if it makes sense to deploy a stable yet slow-and-uncool solution for phase 1. Maybe you’ll never need more in the end. Time to market is a great advantage. Also, another point would be to evaluate the amount of fun you get in order to choose X tech / language / framework (and usually this applies for hobby projects which are by definition supposed to be fun). Even though, current times and the amount of emerging technology seem to encourage lots of diversity when having such thoughts - you can accomplish the same thing using different tools, the idea is to have a clear mindmap and to know your objectives. Languages usually are just tools, the end result is what makes the difference.
Fun facts with a project
A few years ago, I started working on a project - demand was increasing from our customers, but we still had to run the PHP monolith that was cranking from all places. At the end of the day, this resulted in probably losing millions in sales due to technical hiccups. Solution? Doing a full rewrite.
Yet again, we were running a PHP solution in a market dominated by PHP devs when it came to backend web development. Still, NodeJS already was mature enough to give it a spin. As described above, I ran a first prototype by rewriting a portion of the platform aka “decoupling the monolith”. The experiment went well, we gained trust from the upper level peers, so we were ready to do so with the other functionalities as well. But still, we were lacking manpower and the programmers market was very homogeneous. Solution? Simple, write some boilerplate framework on top of hapijs built around symfony (php framework) logic. Why? Because the others needed to feel like home. Step by step, the team became polyglot.
End result? Well, things didn’t stay like this. We’ve even added a few more languages to our bag: golang, rust and even lua. Performance hasn’t been from that point an issue anymore because we were able to iterate fast, measure each component and fix it before it became a pain to manage it.
Being way too performance-oriented
To be noted that the polyglot’s way may not prove always to be the right path. I’ve been working on an eventually failing project, being sort of the sole backend developer. The prototype, on paper at least, was looking great. Once the actual code writing phase began, things were also running smooth enough. But not as fast as they needed to which made the project to actually fail. The engineering mindset behind it was simple - it should be a bulletproof solution and each component should be able to scale to the moon and back. (yep, microservices, everything was automated etc) It didn’t matter if it was elixir, rust, golang nor nodejs - nope, it had to be blazing fast and fault tolerant. And eventually was, but it was too late from the business momentum’s perspective. Others were able to do it faster and already formed a market - we, on the other hand, have been too slow.
When and how to apply it?
Apply this mindset only when it makes sense. Give attention to other details because it’s the greater scheme of things that matters. Iterate fast and fix things faster. Big direction shifts always need to be understood beforehand.
The “use the right tool” mindset makes me smile - as it’s been widely built around microservices adoption. The problem of applying it is really understanding what you’re actually doing - always, having a solid foundation will help anyone swimming in all kind of waters. The same applies for programming languages. Still, keeping yourself focused on only one language may lead to a dead end - but there are also exceptions, such as fortran / cobol, right? Adaptability and flexibility on the other hand are a complete different subject - they’ll help developing a more deeper understanding. And I may add that they’ll keep anyone on-board as things won’t become boring enough to consider a drastic career change.
Complexity has it’s trade-offs.