Become Adaptable As A Software Engineer

When I first started as a Software Engineer in the 90's (1990's to be clear - just in case this is still up in 2100), there were still many languages being developed in, but the major players were C/C++ with some Perl, Ada, Cobol and a few others.

Most systems were being written in C/C++ and running generally on Unix systems. So, that is what I learnt. I started working for companies creating software for Unix platforms written in C and later C++.

It was fun, interesting and you didn't need to be too adaptable. You may need to know some Unix script. How to create a makefile. Do a little Awk or Perl, In regards to language, life was quite simple.

Now, I'm not saying that there were not jobs in other languages. They were still out there - especially as the year 2000 approached and there was a lot of roles for Cobol developers. The reality then was, there were far less languages or subsets of languages out there that we could do work in.

Learning some Java

Moving into the 2000's I found myself working with a little Java. I worked on a project that had a Java front end, C server and Perl backend. The idea was, request were made in the Java UI, passed via a pipeline to the C server, then this would make some requests to Perl backend.

I'd done some Java back in the mid 90's while at Uni. So, I had some understanding. However, it had moved on during that time and the interface code had too.

This was my first real experience of being adaptable.

More languages to come

Later in the 2000's my worked moved into some C++ on Windows which also evolved into doing some work with C#. I was spending more time looking at code in different languages.

Learning to become adaptable, looking at the structure of the code rather than the syntax. Now, there are definitely some nuance in languages - they do things different. However, the way a program is structured remains the same (well, that is until we started to move into more Microservices).

As new languages evolved, subsets of languages and tools that did very specific parts of an application - we had to adapt. We started to become more full stack developers. Someone that would create an application using different levels of language. You may use Javascript for the UI. You may use something like C#, Java, Python or similar for more of the back office with SQL or a no-SQL data storage. We become more adaptable.

Today we need to be adaptable

Without giving too much history - we move to today. In the last 12 months I've worked on projects in C#, Javascript, Python and Java (with Sprint Boot). Some of these I did not have a great grasp on to begin with, but we adapt.

I now look at code as it is structured. Python aside, most languages structure very similar. So, you can follow along the code - with the minor most lookup on specific syntax your not sure of.

You can also create code in a similar manner. You create the idea, the structure (I still love UML). You then create the skeleton. Finally, you start to fill the methods to do what each is needed.

Creating a well structured skeleton will allow you to keep methods to small segments of code doing very specific things.

We also need to adapt to new design models. Today we see more Microservice models used - which in my humble opinion is really the next evolution from having objects in your code.

Small, self-contained services that do just specific things. They maintain their own data (usually in a DB) and don't really care about what is using them. They simply give an interface (usually API) link and just manage the input and output.

It's quite probable that in 5 or 10 years time a new model will be in use. New languages. New tools and techniques. What won't be new is that we will need to be adaptable - being able to switch from 1 platform to the next, 1 language to another.

Being a Software Engineer in today's technology world is becoming more interesting every day. The more you can move from one stack to the next will be your strength. Flex it and train it...