What are your favorite analogies to explain programming?

twitter logo github logo ・1 min read

Hello,

I am giving a workshop on Sunday.
The goal is to try to give complete beginners a less wrong idea of what programming is all about.

Not a small challenge given that for my students, programming looks like something aliens do.

Heck, even the majority of companies hiring developers don't really understand programming either! See how they make us solve algorithms on a whiteboard, put us in noisy open offices and make sure to kill our focus with unhelpful meetings and constant interruptions on Slack.

So my question:

What are your favorite non-technical analogies to explain programming?

I'm interested in good analogies AND in the popular but really helpful ones - like Hollywood describing us as doing magic on a screen or recruiters thinking we are Ninja Rock Stars.

twitter logo DISCUSS (29)
markdown guide
 

I’ve always thought of programming as language.

In theory we are doing the same job as an ambassador, speaking the language asking for things. Solving culture specific disputes etc.

Except we are talking to computers, not people, and culture in this case could be patterns, frameworks applications, systems etc.

Incidentally it’s also why programming have been getting more verbal I believe.

 

+100
I love learning (non-programming) languages.
I speak fluently french, spanish, german and english and tried out others as well.
And the analogy makes totally sense for me.

 

Of course everybody approaches it differently and they can all work just fine.

I like to think of myself as a developer as an artisan: like a blacksmith or a cabinet maker.

I'm not an artist, I'm not building sonething that exoresses an idea or feeling but something that works. Of course that doesn't mean it can't be pretty, elegant or richly decorated, but it has to be a working item.

We all may have your own personal style but we're all working with the same basic techniques and it's important that they're compatible and reproducible.

We know where our materials come from and how they behave.

And we love our tools, sometimes building our own.

 

The only ones I strongly disagree with are "Guru" and "Rock Star".

They send out all the wrong messages for me.

 

Yes, and that's because programming is a team sport, not a star system.

This is why the metaphor from Scrum makes much more sense :

A team of rugby players with different skills that shares a common goal, take hints from a coach, but otherwise self organise when it plays together on the field.

 

I taught 2nd graders the concept of programming by having them design and build a peanut butter and jelly sandwich.

Requirements: bread, pb, jelly, knife, plate, etc (have them on hand, but hidden, then have the class list what is needed)
Program: have one group list the steps to build it
Test: have another group follow the "program" literally

So, in my case, the first step in the program was to spread the peanut butter on the bread. We immediately found the first bug. The bread was still in a bag - it had to be opened and taken out and put in the plate. The peanut butter had was unopened, etc. Go back and iterate on the program until they get it right.

It gives them a great feel for how detailed a program needs to be, and that the computer only follows the instructions you give it.

 

Really interesting discussion, thank you. I've often wondered this, but haven't yet hit upon that single dead-on analogy.

Sometimes programming is like writing a recipe for a friend. This friend is incredible at following instructions ... but not much else. Don't forget to tell them to turn the oven off, else they might burn the house down!

Other times programming is like solving a Sudoku puzzle, with all its elements to balance in your head. Each puzzle is different, despite looking similar from afar -- you can never be sure how long each one will take.

For the most part (as others have already said) I like to picture myself as some kind of craftsman. A carpenter, say, who makes high quality furniture -- furniture that is useful, long-lasting and, on the odd occasion, beautiful. (Funny really, considering I know nothing about woodwork.)

One analogy that I don't like is that of a wizard. There's no magic in programming -- everything can be traced back to people. Normal, fallible people, who were each trying to solve a particular problem at a particular time. Retrace their steps and that 'magic' is replaced by understanding. And, ironically, that's one of the most magical parts of programming.

Good luck with the workshop!

 

I totally agree with Replace magic with understanding

I want to begin the workshop with making them try out this tool

hackertyper.net/

Type whatever super fast and it prints out code like in Hollywood Movies.

Then I will say:

Congrats, you can now be a programming ninja in an Hollywood movie.
Now the bad news: this has nothing to do with programming.

 

That's an awesome idea (and awesome tool). You could even have them share a keyboard, like that hilarious scene in NCIS. "I've never seen code like this!"

I wish some of my teachers had been so engaging!

 

The process of programming is not fundamentally different from making a cup of tea. You have a bunch of instructions and a predefined way of executing them and you end up with a cup of tea. There are variables (ie. How much sugar/tea leaves) and sometimes edge cases (ie. Kettle is broken), that ultimately define if you get to enjoy a decent cup of tea.

 
 

For beginners:
Making websites is like building a house, HTML is like the concrete walls, CSS is like the interior design, and JavaScript is the electricity that make things turn on and off when you flip a switch.

