Full circle: rediscovering my joy in software engineering

This is a different kind of post than I normally write here. Most other posts are about a problem I ran into or a conference I visited. This time is more a story telling post. I though it would be nice to have a sort of summary of what kind of work I have been doing for the last decade.

For years I’ve have had a page about me which tells a bit of my background and past and present jobs. In this post I would like to zoom in on, roughly, the last thirteen years and write a bit about how my work and interests evolved.

Software developer

Let’s start with my job at Fox-IT, the company I joined as a Django/Python developer mid 2013. I started building a portal for the customers of their managed SOC service and I figured that—once this portal was done—I would find something else within Fox to work on. However, this project only grew in functionality and even became the tool used by the SOC analysts to get alerted on new incidents and start their analysis in. I think all in all I spent the first four to five years at Fox working on this platform on a daily basis.

Meanwile, due to organisational changes, my team was supposed to become less dependant on a different business unit and as a ressult we would need to manage our own infrastructure more. I’ve always been interested in that kind of work, so I started picking that up. And due to my background as a developer I wanted to automate as much as possible. As a result my days started to become more an more about creating and maintaining a testing environment. (I also have to admit that messing around with physical servers was fun, especially initially.)

Infrastructure developer

Slowly my work had become more about the infrastructure surrounding the product we were developing, than writing code for the product itself. In hindsight I think it was about 2018 when I was effectively no longer a developer on the product. Instead of implementing features I was using Packer to create template for machine images, writing Terraform to use these images (and managing other infrastructure) and using Ansible to help deploy the product, et cetera.

Did I overengineer it? Probably. Did I like it and have I learned a lot from it? Definitely!

Because I dislike the term “DevOps engineer”, I decided to call myself an “infrastructure developer”. (Though I have to admit that on my CV and social media profiles I used the title DevOps engineer when I was applying for a new job since—whether I liked it or not—that is a more familiar term.) Looking back to this now, there was also a clue hidden in there, but I’ll get back to that.

Since I was the only person doing this kind of work for my team, the organisation figured it would be good to pair up with a colleague who was doing similar kind of work for a different team to have some redundancy. While in practice this did not work that well (yes, we had a similar role, but the platforms and infrastructure were too diverse), it did lead to a new opportunity.

A different team needed an extra person to help create a self-service, on-demand environment to perform digital forensic investigations in. And given my interest in cloud infrastructure (AWS) and my experience, I was a nice fit. I really liked that project, learned a lot and enjoyed myself. And I wanted to do more of this kind of work. However, this meant I had to look elsewhere.

Mission Critical Engineer

And that is how I ended up at Schuberg Philis as a mission critical engineer. As I had expected, this role is heavily operations focussed. In my case, I helped to plan, build and run AWS infrastructure for one of our customers. Unfortunately it was mostly “run” though. Don’t get me wrong, I definitely leveled up my AWS skills and genuinely enjoyed my time in that team. But…

At a certain point in time our customer wanted to add an existing application to their mission critical environment. Since it was a Python application (a Lambda actually) I volunteered to help improve the application so it would be in a state where we felt comfortable to offer 100% uptime and 24/7 support. Only then did I realise what I was missing: software development and the joy that it gave me.

Sure, I had been doing operations related work in the past, but in hindsight most of the time I was still developing. Not building an application perhaps, but infrastructure. I had always been more of a developer than an administrator. I guess that was also why I liked the title “infrastructure developer”.

Lucky for me I was able to switch to a different team.

Mission Critical Software Engineer

And that’s how I ended up where I am today. Little over a year ago I switched to a role where I can focus on writing software again. And we, as a group of software engineers, are also responsible for running, monitoring and supporting our own services. So thinking about infrastructure is still a (small) part of the job.¹ But the main chunk of work is software engineering.

One thing did change though. Where my previous development jobs had been Python oriented, in this team we use Go to write our services. This was part of my plan: by joining a Go team, I could broaden my horizon by learning a new language.

Go was not completely new to me. I had done a Go workshop in 2018. And I had also made an attempt to rewrite an internal Python command line application in Go. However, I had not properly learned the language, let alone work with it as part of my job.

I might write more about learning and working with Go in a future post, but that is beyond the scope of this one. I do want to say I thouroughly enjoy being a software engineer again and learning how to do things in a differeny language.