The liberal arts of tech

Hello everyone,

Today I'm both excited and honoured to introduce a guest post by Iris Meredith, the founder of deadSimpleTech. Iris and I seem to be aligned on many core values, including promoting craftsmanship and learning for the sake of becoming a better human being. I know for a fact that is something many of you, dear readers, also appreciate, practice and value.

Iris has recently launched a very interesting and unique product in this space, called Arca. When most people are euphorically deciding to outsource their thinking and knowledge to machines, I believe in playing the long game. Knowledge is a powerful way to control your life and destiny. Iris captures that perfectly both with Arca and with the article I'm thrilled you're going to read!

Happy reading, and thanks, Iris, for sharing your thoughts with us.

A brief introduction before we begin: for those of you who don't know me already, I'm Iris, I live in New Zealand and while in years past I'd probably call myself a software engineer or a data scientist or something, these days I mostly write about tech and coach software engineers in engineering fundamentals and statistics. You can find my blog here.

When I started writing this article, I'll admit I was thinking that I'd write something about the practical importance of knowing the fundamentals of computing technology: how knowing how manual memory management works, say, can improve your ability to write efficient code and such. And there is doubtless something to this. But it's not why I teach the fundamentals.

The reason I teach the fundamentals is because there are certain technical skills that are proper to and required of a free professional working in the field of computing. Without them, you will find yourself bound to employers in abusive ways, beholden to companies that can extort money from you at will and stuck using technologies that are deeply inappropriate for the tasks you're trying to do, simply in order to get something done. Whatever your speciality, whatever it is you do, you need to know these things to participate freely and equally in the tech community.

What this is to say is that the tech industry, by this point, has developed its own set of liberal arts. This might, on the face of it, sound like an odd claim, so let's begin by digging into what a liberal art is.

Artes liberales

There was a sense, even early on during the classical period in the greater Mediterranean, that there were things that a citizen of the Roman Republic or a self-governing Greek city-state ought to know in order to effectively discharge their duties in the political life of the city. This began with rhetoric and a knowledge of the law, expanding out gradually to other areas as the states grew and changed.

By Late Antiquity and the early mediaeval period, the seven liberal arts were formalised as the Trivium (logic, rhetoric and grammar) and the Quadrivium (geometry, arithmetic, music and astronomy). And while these are quite old-fashioned and have, unfortunately, been partially co-opted by weird reactionaries, they're still a pretty good set of things to learn to prepare you for taking an active role in society as a citizen.

The point of these skills being what was taught, initially informally and later in schools and universities, is that in antiquity these were the skills proper to a free person (liberalis). They were the things that a free person needed to know in order to do their duties as a citizen and function in society: the skills needed to defend yourself in court, the basic tools needed to learn the higher faculties (law, theology and medicine) and the knowledge needed to serve effectively in the military and participate in the political live of the state. Without knowing these things, you would find yourself struggling as a citizen.

Looking at the state of modern politics, it's difficult to say that this was a bad idea, exactly. And while I think the traditional liberal arts remain an excellent set of things to learn for anyone who wishes to be a fully engaged part of our societies (which, given how much software is intertwined with the running of the world these days, we all have a duty to be), we in tech have an analogous set of skills that we need to learn. After all, we not only need to be free citizens, we also need to be free professionals.

What do I mean by "free professionals"? Simply put, we need certain basic skills and knowledge to be able to practice our craft and build things on our own account, without having to obey the dictates of our bosses and do what they tell us to. We need these basic skills and knowledge to be able to lead others, to be able to set a direction for software work that a group of people is working on, to build a unity of vision while allowing individual people latitude to make full use of their own creativity. And we need these skills and knowledge to be able to fight back when others demand that we build things that are shoddy, pointless or that put people in danger. In short, we need these skills to fully exercise our responsibilities as free people in our profession, not just as citizens.

What should a free tech professional be able to do?

This position, of course, raises the question: what are these skills? What are the liberal arts of tech? There are, I suppose, a number of ways you could make that choice, but for me, the essence of it is summarised in the following statement.

A free tech professional should, without too much difficulty and without the use of an LLM, be able to write some software of personal use to them in their day-to-day or professional lives, test it and share and distribute it on the internet without the intervention of a company (Domain providers and ISPs excepted).

This seems, to me, to be the minimum that we all need to know how to do if we're to be able to meet our moral duties as engineers with free will and agency. Below, I've broken down the points individually.

Writing software of personal use to you

To be a properly free professional, you can't just work to a spec that someone else has written all the time: you really do have to design something that's meant to meet your needs, or the needs of someone really quite close to you. The hardest part of being a software engineer, after all, is figuring out what code to write. That's remarkably hard to do starting out from code that you're writing for someone else. In the first instance, a lot of the code that you wind up writing in standard employment generally shouldn't be written: it's fad-chasing, aims to fix a bug that was itself introduced by fad-chasing, pursues change for the sake of change or is being written because management demanded it with no clear use case (much less a business case) for it existing. In this situation, it's impossible to learn how to write the code well, because any code that you write will be bad: the correct code to write is no code.

Even if, by some miracle, you avoid all of these situations, code that you're being told to write is oddly distorted: the architecture of the code often has to fit the wider codebase rather than what's best for the specific problem being solved. You'll often find yourself railroaded into bad solutions because the good ones aren't available. And worst of all, you probably don't care, in the end, whether the code itself does what you want: certainly not as much as you would if it's a problem that's personal to you.

This means that, to be a properly free technical professional, you need to be in the business of, at least occasionally, writing code to solve problems that you actually have. It doesn't have to be much code: a personal website, some python scripts that automate some of your more boring chores or a discord bot are all the kinds of thing that you might want to write. But it does have to be something that solves a problem that you have.

