Laziness and improvisation: two programming superpowers

Photo credit: Gabriel Tovar via Unsplash

Programming is a superpower.

In comics and films, there are several superheroes whose power is to control machines. Programmers can control machines too, except, rather than extending their hands and screwing up their faces in concentration, they do it by typing on keyboards. (Alright, they may screw their faces up in concentration too.)

Moreover, just like the comics, there are many variants of the programming superpower. Lots of superheroes can fly, but they don’t all fly in the same way: some ride on magnetic waves, some raise winds to lift them and others . . . can just fly, without any attempt at explanation. Similarly, some programmers are great at front ends, some are great at back ends, some are great at performance, and others are great at reliability.

I’d like to discuss two variants of the programming superpower in this article: laziness and improvisation.

Laziness

It’s a cliche amongst technology people that a programmer will spend ten hours automating a task that takes ten minutes. And, like many cliches, it persists because it is true. I have often found myself taking unexpected diversions from my planned work, because I needed to automate some niggling task that I would otherwise have had to do manually.

This is the laziness superpower in action. It may not look like laziness: the person who is exercising this superpower may be concentrating hard, typing fast and working outside normal hours. But the goal is to save themselves work in the future. If you are a non-technical project manager, and you are worried that your team member is working on something that’s not on the plan, it might be best to leave them to it: tomorrow they will be more efficient and, even better, they will have created a tool that makes everyone else more efficient too.

Programmers don’t like boring work, they don’t like being disturbed, and they don’t like working on someone else’s terrible code (especially when that someone else was themselves a few months ago). The best way to avoid boring work is to automate it; the best way to avoid being disturbed is to build reliable solutions; and the best way to avoid being baffled by your own horrible code is to write good code that is well documented. At its most developed, the laziness superpower looks a lot like diligent professionalism.

Improvisation

Like many people, Apollo 13 is one of my favourite films, and, like many people, one of my favourite parts is when they are trying to find a way to keep the CO2 scrubbers working. It’s the part of the film that contains the line, ‘We’ve got to find a way to fit this . . . into the hole for this . . . using nothing but that.’ This is just one example of the creative improvisation needed to bring the crew home safely.

The good news is that, if you enjoyed this part of this film, you might enjoy a career in technology. A surprisingly large amount of programming work is getting this . . . to fit into the interface for this . . . using nothing but that. One of the reasons that programmers who get involved in the selection of software packages spend less time fixating on the UI and watching the demo than their less technical friends, is that they know that all of their work will be at the back end: getting systems to talk to each other (and they also know that the UI will change anyway).

You might imagine that, by now, decades into the computing revolution, there is nothing new to learn about how to put systems together to meet business needs. If you do imagine this, then it’s definitely worth spending some time learning to code and working on an integration project. While they contain some familiar patterns and techniques, every one of them is unique, and every one needs the improvisation superpower.

I often argue that everyone should learn to code, not just because we need more programmers, but because it helps us understand the way that software gets built, and thereby gives us a deeper understanding of the world. Many people are sceptical about this advice, because they imagine that programming is a rote task, relentlessly turning lines of requirements into lines of code. I hope that in this article I’ve given some idea of why programming can be exciting: it’s a constant battle with the forces of error, waste and complexity, requiring us to invoke our powers of laziness and improvisation, alongside our powers of imagination, resilience, curiosity, courage and many others. You still may not believe me, but you won’t know unless you try . . .