Raphaël Améaume

Freelance Creative Technologist.

Based in Paris, France.

The elevator pitch

An attempt at explaining programming

  • Thoughts

As a programmer, I often get the same reaction when I tell someone what I do for a living, which is something along these lines: “Oh you write code…” like I’m living in a somewhat different world. I think programming is still seen as some weird magic related skill despite code running a lot of environment, from world finance to local traffic lights. I tend to advocate that programming is not that hard and at core is mostly logic that a lot of people can understand. To be able to explain the kind of problem I’m confronted to when programming, I came up with an elevator analogy. This explanation is a bit longer but I think it has some efficiency in getting people outside of coding an understanding of what we programmers really do.

Let’s take an elevator. What does it do ? It can go up and down. Therefore the elevator has two functions.

How do you make an elevator go up and down ? You tap on a button outside to call it and inside to tell it which floor it should take you to. Great, that’s an input, in this case a user input.

What is a basis condition for an elevator to go up or down ? That it doesn’t goes above its maximum weight it can afford to bring up or down. The maximum weight of an elevator is (at least in France) written in each elevator as the law abides it to. Therefore we have a number that is fixed, and is part of how the system was built. It shouldn’t change except if the system itself changes. It is a constant.

To meet this base condition of the system, it needs to know the weight of the people/objects inside it. The total weight depends on the number of people inside it and their respectable weight. We now have a variable weight inside the elevator.

So now the elevator knows the total weight but what for ? Well it shouldn’t go up and down if the total weight it carries is above its maximum weight. So now the system needs to meet conditions to fully work.

This can be generalized as:

A system works based on inputs, conditionally depending on variables and constants to achieve its functions.

Does the elevator knows what to do when two different people hit the call button at exactly the same time? If not you might have a bug.

This is a very simple example of an elevator but we can see it lacks a lot of functions:

  • What if someone calls it when it’s already going up and down?
  • What if this person is on a floor in between the origin and the destination of someone already in it?
  • What if the floor is outside of this range?
  • What if someone is standing in the middle of a door while trying to close them?
  • What is the minimum/maximum floors it can goes up and down to?

We also don’t know much about the looks and requirements of our elevator:

  • Is it accessible?
  • Is it transparent ?
  • Should it open on different sides?

And so on.

I think programming can be defined around these questions. You first need to understand the functions, variables, conditions of the system you’re building, like in many different jobs. Sometimes the answer is obvious as it’s required by the system to simply be. Sometimes programmers have the answer because they’ve been programming elevators for a couple of years and therefore have experience. And sometimes, it’s a matter of price or preferences to get answers to these questions.