What are your favorite analogies to explain programming?

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.

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.

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.

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!

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.

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.

One of the best analogy to try and talk about programming in a non-technical way is picturing out LEGO

If you look well. LEGO provides you with the tools you need to build something useful or something others (your friends) might like. And what it's being built is under it's own 'Framework' which is the way how LEGO it's constructed this is the framework. You have the tools which are the small lego pieces. And then you put the creativity in your run by building something amazing with these things you've been given. Pretty much how programming works

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.

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

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.

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).

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.

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.”

I'm surprised no one has said this yet! Programming is like music.

Programming languages are like instruments. They all play music, but the specific things you can do easily with each instrument differs (a.k.a. there use different paradigms). I could easily play a melody on a guitar or on a piano but would not recommend that someone try to play a melody on a drum kit (at least not to a beginner)! Similarly, I would not recommend someone try to write a web server in SQL!

Also, a band (or orchestra or whatever) is a system of several different instruments doing their own unique job to achieve a goal: play a song! Similarly, a technology stack comprises of different components all doing their own unique job to achieve their goal.