Putting the Meaning in Platform Engineering

I have been working for a few years in technology, mostly doing platform engineering. I’ve done work for small companies but more often for larger companies. Software engineering is my vocation. When I was little I wanted to be an inventor, and programming is my outlet to make useful gizmos like I always wanted to. So in general, its a pretty good thing to be doing. With that said, I want to talk about one thing that bothers me:

On a day-to-day basis, few tasks relate to the impact of our work on people’s lives.

This is not to say that there is no impact of the tasks we do, simply that it is not often the focus of our efforts. We augment our software and remove technical deficiencies, but no-one asks us to question if the system will be useful.

The problem is not specific to platform or software engineering. In large engineering projects, many people are needed and the individual’s work may not be useful in isolation. The traditional view would be something like this:

Engineers do practical, quantifiable things to shape the world, and subjective things like feelings and emotions are nebulous and unquantifiable. Furthermore, there’s a division of labour, and the strengths of engineers lie in abstract reasoning and attention-to-detail, not in emotional intelligence.

From what I see in software engineering, this view is incomplete. There is too much churn in technologies and too many ‘best-practices’ rabbit holes to get lost in. The purpose of the work is everyone’s responsibility. We can all gain if each person can engage more with the outcomes of their work.

Ghosts In The Machine

In software engineering, we reduce people’s experience to tractable ‘User Stories’, e.g. “as a Developer I want to look at an availability dashboard so I can understand my software better”. This reduction is introduced to define clear and achievable tasks. A side-effect is that we don’t ever need to engage with people’s feelings, only with their immediate wants.

In platform engineering, the user is typically a developer. The necessity for these developers is to get on with the work assigned by the business. Therefore, the question of whether a process makes a developer feel frustrated or angry would not be something that comes up in a user story, only whether the process can be carried out efficiently.

Business Value

There is a further complication. Effectiveness from a business should mean decreasing costs and increasing revenue. In a competitive market, both of these things lead to value being created for consumers, who get the things they want for a lower price. In practice however, businesses build their own ideologies and seek to maximise their own idiosyncratic metrics of “business value”. These values are built up over time as heuristics for efficiency and effectiveness. They make decision-making easier as opposed to reasoning from first principles.

However, as the environment changes, the heuristics an organization has built up for decision-making become invalid. How appropriate these values are at any particular point in time is not easy to determine. So, if we achieve all our explicit goals we still may not produce something useful, we just produce this arbitrarily defined ‘business value’.

If we truly see engineering as a vocation then this won’t do at all.

Philosophy

While we typically won’t have the luxury of ignoring the business desires, we need to bring ‘objective’ values to the table as well. Unfortunately, although this may be debated hotly and lengthily, we cannot be certain that such values exist. To deal with this issue, we need to look to philosophy.

The best answer to this problem in the realms of philosophy comes from existentialism. Existentialism says that it is up to each individual to create meaning for their existence. We need to find our values, and imbue our life with their meaning. While this sounds theoretical, it is important that what we do day-to-day is in line with our deepest values. It is too easy to go through life in a sort of daze, going with what we know and never striking out far enough to find something more fulfilling.

What do values look like? Perhaps a good place to start is “life, liberty, and the pursuit of happiness”. Or maybe Daniel Pink’s “autonomy, mastery and purpose”? Some things I believe are Buddhist dharma - we should encourage expression of the four immeasurable states and alleviate ‘suffering’. In general, different formulations of values will inspire different people. Whatever makes the path easier and life more enjoyable.

There are certainly some values that we should share as a profession. There have been many attempts to set out an Hippocratic oath for software engineers - or more plainly - a shared code of ethics. Although none seem to have caught on in the mind of engineers, the IEEE code is a reasonable and thought-provoking place to start. Due to the universal nature of such documents, this only covers the groundwork for ethical decision-making.

Let’s round out this philosophical section by restating things in a simpler way. As a human being you have things you value for their own sake. Asking sensible questions about the impact of your work on the things you value is one of the most valuable things you can do. It is also something that can never be automated.

In Software

While software can be tremendously valuable, it can cause users a lot of suffering. For example - bloated, unintuitive and arbitrary interfaces waste users time and makes them frustrated. On the other hand, users can find elegance and joy in well-designed interfaces. Even where this is not the case, responsive and intuitive interfaces and allow users to get into a pleasant state of flow.

For platforms, we can think about pain-points that developers often have:

• Centralised infrastructure provisioning with long turnaround cycles stymies autonomy and dis-empower people. It can cause alienation and even lead to conflict. For this reason we should enable self-service wherever possible - up to the point where e.g. it substantially endangers users’ data
• Lack of feedback in the software development process slows down learning and makes the process of developing software both less efficient and less enjoyable. This is why we need to provide tools to give quick feedback on software changes, and make sure access to those is readily available in and outside of a delivery pipeline.

There are surely many more ways in which the platforms we use impact our experiences. If we bring our attention to them more often, perhaps we can deal with them more skillfully.

Finally

There is a Zen proverb that fits in quite nicely with the theme of trying to imbue our actions with meaning:

Before Enlightenment chop wood, carry water. After enlightenment chop wood, carry water.

In programming, we must think about the mechanisms by which our software is to work, we address the requirements in front of us and should ensure good quality. These are our professional duties. It is not our duty to question the purpose of a piece of software, but it is useful. It is up to us how we divine the purpose of each task, and how we let that purpose shape our approach to them. This is how we find meaningful actions.