Did you know people used to be computers? Yeah, back in the day, before we had calculators or CPUs, people still needed to crunch the numbers. For example, NASA, when they were building rockets, needed to run all kinds of numbers to make things work. So they would actually employ people to sit down with a pencil and paper and do the additions and multiplications necessary to solve their physics equations. ( That’s what Hidden Figures is about, I think. )

By NACA (NASA) - Dryden Flight Research Center Photo Collection - http://www.dfrc.nasa.gov/Gallery/Photo/Places/HTML/E49-54.html, Public Domain, Link

Similarly, programming used to mean setting a schedule for, like, a play or something. It still does, really. So programming a computer, at the time, meant setting a schedule for some person to do a bunch of rote arithmetic (additions and multiplications). And then when they were done, you used their answer to build your spaceship.

By Kat Walsh - Own work, CC BY-SA 3.0, Link

This is still true. Except now the computers aren’t people any more. They’re robots. And when you program the robot, you basically give it a schedule of additions and multiplications to perform. What those numbers end up meaning, when the robot spits out the answer, is up to you.

I think this is the nicest way to describe what programming is to new people. You can even keep the analogy around when you’re talking about more advanced concepts. Consider runtime analysis: if I tell my computer (person) to solve a problem using this program (or step by step schedule of arithmetic), will it take them more or less time than if I give them a different program (schedule)?

Or try abstractions and system design: if I have a really long program (schedule), it might get confusing for my computer (person) and me to keep track of what everything means. (Why were we doing this addition on line 455 again?) Abstraction is just figuring out how to break up that program (schedule) into logical chunks, to make it easier for both of us to keep track of what’s going on. And if we’re lucky, we can re-use some of those chunks, so the whole schedule becomes shorter.

I could probably keep going all day, but last one: concurrency and distributed systems. What if I hired ten people instead of one? Could I get my answer faster? How would I have to change my program (schedule), so that everyone works together without duplicating work? Is it even possible?

So yeah, next time you teach middleschoolers how to code, try this analogy. I think it’s nice.

- Mitchell