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.
Latest comments (32)
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.
great analogy thanks!
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 worksTo 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 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.
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 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).
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
Type whatever super fast and it prints out code like in Hollywood Movies.
Then I will say:
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!
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
stdobject has the handlerstdoutthat stream out the messages while having thestdinon the basic to consume the incoming.As far as regular people are concerned we're gods.
I would say: aliens.
you're both right.
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