I am on the train home from a Zig software conference called Software You Can Love. I learned a lot of cool programming techniques and things happening in Zig. But I was primarily attracted to the conference by the name rather than the Zig language, and I leave feeling a bit disheartened.

There was very little discussion about software you can love. In my view, the best conversation about this topic came from one of the speakers, Tyler Calder, who distinguished between software that creates value for end-users, and those that create value for program owners (ie., those who have the power and ability to modify the behaviour of the program). His argument was that software you can love is software that primarily creates value for end-users.

Normally, when software engineers talk about impact, they refer to it in terms of measures like how many users experienced delays loading a web page, how many people installed an app, or errors hitting “buy now”. But these views of impact are small minded. By impact I am thinking concretely about the impacts from creating programs that automate denial of health insurance claims (someone dies a preventable death), connect social movements through online spaces (people come together and exercise collective power), or trap people in addictive use patterns (someone neglects their own needs, is isolated from others, and experiences long-term psychological harm). There is also the null case where opportunities and abilities to solve social problems with technology are squandered because our skills are redirected elsewhere (someone is failed by technology, or finds no available technology for a problem).

The last five years has taught me that software is a tool we can use to influence society and participate in social reproduction (introducing software that persists in the world and results in durable change that people grow to see as normal and act to reinforce). The kinds of software we make have real impacts on human lives and balances of power. We’ve seen this most recently with the explosion in the use of LLMs and other generative technology, and how it’s seeped into all of our lives for better or worse. Nobody would argue that these technologies have not changed everyone’s life and redistributed power over things like labour and what is considered true. This demonstrates that the technology we build has real and incredibly potent effects on the world.

The talks at the conference and discussions with people there made me realise that there is a tendancy to derive great pride from technically sophisticated or aesthetically pleasing software design. It’s really cool to make a slick website, optimize a program using arcane techniques, or do something really unexpected and fun in a program. I think everyone can relate to how exciting it is to build these kinds of ideas into impressive programs. But I think this is a very hollow activity. We are building toys for ourselves to keep our minds occupied—they allow us to play pretend without having any interaction with the material world.

Making software toys might make us feel good and like we accomplished something, but this is an illusion. There is no inherent virtue or achievement in making software toys. There is no value in creating programs that have no or a negative effect on society. There is no value in creating programs that make people’s lives worse. Perhaps it is fine to play with software, but it is the same as playing video games. It’s a way to relax but it’s not something that it makes sense to derive pride from. I think this is a fundamental mistake made by many programmers and something I observed a lot at the conference. A clever way to solve a programming problem is not a solution to anything real. For your software to do that, it needs to have an impact on other people and on society as a whole.

I think this view of software is critical for effective software engineering and I observe that this way of viewing software and its success is altogether absent in software engineers I talk to. I had many conversations where someone is proud of their nifty technical achievements, but I had zero conversations about software that had a change in anyone’s life.

It’s much harder to change someone’s life with software than it is to produce a program that uses a cool technique. Algorithms are much easier than social change. So is it fair for me to expect this from someone?

Firstly, even if it’s hard, I think it’s important that your goals are set correctly, to avoid feeling proud of achievements that don’t matter. Secondly: no, it really isn’t fair to expect a single person to have this kind of impact, because we’re dealing with issues that are much bigger than a single person.

Luckily, other fields have already solved this problem. The solution is called a community of practice. This means we work to find other people who care about the same real world issue, create a community with them, and work together as a team on the issue. Creating community is quite hard and getting harder as our world becomes more insular and individual. We have to work against this tide and practice how to form and keep communities alive. This is a skill that you have to work on, and it’s critically more important than learning a new programming language. It’s so important that I am convinced that learning any new technical skill is irrelevant until one can get a grip on this and start to put it into practice. Not everyone has to be able to create communities from scratch, but everyone should hone their ability to contribute to a community, affirmatively build its strength, and avoid poisoning it. Crucially, these communities need to be organized around a societal goal, and not simply around a programming language or sub-speciality field (eg., distributed systems or DevOps).

But simply building a community of programmers is not enough. If we are solving societal problems, we need to be good “product managers” as well. We need to have actual understanding of the social, political and power structures at play. This means that we don’t make naive software that fails because it doesn’t solve the right problem. This requires curiosity and insight into the problem, structures and people affected. To do this we need to have strong networks with those whose lives we aim to improve. We need to have networks with people who aren’t software engineers and invite them into our communities and projects; in other words, we need to practice co-design. It’d also be good to focus less on problems that technical people face (ie., we’re done building toy programming languages, CLI tools and software infrastructure projects). Once we’ve done this, we need to re-define success in terms of these views and replace our old, shallow feelings of achievement that are easily satisfied simply by learning new programming tricks and constructing flashy interfaces that do nothing.

I want to close off by saying that these are criticisms and ideas I direct at myself more than at you. I have fallen into this trap too. I have not built anything that mattered to someone outside of our bubble in software engineering. Realising this brings me shame. But I seldom feel that others share this awareness of the causal ends of the work they do. So if you take nothing else from reading this, consider this: what is the software you are building doing to the world? Is it really making it better or worse for an actual person, and how can you be sure? How do you decide what better or worse is? (hint: this is the same as asking, what are your moral values?). Continue asking yourself these questions as you participate in software engineering.

Let’s create software we all can love.

Book recommendations

• Community: The Structure Of Belonging - Peter Block
  This book is a good way to start thinking about how to build communities.
• Design Justice - Sasha Costanza-Chock
  This book is an introduction to co-design/participatory design.
• Automating Inequality - Virginia Eubanks
  This book is a good introduction to how software can have life threatening effects on actual human beings.