Testing the software

It is startlingly easy, when writing code, to not check whether it actually works. This problem perhaps arises the most in enterprise software, where you often find yourself writing code that you actively can't confirm works in any meaningful way, but it pops up in a surprising number of places. It's not uncommon these days to see vibe coded startups that don't bother to check things like whether a user can actually sign up to their app and deploy their software with broken authentication flows. In this new LLM age, an increasing amount of software doesn't work, but rather just looks as though it does.

Testing these days usually means automated unit tests, but to my mind, manual testing skills are arguably more important. Can you run your code? Does it build? Can you step your way through usage flow with no issues? What about if someone gives an invalid input somewhere? Does the software, in general, do what you want it to do?

Manual testing is a skill in itself, one that's well worth developing, but also one that's often neglected in technology settings. And this is a transferable skill: getting good at manual testing will help you design testable software, which is both, more often than not, usable software and is easier to write unit tests for automatically. Paying close mind to QA tasks, then, is very much an important part of developing the skills proper to a free engineer.

Deployment and maintenance

To my mind, you haven't actually written a piece of software unless you've deployed it and maintained it for a while. So much of the engineering life cycle, after all, only happens after the code is written and sent out into the wide world. You have to find affordable, reliable and secure ways to host your software. You have to catch and fix bugs as they arise, to make sure that what you've deployed is available (either to the world or to yourself) when it needs to be, to modify your code and deploy changes as you develop new needs and the code that you've written finds itself in a new environment.

To be a free technical professional, then, you have to deploy and use the code that you've written. Without that, the responsibility and the discipline that makes sure that you write robust, efficient and secure code finds itself missing, and you lose out on a lot of lessons about good. Consequently, the code that you write elsewhere will end up being a lot more brittle than the code that you'd write if you had that experience and knew, more or less, what to look out for. Deploying your code will teach you what security risks to look for, what kinds of code can end up being inefficient and what architectural patterns make migrations or deployments of new versions difficult.

Limited intervention from companies

You will note that, in the course of this list of things, I've stressed things that you can do by yourself over things that you can do by buying a service wherever possible. After all, an awful lot of tech products these days are the equivalent of package cake mixes: sure, they technically involve more cooking skill than just buying a cake, but they're much closer to buying a cake than making one from scratch. Take Vercel: sure, you may have written the Node app yourself, but when it comes to deployment and maintenance, you don't really have to think, and consequently you don't learn. You can just exist in a pleasant haze of vendor lock-in, at least until you get hit with an unpleasant bill or three. Stepping out of the vendor ecosystem and doing things for yourself, however badly, is an essential step in learning.

You don't have to be militant about this: I use Gitlab rather than self-hosting a code forge and have a lot of my services running on Hetzner rather than owning my own servers. All of these things expose me to some risk and mean that I'm pretty far from being the kind of purist that I would be if I pushed all these things to their extreme. Nonetheless, even what I've done cuts out several layers of middlemen, shields me from quite a bit of potential fuckery and saves me money to boot. It also buys me more flexibility: after all, if the AfD do something horrible in Germany and I have to get all my stuff off Hetzner, it'd take very little work to migrate my existing stack to another cloud, or even to a local server. That'd be much harder to do if you were relying on Vercel for everything.

If you can do all of these things, even if only a little, the code that you write will be much better, you will become much more confident as a technical professional, you will be able to push back against bad decisions made by others that much more effectively, and most importantly, you will be able to carve out a little space in the tech world for yourself and do what you want in that space. You will, in short, be in a position to actually use your formal freedoms.

Why care about this kind of freedom?

If you've read this far, you may have noticed that I'm using a definition of tech freedom that's quite a lot stronger than what the Open Source software movement would probably call it. The Open Source movement has historically taken the position that if the software you're using meets certain qualities for freedom, you'll be fine: what you know doesn't necessarily matter (or perhaps, for some of the more misanthropic members of the movement, if you don't bother to learn you deserve what happens to you). If the source code is available, you can modify it and you can build your own binaries, you have nothing to complain about, right? I'm not so convinced.

Theoretical freedom to do what you like with your computer is only usable if you have the skills to act on it. Being able to build software from source code is no use to you if you don't know how to build source code, or if you don't even know how to clone a git repository. And you have to be able to do these things quickly and almost instinctively: only being able to do them with a struggle is little better than not being able to do them at all. You can't just use free software: you need the skills and knowledge to capitalise on that freedom and become a free professional.

This doesn't mean that you have to immediately jump into learning all the fine details of how to write a kernel, manual memory management and sophisticated algorithms in low-level code (though of course it can if you want it to). It does mean, though, being able to do the basics without a company getting in the way (or well, with as few companies getting in the way as possible. You don't want to have to be beholden to Vercel to deploy a basic Node application: you should be able to do it yourself. You should be able to use git effectively without leaning on an LLM. You should have the skills that you need to manage a remote server safely and effectively. And ideally, you should be able to do all of this pretty effortlessly.

You have at your fingertips one of the most powerful machines ever devised by humans. You can use this to do great good, or to do great evil. But to do either of those things, you need to understand the machine you're working with. Otherwise your every use of the machine will be beholden to Dario Amodei and Sam Altman at best, or Elon Musk and Peter Thiel in the worst case. And I really don't think anyone in their right minds would want that.

Arca is my project to, in one way or another, allow people to learn some of these liberal arts in a way that's effective and appropriate to the time we find ourselves in. We're in very early days yet, but the platform is available in early access, so if you're interested, please sign up and help me realise the project in full.