Journey as a Programmer

I have been a programmer in some shape or form since 2008. Below is my journey and what I learned since then.

First ever job (that paid 💰)

I started with Microsoft .NET world in banking industry, learned a lot about C# and C++ at that time. You’d use (and probably still use) C++ for speed and everything else C# in that world. I learned a bit about LINQ at that time (first seeds of functional programming, even though I didn’t know). Object Oriented Programming is the main paradigm and I didn’t question the validity and necessity of that paradigm. I left the company because there was literally no engineering best practices that enforced correct and safe code and product and I was beginning to burn out and even become disillusioned with the profession.

China days 🇨🇳

Then I moved to Telecoms industry with Huawei. I still did C++ but our Chinese colleagues almost forbade us to do anything meaningful while I was there. At least I visited China for three months and learned a great deal of (even though waterfall) engineering practices during my tenure. I had to leave there for mandatory military service. And I finally left the world of Bill Gates at the end of 2010.

Car park or Parking lot?

I came back at mid 2011 from military service and dived straight into the Linux world with Java and Javascript for a software consulting firm. I learned a great deal about Linux and also became a personal Mac user in the meantime. Unfortunately the project we participated became bogus because of partners in Spain and company started to have cash flow problems. I too had similar financial problems and had to leave this company (called Parkyeri, Turkish word for “Car Park”) for Pozitron, my final employment in Turkey.

Pozitron ⚛️

Pozitron was the most important school for me after university honestly. I continued to improve my knowledge of Java and open source. I got the chance to work on various important projects there (BKM Express - Turkish version of Paypal at that time) and became a team leader after a while. We introduced practices like Unit Testing, Code Reviews, Linting, online course attendance, knowledge sharing presentations and even a Friday tech newsletter for the whole of engineering organisation. In Pozitron I was introduced to Scala and Functional Programming and it blew my mind. I became a FP enthusiast with Scala and started to look for more chances to program in that language. Since it was an amazing company, Pozitron used to send its engineers to conferences abroad. I have been to London for these types of conferences twice, attending QCON both times and finally decided to move abroad (at least for a while) to improve my skills because of these travels (and I fell in love with London too).

TripAdvisor/Dublin 🇮🇪

When I and my then girlfriend now wife made the decision to move abroad, I started to interview companies and finally ended up with TripAdvisor as a DevOps engineer due to some mistake in the interview organisation (and honestly I have to blame myself too). It took a while to convince me to become a DevOps engineer, but alas I moved to Dublin in September 2015. Thankfully, I managed to do a lot of programming in that job as well, mainly writing Python and Bash scripts to further automate the infrastructure and build processes of TripAdvisor. After trying out the DevOps craze for a year I decided I’d rather write functional Scala and left TripAdvisor for London UK. I was pretty amazed by the fact that in 2015 TripAdvisor was still running its own datacenter and they had physical server blades stacked in cooled racks and everything. I am sad that they had to let go a lot of their engineering team during the start of pandemic and I wonder if they are still using data centers by 2022?

To the UK 🇬🇧

StepStone/Jobsite was my first employer in the UK. I was part of a team that was converting NodeJS data pipelines (crazy) running in EC2 servers in AWS. We replaced them Scala/Spark applications that run in Elastic Hadoop containers (EMR) in AWS. The drop in application durations were drastic, from 20~ hours to 30~ minutes, and the gains were spectacular. During this employment I decided to learn about web development with React. The team started to fall apart after a while with some critical parts of the pipeline couldn’t be converted in time, I decided to join a startup called Quantemplate.

Insurance tech

Quantemplate defined itself as insure-tech platform that enabled its users to upload, clean, map, transform and analyse insurance data. They had a formidable backend of Akka clusters with the main web application written in a custom framework in Coffeescript. I learned a lot about Scala, functional programming and web development in this employment. But most importantly I learned that functional purity cannot save you from bad communication, confused organisation, wrong business choices, stale leadership, low developer happiness and inefficient processes. In this employment I started to recognise that static typing languages have their own kind of engineers while dynamic typed languages are used via engineers with a different type of mindset, namely pragmatism.

Dynamic pragmatism 🌐

This led to me to learn Clojure and my employment in Uswitch (now named as RVU in the UK). I started to work for one of the backend service teams and improved my understanding of microservices architecture, dynamic typed languages, Clojure (which might be the best programming language in the world, albeit with some disadvantages) and surprisingly React and Javascript. The more I learn Clojure, the more I started to appreciate the pragmatism of Javascript and started to like web development more. After a while I moved to the engineering team of money.co.uk which is a different brand in the RVU, focusing mostly on a main CMS based React application alongside with a NodeJS api using Typescript.

