What is my job as a software engineer?

2021-11-01T00:00:00Z

A while back at a party someone asked me the usual question: "what do you do for a living?". In a bit of an automated manner I said that I was a software engineer for TomTom, the location company and that I was working on doing maps for autonomous vehicle.

I could see the usual spark in the topic, I make cars drives themselves! What an incredible thing to be part of.

As much as it is true I was bothered by how unrealistic that description of my work was. There are thousands of people making cars drives themselves around the globe! So what do I actually do? what is my actual day-to-day work?

1 · Thinking the complexity and make it reproducible

We then started a deeper discussion about our respective jobs, it turns out he also was a software engineer working into making a test framework for payment devices.

So let's finally answer that question. What we came up with as a job description is:

We think the complexity of a task from one end to the other, looking at all possible states, all transitions, all constraints and every needed operations.

Once we have a clear vision of the operations' maze that is needed in our mind we encode that within a machine to make it endlessly reproducible (given there is no Zombie apocalypse of course).

Okay, that's a convoluted way of explaining our work. There is a lot in here, let's unfold a bit.

First it means that whenever we interact with any computer in any way, the logic to do whatever the computer is doing (rendering this blog for example), was once spread among multiple of humans thoughts.

Second, we as developers holds a lot of complexity at any given time in our brain. We are retaining as much as possible the maze that is our code, from the format of the data to the error handling channel.

Third, I am not producing a map ever, the computer is, I am thinking on how to produce it with my coworkers in order for the machine to do the job.

2 · The color change

So, why am I writing about that besides being able to have an unconventional answer when asked what I do for a living?

Have you ever heard about that none technical person who casually asks to change the website color entirely?

Well, we as developers we have! Let me tell you what happen at that moment in our brain, we start to skim through the code in our head. We load the whole context of where and how those colors are defined, rendered, if there is any variations of those colors, if changing them might mean changing other colors to adapt the style, where are those other colors encoded and ingested by the system?

While we are loading such huge information context in our head to assess the query someone is looking at us expecting a quick answer (and often thinking that changing a color is easy).

3 · Know yourself and others

So what can we draw out of those observations?

As developers our job is to pre-think complexity and make it behave the same way for eternity.

That is a heavy task on an everyday job! Every morning loading thousands of already encoded cases, then thinking the next one, then transcribing it in the machine!

This post is not a complaint, I absolutely love my work, but I think it matters that the rest of the world understand our job from that perspective. Disturbing us during work is the same as blowing on a house card. Asking for a simple question is the same as asking for us to load half of the system in our brain to see where your question would fit.

Having more people aware of the cognitive load of our job makes working as a team easier. The same goes of course for every other job around software, the more we deeply understand others work the better we handle our interactions at work.

So next time someone asks you what you do for a living, think twice and ask yourself, what do you mentally and physically do exactly?

DevOps: Accelerate software not human

2021-11-01T00:00:00Z

1 · Coding is easy, building complex software is hard.

Coding your first line, learning your first program and starting to get result takes few weeks to some month, how exciting! In that regard, coding is easy to learn. Welcome to the beautiful world of developers.

After getting started with your new position you will start to hear questions regarding your code like:

How to interoperate pieces of software? When and how to design API? How will my code look like at runtime? How to tool my piece of code to be observable? How to enable end to end tracing? How to document both features and codes for everybody involved to be able to participate? How to react to failure or shortage of services? How to store the data, in which format, for which kind of queries? How to display it to none technical user? How to make a feature available in a nice manner to users?

Feeling overwhelmed? those are just few examples of all the questions that revolve around a bunch of line of code which will live for years somewhere within a data center.

Feeling overwhelmed by them is totally okay. Coding is easy, engineering and building complex software across a group of people and to the world is hard.

2 · DevOps culture and automation to the rescue right?

One of the principle of devops is having small changes. Such changes allow us to answer those question one by one against a context we, as human, can grasp.

This way we won't tool once our entire codebase but do it slowly for every bit of software we release out in the world.

Another cool thing about small changes are the fact that it is easier to manage for the whole development chain, bye bye long night deploying thousands of new line of codes and dozens of features. Now that you have small chunks of changes you can deploy in less than a minute. On top of that you can safely automate it!

Congratulation you can now gather feedback around a feature in less than a day and react as quickly... Or can you? Did the capacity to accelerate deployment and iteration actually change how fast, as human, we can react to that mountain of information lying in our observability systems?

3 · The human brain didn't become faster

Here goes the trap, now that the whole toolchain is as fast as computers can be to test, deploy and monitor your software, making a change should be as fast right?

In reality, it pushes the pressure from deploying once during hours to the everyday developers' life.

But the pace of our everyday life didn't change. It takes the same amount of time for human to design a feature, investigate a database performance, read a blog article or learn an entirely new framework.

Selling DevOps as accelerating and enabling people isn't fully right in the end. DevOps pushes some complexity out of the developers way but brings new one that challenges our time management and at it's core the time we have to stop and think about what we are doing, what we are coding, how and why.

4 · It's time to stop and think

I am not advocating against DevOps, I wouldn't code any other way now that I embraced it but that set of practices should be put in it's right place, not in the way of our time as developers. When aligned to the company or team culture, DevOps should actually free developers, product owner, designers and sales some time to gather, stop and think about what they are doing and selling and that time is incompressible whether we like it or not.

Us as developers should embrace deploying as soon as it is ready and get comfortable about having automated integration steps to have a safety net around our probable mistakes. This, on the other hand should not prevent us from taking the time to think our code through.

Let's respect our human pace and our limits regarding how much data we can consume or how long it takes to discuss our software. This way we can take the right decisions and iterate toward the right direction.

jarleton.dev · Essays