John Ahlroos

I am now closing in on my 40th birthday and for half of my existence I have now worked professionally as a Software Engineer. When I think about that it kind of feels incredible and I wonder where all the time has gone.

Getting started

When I started out in school I never thought programming would be something I would be doing for a living. Back then, schools did not even teach that much programming, so most of what I did I learned from Linux magazines I bought from the local kiosk.

The first official course of programming I did was in high school where we had a proper programming course in Python. There really was no Udemy courses or other free internet courses you could take, so the learning you had to do was from real books. gasp

When I started the problems technology was solving was so different than today. The internet was a young playground for idealists like myself to try different things on. The internet was not yet driven by big money companies only looking to cash out on users, and user data was not yet a commodity to be harvested.

The first job I had was writing software for a company that used COBOL as its main language. The job actually was implementing small snippets of code that was entered into a framework that then took that code and made data transformations to a pipeline. Not very glorious, and the office environment was the typical cubicle.

Open Source

Later on I joined a company who used its own web framework for building business applications for clients. It was the first time I worked for external clients as a consultant and I remember thinking back then that I will never be able to meet those deadlines and produce that code. But I eventually got the hang of it and learned.

The company later open sourced the framework and I was lunged into the open source world where opinions are strong and expectations are high by the other developers. I stayed at that company for 8 years, and I probably overstayed my welcome. But I liked the coding challenges from which I learned a lot and working with the community allowed me to meet many interesting people along the way.

But after working in open source for 10 years I decided I wanted a change, and decided to have a look at Fintech.

In Open Source development the emphasis usually was on inventing new and novel ways of making software. It was mostly marketing when you think about it, yes you're writing code, but there are a lot of community involvement required and if you are good on camera it also helps.

Fintechs

Fintech is mostly the opposite.

In most Fintechs there will be NDA's preventing you from contributing and discussing freely your solutions. Also when you are working on systems that manage other people's money there is also a lot of regulation that need to be followed to keep peace with the regulators. And if the company is international, well, there is even more regulation.

Usually when you join a Fintech company your goal will be to take a piece of code that will be using some ancient ways of implementing things and turn it into something a bit modern while at the same time trying to solve business problems where the stakeholders could not care less of what code you write. Oh, and the original authors of the code you work on are long gone and they most likely did not care about leaving any documentation or code comments.

When it comes to development work most people will think about Fintechs as the last paragraphs I wrote and wonder why on earth one would go from Open Source using the latest technology to a Fintech deprecated mess?

But here-in lies the challenge. From what I have seen only senior developers with lot of experience will thrive in a Fintech, especially in a start-up like scenario where you will have little mentoring. Young developers usually either burn out or voluntarily leave after a a few months. And this is why Fintechs get their bad reps from usually.

I've found that if you are going to survive in Fintech you will need to grow a pretty thick skin. That usually comes from years of getting sht* from customers and managers. If you are a senior reading this, you probably get this. There are a lot of managers that will eat you up unless you are able to stand your ground. You will have to be able to dive into code-bases that are bad and come out understanding and refactoring it. You will have to manage outrageous expectations on outcomes and schedules. And you will have to be able to manage YOUR time furiously unless you want to burn out your first year. This is why I don't suggest Fintechs for developers who only started.

But for senior developers, Fintechs are great playgrounds. The usually pay well (tip: Don´t join a fintech that does not pay well) and unless they are very big there will be an amplitude of things to learn from and improve. Be advised though, if you decide to join a bigger fintech there will be a lot of red tape from non-developers. As a fintechs grow them seem to entangle themselves more and more. If you are looking for a good experience look for small to medium size business with a senior development team.

The cloud

One of the major break-troughs that has occurred over the years has been “The cloud”. With this I am obviously referring to Infrastructure-as-a-Service, akin to AWS.

When I started it was common to have your own server rack, and on the servers you had virtual machines running on the server. In the virtual machines you then had application servers where you deployed your application on. These days however it doesn't normally work like that anymore, except for in older enterprises (I'll ignore their existence for this post, as they are a category of their own).

The way applications are packaged these days are using Docker or Docker like abstractions like AMIs on AWS. The application developer rarely cares anymore about the OS of the server and mostly focuses on the application architecture and packages it into an Image. The image is then provided to a cloud hosting platform where you have virtually set up your server configuration. Some cloud platforms even take it further and allow developers to just upload code and run it without even caring about the environment (FAAS).

Dependencies and source control

In the Java space where I have worked most of my career there has also been a lot of changes. One of the most ground-breaking ones were the invention of dependency management and source control.

You see, before you had dependency managers, you built your libraries by hand and deployed then manually to the server. The only place you had these files was on the production server and usually there was no reference on when the library was built, by who, or even what it contained. So when something broke and it was a library, it was usually a big mess.

Later along came dependency repositories where library makers could upload their libraries and version them. This meant that you no longer needed to built them yourself and you knew what the library contained. If something broke, you could just upgrade to a newer version.

Kind of the same evolution happened to source control. When I started source control was a set of files on a server where you connected through FTP and uploaded and downloaded files as you developed. Similar source control systems where you could branch your code came a bit later like CVS or Subversion. They all were though centralized, and what we call branching today was highly frowned upon. Git obviously came and changed everything.

Ways of working

This is maybe one of the controversial changes that has happened in my career when it comes to non-code related things and I still cannot determine if it was a good or bad thing.

What I mean with this is obviously the Agile movement and working methods like Scrum and Kanban. I could write a lot of negative things these have brought, and why most of it was not intended by the authors but glued on top by business people trying to gain more foothold in the process then ever was intended.

But, I'll digress in saying than unless everyone at the company buys into these processes you will do more harm in implementing them than you will be getting out of them. I have been in a few transitions to know, and nothing good has ever came out of those.

In my view the best way to still develop something is just plain old working together as a team, using a board to put up todo's and respecting and trusting the team YOU have selected to accomplish it.

The teams that have encompassed this mentality has always accomplished their goals successfully. The key has always been to select your team mates wisely. And to clarify, in this context “Wisely” doesn't mean selecting only your pals and like-minded people but selecting people that brings diversity on a positive level to the team.

Going forward

It looks like going forward I will go on being a Software Engineer. Nothing I've seen around me has convinced me otherwise. Will I continue in Fintech, I honestly don't have a clue.

They say that after 40 opportunities for engineers decrease but we shall see, while I think that is true for very shallow minded societies like the US, I believe there is a waking occurring that we older developers still have something to give. The key and advice I will give is to just stay on top of new and upcoming technologies and apply your experiences to these. In most cases you will always be a 10x engineer if you can do this.

But as we know life can give you a left hook and kick in the stomach and you can find yourself jobless and even homeless. So always prepare for that. So what I these days do is what the Stoics recommend, manage the things I can influence and for the rest, well let it sort it out by itself.