What I really learned

I learned some tricks along the way, and I’m always in the beginner’s mindset to figure this whole mess out. I can share some of the tidbits I kind of think might be helpful to some other people.

First things first, software is hard! 💣

As is the case with anything worthwhile to pursue, software development is hard! It looks incredibly easy to start, but scaling a working application that’s beneficial to human beings and organisations is a tough problem. Unfortunately there are no silver bullets but rather sets of principles and tools that we can live by, which can help ease the burden if ever so slightly. Accepting this fact will make things easier for the software engineer in the long run (hopefully).

Pragmatism trumps dogma 📔

As engineers, we should always strive to deliver the correct solution for the given problem and environment. If you are coding for a passenger jet sofware, you should use all the safety tools in your disposal. Type safety, linters, enormous amounts of testing (especially testing) to say the least. But for example, if you are working on a web application, you should be using some easy to use tools to quickly iterate on ideas. Blindly following a set of rules does not help anyone on the long run (hell, even on the mid run). There’s always pros and cons and we should be mindful of this fact.

You can’t beat testing 🧪

There’s no getting around testing unless you are writing POC or a very small cronjob etc. Even with the strictest compiler, you will always confuse yourself at one point and destroy at least some bits of your application. Please write tests and to write testable code, and please use functions and functional programming (even just writing pure functions mostly would help tremendously) (because it makes it much much easier to test!).

Our (not) Ancient Profession 💾

Unlike civil engineering, teaching, architecture, baking, farming and countless others I can’t recite, computer engineering is still at its infancy. Its current theoretical roots are younger than hundred years as of 2022. Even though (especially in the last decade or so) we have some of the best minds in the world in our field, we learn by mistakes and trial and error (and those best minds are focused on selling more ad views and curating fake news on news feeds). Unfortunately that means we are yet to find solutions to most of our problems. But this is fine, we just have to be patient and have an open mind and we will slowly get our profession collectively to a mature point over decades or maybe even centuries.

Static vs Dynamic typing ⌨️

I’ve been on the both sides (mostly on the static type side) of the fence on this issue over my career. I have come to realise one thing: there’s no clear winner. Static types gives you a bit more peace of mind but it’s more or less meaningless if you are writing a program that talks to anything over the Internet ( you don’t know what you will receive hence you can’t prepare your types for that )(ah yes you can but then everything will be nullable or option or whatever type that supports that). Dynamic typed languages are very fast to prototype in ( best choice in coding interviews, because you have to write less code and think about objects/maps instead) but you can get beaten by your own limited brain capacity (ie changing argument/field types, names, order) unless you have sufficient tests . So, there are advantages and disadvantages to both sides and as an engineer we should always be mindful of the trade offs when picking a language, which leads me to my next principle.

Know your trade offs 🤔

One could argue that software engineering is the art of being aware of the trade offs and the risks these trade offs pose for your current project/environment/business. As you can already gather from the previous ideas, there’s no silver bullet to programming and every decision you make will have advantages and consequences. Just don’t forget about the consequences! (There are various techniques to document these so we and the team can remember them later on, like ADRs )

Choose boring tech 🤯

After the above paragraph, you now know about decisions and consequences. So on your next project, you have to pick say, the frontend framework to build your web application. What are you going to pick? The next shiny framework, or the old and boring one? Yeah, younger engineers in the team would like to try their hands on the new framework, but do you know what that tech can cost you in the long run? Can you support its maintenance? Are there going to be patches to its bugs and security holes? Are you going to find community support when you need it the most and the quickest? These are important tasks and they will suck the energy out of your team in the medium to long term. But instead, you can probably go with a known and boring technology like React (even React has its new gotchas coming up every day thanks to Google and its core web vitals approach changes). You can find support, engineers and common knowledge for React easily. So what do you do? You pick the boring technology. (This is by no means my original idea, but from this brilliant person and his essay about the consequences of technology selection here, but I can say that it easily became one of my core principles in programming and engineering)

Verdict

Even though I am not the young and chirpy engineer anymore, searching for the holy grail of software engineering, I’ve come to accept that what we do is hard and we should be careful and calculating about technology and decisions around it. I still am fascinated by the power automation and would like to work towards welfare of others through software engineering. Computers are amazing and I like working on them for another 25 years hopefully!