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...
For further actions, you may consider blocking this person and/or reporting abuse
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
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.
great analogy thanks!
Well, when I teach programming to beginners I say it's like carpentry: It's easy to learn, but requires practice to master.
As far as regular people are concerned we're gods.
I would say: aliens.
you're both right.
One such analogy from me:
Contributing to open-source is like dancing Tango
Jean-Michel Fayard (fr/en/es/de) γ» Oct 11 γ» 6 min read