I was talking to a friend of mine recently and asked them if they wanted to learn a bit more about how to code, they said they didn’t want to. I followed up by claiming that what you learn from designing software is very useful generally, but couldn’t really articulate why. I’ve since thought about it a bit and I have something more coherent which I thought I would write up.
There are two main claims:
- Systems are everywhere. Understanding complexity, its tradeoffs, how systems grow and evolve, is applicable to many things and it is therefore broadly useful.
- Software engineering is the purest incarnation of systems thinking, and the one you, as an average individual, can learn by doing.
Systems are Everything.
“A system is a group of interacting or interrelated elements that act according to a set of rules to form a unified whole.”1 That seems broad and, yeah, it is. let’s start by just coming up with some examples:
- Government is a system
- Corporations are systems
- Religions are systems
- 1+2+3 => all human organisations are systems
- The legal system is a system (ok that one was easy)
- Family dynamics are a system
- Language is a system
- A conversation is a system
- Societal norms are a system
- The laws of physics are a system
- and on and on and on.
What’s the point of such a broad definition, and if it is so broad, can we say anything concrete about systems? I think so, here’s some ideas:
- Systems can be immutable (the laws of physics), or “completely” arbitrary (fashion pairings), and many levels in between.
- Systems can be said to be more complex or more simple, at least relative to other similar looking systems. There can be more rules, fewer, many elements, or only a couple.
- Simpler systems are easier for us to learn and to teach to each other. They are easier to grasp.
- Most of the systems we interact with are outside of our control (immutable, physics), or we have very weak influence on (government, through democracy etc), or are at least provided to us pre-made (norms, culture, language). It is rare that we actually need to think deeply about how a system best be made, and even rarer that we need to build one from the ground up.
I believe there are more, but hopefully by now you could imagine there might be something to the idea that systems as a term is broad but still has some depth and utility.
Software is Systems.
These days I like to write without assuming too much knowledge about code since I know that my mum reads these, so I will do my best to bridge the gap. Reducing software to its most fundamental: we are writing instructions for a machine to do some calculations in some particular order. Elements are numbers (1s and 0s), the rules are math. It is itself a system, but since so many things are that’s hardly surprising or special. What’s fun is we don’t just run random sequences of calculations, we like to make those sequences do useful stuff for us. Useful almost always to us means “with some parallel to something in the real world”. A spreadsheet might be a simple model of a company’s finances. The weather report simulates the real weather. The internet is kinda like talking to people. A computer game may attempt to be a virtual world.
These are systems too, but notably:
- They are sometimes, often, simpler than their real counterparts (eg a weather model)
- They may diverge from their real counterparts for many reasons (you don’t need to be online to read a message, you can read it when you have time, unlike talking to people)
- They are created and change way faster than many of the other systems we see.
Already now you may see a part of my conclusion; that if you are given the chance to design one of these systems it serves as a great way to learn it’s real world counterpart. We might often say that the true mark of understanding is being able to explain a concept to someone else. Explaining it to a computer, unable as they are to fill in any gaps you might leave, is surely equivalent. There is more to be gained though. You may also desire to change the model as you work, maybe just to save time or to explore other possibilities. You may attach additional, entirely novel features to a system. Sharing a tweet to anyone on the internet, for instance, was an interaction that simply didn’t exist before software built it. We get to experience the wonders and horrors of these new interactions collectively. But you don’t need a Twitter-sized project to learn from designing systems. Even moderately sized software, even with no users except yourself, teaches you the power and the challenges.
There are other fields that regularly produce systems. Physical models for example are naturally analogous to software ones, but the ease with which we can create software with high level languages, especially now with the aid of LLMs, means that “thinking about the system” is all that really is there. Comparatively, if you ever even have the chance to, say, develop your company’s org chart, it will grow slowly and change infrequently, at least as compared to software.
If you want to learn about them, writing software is designing systems. For me so many of the things I know about software is applicable everywhere. My first post, complexity fills the space it’s given, is a perfect example. From watching empty classes fill up with more and more code I recognised the phenomenon. It wasn’t that hard to start seeing it everywhere in all the systems we exist in, teams at work growing, getting sliced, growing again. Statutes for an organisation becoming more complex, following the structure of headers and filling them in even if perhaps, maybe, they shouldn’t.
Or take debugging as another example. One of my favourite rules is “if you don’t understand a problem, you’re not allowed to fix it”. Often there are many ways to fix a bug, and sometimes you can see a fix even though you don’t know quite what’s causing the problem. The danger is obvious, the underlying cause probably is something that should be found, understood, and interrogated. You realise this for software, then you realise it’s true for all the other systems we interact with. Like drinking more coffee to counteract how sleepy you feel, when really you should be getting more sleep.
So, what would I tell my friend? Probably not “you should learn to code,” which is a big ask for what I’m actually pitching. More like: there’s a way of thinking, mostly invisible until you’ve done it for a while, where you start to see the rules instead of the surface. Systems all the way down. You can get there from other places. Software is just the cheapest, fastest one I know of, and the rare teacher that won’t fill in your blanks for you. The bar to entry is lower than it has ever been. It is also, frankly, kind of fun. Maybe try it anyway.
Discussion and comments on Hackernews.