Programming Isn’t that Complicated

I saw this image recently — it’s meant to explain a basic concept in programming. It comes from an excellent python tutorial site where you can learn to code. Programming is something that sounds mystifying to a lot of people, and I think that’s really unnecessary. Let’s use this image of coffee cups, but expand it a bit, to look at the kinds of thinking programmers do.

Suppose you work for a coffee shop, and your job is to make sure things run smoothly. You are in charge of designing the process that the employees in the coffee shop follow. That’s what programmers do all day: they are designing, refining, examining and fixing processes.

How Should We Refill the Coffee?

Let’s say a customer wants a new cup of coffee. How should this work?

You might say, “well that’s simple!” — and of course it is — but programmers spend all of their time thinking carefully about things which sound simple at first, and end up having lots of hidden complexity.

The “this is simple” view says, “a customer requests coffee, and the server pours it.” This works great, as long as your servers are only pouring one type of coffee, and you only have a few customers. What happens if the restaurant has room for 10,000 customers, and serves 500 types of coffee?

Busy Waiter from Wikimedia

You can’t possibly have each server carrying 500 different types of coffee. You need a better process. Programmers deal with making simple things work at scale — when the number of items involved in the process is massive.

Taking Orders

One solution we could try: have the servers walk around the cafe, looking for people who want more coffee. When someone wants more coffee, the server writes down the type of coffee the customer wants, as well as the table and seat number for that customer. She then heads back to kitchen, fills a cup with the right kind of coffee, and brings that coffee to the customer.

Right away, with this example, you can see what sort of things programmers might try to make the restaurant work better. How about having the servers take orders for more than just one person? They’d have to spend more time gathering orders, but they could fill multiple orders at once. There’s a trade off: longer time to fill a single customer’s cup of coffee, but more cups filled per minute.

With a larger order size, waiters would spend more time gathering orders, and fill more cups per trip. You can see the numbers here.

Programmers Optimize Processes

If you’ve ever tried to find a faster way to get from home to work — maybe by trying a back road, or turning at a certain light if it’s red — you’ve done what programmers do: look at some simple thing and try to make it just a little faster, because it happens very frequently.

Almost Everything can be a Processes

We’ve already seen that changing the size of the orders that servers take has a trade-off: more orders per minute (which is good), but each order takes longer (which is bad). We might do some research to figure out ‘the best order size’ — but we could also have a process for choosing the order size!

Imagine someone in the restaurant who uses a stopwatch to record how long it takes people to get their coffee from when they ordered. We’ll call her ‘The Performance Manager’. The Performance Manager looks at how long orders are taking, and updates a whiteboard in the kitchen, which looks like this:

Suppose the performance manager knows that customers don’t mind waiting two or three minutes, but five minutes is too much. If the orders start taking too long to get filled, she lowers the “batch order number”. If the orders start getting filled within two minutes, she raises the number, so that servers can fill more at once.

The performance manager is also following a process that can be optimized. We might ask how often she should update the number on the whiteboard, or what she should optimize for. We might have more whiteboards, or different boards for different servers…

You can look at everything in the restaurant through this lens: how is the food prepared? How are the dishes washed? How does the ordering of supplies work? Even things like “How do we advertise?”, and “Where should we build a new restaurant?” — all of those activities can be described by processes, which can be optimized.

A programmer looks at the world and asks, “how does this work now, and how could it work better?”

You may have heard the phrase, “when you have a hammer, everything looks like a nail.” When you know how to write code, you start seeing the processes that were there all along. Everywhere you go, you’ll see processes in motion and think of ways to improve them.

Why Does It Seem Hard ?

Firstly, programming involves learning a new language. Learning a new language takes time and it can be difficult, but it’s doable for most people. Lots of people learn new languages, though, so there’s something else as well. The ‘something else’ is what I think turns a lot of people off of programming. Let’s look at an example.

Suppose you’ve learned enough JavaScript that you plan to go to the JavaScript cafe and try out your skills. You get yourself a table, and when you see a server, you say:

request({type: “food”, details: {drink: “coffee”, size: “small”, flavor= “black”}})

The server comes back with a small black coffee, and it feels like magic. Wow! You did this! You drink the coffee and you feel awesome.

Now you have to pee. You look around, and don’t see any bathroom signs. That’s… odd. Fortunately, you’ve made sure to learn how to ask for the bathroom. The server comes back, and you say:

request({type: “info”, details: {location: “bathroom” })

You hoped the server would give you directions, but instead the server says:

INVALID REQUEST: missing “gender” detail field required for “info” request

What? You can tell the server needs to know your gender — but couldn’t the server just tell by looking at you?

You ask someone nearby for help. It’s a guy with a thick, unruly beard, and a t-shirt that has a joke about filesystems on it. Fortunately, he speaks English.

He helpfully explains that in the JavaScript language there are 300 different genders: “Most of them are historical, so I wouldn’t worry about that. Unless you’re doing something crazy, you should just go with the default for your sex, which is probably Genders.FEMALE.” Then he smiles at you and stares awkwardly for a bit, before going back to typing furiously.

OK! You really have to pee, so you try your request again.

request({type: “info”, details: {location: “bathroom”, gender: Genders.FEMALE }})

The server responds:

{ path: [ { direction: “south”, steps: 50 }, { direction: “east”, steps: 10 } ] }

South? What? You then realize that the server robot can’t point because it doesn’t have arms, and you’re glad you remembered how to orient yourself by looking for the sun. This place is weird…

You walk 50 steps and find yourself at a corner, where you turn right and walk another 10. You’re in a long hallway, with 300 different icons above 300 different doors, and you’re happy to recognize something that looks like it should be for women.

You turn the handle, and the door is locked.

Luckily, someone walking by helpfully explains that you need to send a request to use the bathroom, otherwise you won’t be authorized to enter.

“You probably just asked where the bathroom was, didn’t you? Somebody ought to fix that,” she says, and she goes on her way.

Software Culture is Very Different

That sounds insane. If that were your first taste of ‘JavaScript Culture’, you might hate it and never come back.

Unfortunately that’s what a lot of people’s first experiences must be like. I’m saying this as someone who is so thoroughly enmeshed in software culture that I have a hard time thinking like a neurotypical adult. I have a problem with taking people literally; I had to learn to think about what other people meant, rather than simply what they were saying.

When you talk with people, you generally ‘fill in the blanks’ for them, and expect them to do that for you. Unless you’re autistic, you probably don’t take everything people say literally — you unpack meanings, look at intentions, and take nonverbal cues.

When you ask someone where the restroom is, the other person is usually able to understand that you’re asking because you plan to use it, and that in order for you to use the restroom, you’ll need a key — so even though you didn’t ask “could I have a key to the restroom”, the other person will usually give you that key.

Programming doesn’t work that way. It actually makes things simpler once you get used to it, but there’s definitely a learning curve.

If it seems like ‘magic’, or you think it’s too hard for you — just remember that you’re getting a taste of a strange culture, which is very different from what you’re used to. It’s also a wonderful place that will let you do almost anything you can imagine — so it’s definitely worth learning about that culture and how it works.

If you’re curious about programming, check out that tutorial site I mentioned earlier, and try to remind yourself that you aren’t just learning a new language, you’re learning a new culture which is very different from almost anything on earth. You’ll start to see the world — and especially your own mind — in a new and hopefully more interesting light.

Good luck!

share your thoughts!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s