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.
Top comments (32)
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.
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.
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.
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!
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.
Funny, there is a (great) podcast called exactly like this from @jcutrell
spec.fm/podcasts/developer-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.
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
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 worksFor 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.
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.
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.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