For someone learning Redux:
Reducers in redux is just like making caramel, you boil (action) the sugar (payload) until the sugar is fully dissolved into golden color (state). That's why the process of making caramel is also called reduction.

Explaining GraphQL vs REST API:
GraphQL is like going to a bespoke tailor and have your clothes made to measure (use exactly all the data you need). REST APIs is like going to the department store and buy a pair pants with excess lengths so you'll have to cut & make it shorter (use only the data you need).

I always wanted to blog but I couldn’t find the time. So I recently started writing short programming analogy once a day on my Twitter @yansernio just to help me get into the writing mood again.

 

@yansern Now folling you on Twitter :)

In my workshop on sunday, I want to show how to launch a website using GitHub, netlify and a static website generator.

  • HTML/CSS/JavaScript? I will definitely use your analogy :P
  • Git/GitHub? It's like Wikipedia.
  • DNS? It's like the Internet's phonebook.
  • Continuous Integration? (with Netlify) ... not sure
  • Static website generator vs something like Wordpress? ... not sure
 

Continuous integration is like having a team of mechanics working on rebuilding the whole engine of my car, pistons, rings, valves, etc... with the crankshaft not even stopping for a second, and me, still driving the car on the road.

 

Programming is much like writing ... a manual.
You describe every step from start to end and if followed correctly, you reach the goal!

Now your job as a programmer is not just writing down the steps, but also coming up with the them.

Ah ... and you are writing for a (literate) baby, that follows each and every instruction to the letter, but shows no initiative and only understands it’s own language.

 

We are Galton board builders. Had to google this name.

Information are the beads. We can limit where and how it comes from, but there's great uncertainty involved. We use syntax, patterns and frameworks which are the pegs. And for a predicted set of beads falling, the disposition of the pegs has to drive each bead to its right location.

 

I have to confess I have no idea what Galton board builders are :)

 

Aka bean machine or quincunx. Something a Victorian era statistician would built to demonstrate an obscure theorem hard to explain. I find it fitting 😁

youtu.be/S5WAswaJRjw

 

To underlign just how much uncertainty is involved,
I plan to use this Brexit analogy :P

 

I participate on building simulations of the universe as far as I understand.
I develop interactive beings and their environment; similar to the living animals that has the basic input/output functionality to paricipate relational processes of the mass.
I program abstract structures and outcomes in order to build the beast.

The beast that has the consuming and interacting cells. On very basic I name these cells variables then more advanced ones files or objects.
The more advanced a cell gets the more clear its role.
Like an heart take care of blood circulation in a whole, my std object has the handler stdout that stream out the messages while having the stdin on the basic to consume the incoming.

 

Programming is playing god in a world of sand. You can build anything you want but there are hard constraints.

Build with basic granules and it'll take forever to accomplish anything.

Build too vertical and it'll all come crashing down.

Build everything from premade molds and you'll get a lot done fast; but you'll never learn how to work without them.

It's all about granularity. Learn how shapes flow, fit, and bind together. Then apply that knowledge to work with and/or build your own molds to work faster.

Achieve that and you can build anything

 

My wife’s grandmother lived to be 100, but lost Most of her vision in her 60’s, long before computers were anything but sci fi props.

She explained my job to her grandmother like this: “you know how when you buy a TV, you want to use it to watch shows? Well, that’s what computer programs are like... you buy them to make the computer do stuff. And you know how tv shows have a bunch of actors you see, but then there are a lot of other people you don’t see who work the cameras, write the script, edit the video, and stuff like that... well computer programs are the same way. You ‘see’ the program, but there are a lot of people behind the scenes that help create that program.”

 

To me, programming is a journey. It starts with breaking down a problem into littler ones and writing instructions on how to solve them. It very quickly becomes breaking down the larger problem into the right set of smaller problems, while keeping it easy for someone else to appreciate and change the solution later on. Finally, it becomes about using as many users and systems as possible to benefit from your solution.

 

I like the restaurant analogy: the cooking chief is baking your plate (web page), the server (😉) is giving you what you want, you pay with money (bandwidth). If you do not give enough bandwidth, you cannot receive your plate in time, etc... It was very useful when I gave that small introduction to web apps for my students (2 years ago).

 
 

Well, when I teach programming to beginners I say it's like carpentry: It's easy to learn, but requires practice to master.

 
Classic DEV Post from Jun 5

Are we "developers" gatekeeping "knowledge" from our juniors and peers? 🤦

The subconscious role we "senior developers" play, in preventing the spread of knowledge without us realizing. And stifling the growth of all around us.

Jean-Michel Fayard (fr/en/es/de) profile image
“Weeks of programming can save hours of planning.”