Arts and humanities in computing

You might work in software because you just like to build cool things. I understand this, and I also like to geek out about things like balanced trees and coupling and cohesion. However, you’re probably building something to solve a problem for someone, rather than just building for the sake of it. Whose problem are you solving? Does anyone have a harder time because of what you’re building? Are you making existing general problems, like unfair distribution of power or resources, better or worse? In short: why should what you’re building exist? You need to be careful that “I just wanted to build cool stuff” doesn’t become too much like “I was just following orders“.

That brings me to the title of this article. I’m not saying that people with no arts or humanities exposure are mindless or uncaring drones, or that people with arts and humanities are paragons of virtue and wisdom. My point is that, while it might appear that arts and humanities are irrelevant for people who work in software, I think the opposite is true. I’ll try to dig into that a bit more below.

This post was inspired by two skeets. No, I don’t like that term either – tweets is what I refer to them as, regardless of platform, and I know Jon Skeet so to me skeet means him.

The first way in which arts and humanities can help software people is that they are often to do with people rather than things. As a software person you need to navigate the world of people unless you have:

• No boss,
• No customers or users,
• No colleagues and
• No desire for self-awareness

It might be that you write software that’s called by other software rather than being used directly by people. You still need to worry about people in this situation, it’s just that it’s the programmers of the software that interacts with yours rather than end users. Instead of user experience, you need to think about developer experience. What makes an API easy to use? As well as good documentation, it’s things like the API breaks the world down into things and sequences of actions that make sense to the programmers who are trying to use it. The API author has understood how those programmers see the world, and has written the API in a way that fits with that.

There is so much in software that’s related to people (as I hinted at above). It’s behind user experience (UX), requirements and design, and testing. You can use UX techniques to help persuade people to accept your proposals. Knowing how to communicate well, when speaking or writing, can be very valuable – it can make you more visible, help you to scale yourself and your influence, and make your life run more smoothly. If we go beyond the world of people, imagination is something more traditionally connected with the arts than with technical subjects, but in my experience it’s been really useful when building software. The links in this paragraph each go to several other posts I’ve written on these topics, so I won’t go into more detail here.

Imposter syndrome is something that loads of software people have. This includes people like me, with a computer science degree and then a career in just software, but doubly so for people with backgrounds other than computing such as the CTO of Honeycomb.io, Charity Majors. I think a prejudice against arts and humanities is an unnecessary fuel for imposter syndrome. There’s sometimes a weird undercurrent of purity in tech circles, as if knowing arts and humanities is dragging you away from the The One True Path of Geekdom. Also there’s a weird feeling of opportunity cost – the time you spent learning Anglo-Saxon poetry could have been better spent grinding out a few more leetcode puzzles.

It’s useful to have the skills of people who have studied a lot of books (such as students of literature, history etc.) when you read things online. It’s not just about understanding the words, but digging into who the author is, why are they saying what they are, and what context is important for it. This sort of thing can help when you see the next flame war among geeks over things like choice of architecture pattern, development practice, JS library, IDE etc.

If you go by what’s online, programming seems to live in the perpetual now, and is free from the burden of history. Something that helps you break out of this perspective is when you work on legacy (translation: useful enough to have survived this long) code. It also helps to have been in the software business for a while, as you have been around long enough to have seen the IT circle of life. This is where New Shiny Thing arrives, is flavour of the month for a while, fades, and then is usurped by Newer Shiny Thing and the cycle continues.

An understanding of the history of your profession helps you to put now into a better context. Yes, New Shiny Thing has some good points, but what are its bad points? What problems does it not solve, and what problems does it not solve as well as other things can? It can help with your judgement of technical things to have a bit of a historical perspective, even if IT time seems to be measured in dog years rather than human years.

You might have had bad experiences in the past where you have been made to memorise dates of battles, or go into tedious detail analysing the imagery of a particular author. What is the point of all this specific detail? It’s just cluttering up my brain, taking up my time and won’t be useful to me. I agree, and I’m sorry if this has happened to you. However, I could say the same about the hours I spent learning the details of the Z80 chip’s machine code instruction set. I have never found it useful that I still remember that C9 is the code for the return instruction.

But I think that both kinds of study can give you generally useful skills and perspectives. Instead of learning the dates of when Henry VIII was married to which wife, you could learn about the factors that changed key relationships between him and the Pope, his wives and his advisors. What was important to him? What was important to other people around him? Similarly, instead of learning the details of Z80 machine code, it’s useful to know that chips including the Z80 often have a single instruction that can test if a value is zero/non-negative and jump somewhere if that’s the case. This means you know why it’s quicker for loops to count down to zero rather than counting up to an arbitrary number, which is used in things like .Net performance improvements.

To sum up, technical subjects can help with what and how, humanities can help with why (or why not) and for whom. They can help you understand, and be understood by, important people around you at work. Geek culture tells us we’re all just one more data structures and algorithms video or one more leetcode puzzle away from geek nirvana. Maybe there’s more to it than that.