How to explain programming to your Mum

Image via Wikipedia

This article will hopefully be helpful for those times when you have to explain to your mum/dad/girlfriend/person on the bus what it is you do all day. I can't help you explain the intricacies of your particular scientific field but I can help explain how all the computers get involved.


Carbon vs Silicon

Transistors lie at the very heart of all computers in the same way that neurons lie at the very heart of a brain. The difference is that transistors are digital, they are either on or off, where as neurons are analog, they have varying levels of stimulation. The digital nature of computers is seen at every level of abstraction and it what makes them brilliant at logic and mathematics. Humans, on the other hand, are creatures born of the analog with all the vagueness and uncertainty that entails. We might be less proficient at pure logic and mathematics but we make up for it with pattern matching and generalization.

Translator

One way of explaining what we do day in, day out is to think of us as translators between the human world and the computer world. As programmers we have the hard-won ability to take a problem from human space and translate it into computer space. Not only that but the computer we are talking to is brilliant but very, very pedantic. We have to remove all the vagueness out of the human problem and make it into a crystal clear computer one. It's a little like the difference between a map and a set of directions. With a map you can find your own way and you only need one; it's a general solution. A set of directions is very clear but it's very specific, if you make a mistake the rest of the instructions become rubbish. Dealing with a computer is like only dealing with sets of directions.

Sometimes this translation is easy like asking a computer to do sums; often lots and lots of very complicated sums. A lot of the time, however, the translation is very hard. Unfortunately, the things that are often very hard for computers (eg. natural language processing, face recognition) are things that people find very easy. An interesting way of helping people begin to see the huge difference between computers and people is to ask a person to add together a billion random numbers in less that a minute. They'll say it's impossible. Then ask them why they can't do it but their computer can. Similarly humans find it very easy to recognise people, talk with lots of different people, read all sorts of handwriting (but not doctors') and other things that are very difficult for computers.

Designer/Architect

As programmers we are also designers and architects (but rarely can any of us actually draw). After we have translated a problem from human space into computer space we have break it down into the very specific set of directions. This is fine if you only want a program to do one thing but we want our programs to have a bit (or a lot) of flexibility. This flexibility adds complexity and that complexity needs to be managed. Get your design right and your program is flexible and can be changed. Get it wrong and you make your life really hard.

The architect analogy is good for when people keep wanting you change your program when you are half-way through. People don't ask architects to build a skyscraper and then come along 6 months later and demand that it also fly but it seems fine to do it with a computer. The problem is that the architecture is hidden behind the interface and the cost of changing it isn't seen by the user. It's like going to the theatre, from the front the set is plush and fabulous but as soon as you go behind the scenes it all industrial. The danger is that if you don't maintain the set then one day it'll collapse or catch fire. While it is unlikely your code will burn a building down, having your code collapse (crash) a lot is a sign that it needs some maintenance work.

Summary

Translator, craftsman, architect, designer, creator of directions. All these are analogies we can use to try and explain what we do as programmers. Each touches on part of what we do but without being one it's difficult to put your finger on quite what it means to be a programmer.

What analogies, metaphors or stories do you use to explain what you do?