I am referring to explaining to the non-programmer what programming is. I made sure to search for similar questions before creating this one, but the few ones I did find seemed to dodge the question, and I specifically would like to see some metaphors or analogies. I personally find it easier to explain something technical to someone through the use of metaphors or analogies.

The reason I'm interested in this is because many people encounter the work of a programmer on a daily basis, but if you ask the average person what a programmer is or does, they don't really know. This leads to certain situations of misunderstanding (ex. "[...] but I thought you were good with computers!")

I really would like to find the best one out there. I would like to be able to easily explain to someone what my career choice is about. Of course, at least the general idea.

I personally don't have a solid one, but I have long thought about it and I have usually gravitated towards the 'language' metaphor, where we happen to know a language that computers understand, and therefore we are able to tell computers what to do, or "teach" them, to solve our problems.

For example:

Imagine that in an alternate reality, humanoid robots with artificial intelligence exist, and some people are able to communicate with them through a common language, which is a variation of English. These people who can communicate with the robots are able to teach them how to solve certain problems or do certain tasks, like doing our chores.

Well, although robots like that don't exist yet, programmers of our time are like those people, but instead of communicating with the robots, they communicate with computers. Programmers "teach" the computers how to perform certain tasks or solve certain problems by means of software which they create by using this "common language".

Programmers and this "common language" are what give us things like email, websites, video games, word processors, smart phones (to put it simply), and many other things which we use on a daily basis.

I don't mean to put programming on the throne or anything, it's just the best metaphor I could come up with.

I'm sure someone will find some issue with this one, it's probably a bit contrived, but then again that's why I'm asking this question.

  • I guess learning a programming language is somewhat analogous to learning a foreign language. However, the act of computer programming is very different from the common act of talking/writing. Computer programming requires at least: precision, innovation, concentration, creativity, organization, persistence, and rigorous logic.
    – Ami
    Commented Sep 14, 2010 at 4:03
  • I'd think to counter the well-known "but i thought you were good with computers" you'd have to incorporate such a misunderstanding into the metaphor, for instance someone could think cops are great at committing crimes because they "are good with crime scenes" or something.
    – deltreme
    Commented Oct 11, 2010 at 12:03
  • Why not just explain what a programmer does? All this talk of roads and robots and building blocks is plain silly. If I ask a a stockbroker what they do I don't want to hear gambling anecdotes; if I ask a plastic surgeon what they do I don't want to hear about artistic flair (or whatever) - just state the facts! Commented Mar 4, 2011 at 5:18

23 Answers 23


It's like having to write detailed step by step directions for how to drive somewhere. But you usually have to add contingency plans for things like 'what if there is a traffic jam', or 'what if a truck breaks down in the turn lane'.

And sometimes you have to dive even deeper and explain the rules of the road like which side to drive on or what to do at a red light. And sometimes you even need to explain precisely how the steering wheel or the gas pedal works.

And usually, once you've got that all described in exacting detail, the customer says "that's perfect, except it needs to work for someone driving a hovercraft"

  • 3
    Or you can just PROLOG it: this is you in the car, this is your destination, this is an accident, now tell me, can you get to the destination without having an accident?
    – biziclop
    Commented Mar 3, 2011 at 17:18
  • No, it usually changes to "Perfect, but we really wanted a house...". Love your analogy though :)
    – jmq
    Commented Mar 3, 2011 at 17:41
  • 3
    Great analogy. Also, the car is driven by someone who will do exactly what you tell them but has no common sense or ability to make decisions on their own.
    – Bob Murphy
    Commented Jun 16, 2011 at 5:30

I write very, very detailed instructions for a very, very dumb machine.


I use the metaphor "We write knitting recipes" which is grandmother friendly.


  • Knitting is a rather simple mechanical process where you basically need to follow detailed instructions exactly to get anything out of it.
  • Most knitting instructions are for multiple sizes. This gives you if-statements and math and loops.
  • You get to find the error in the recipe when the army of angry grandmothers come with their buggy sweaters!

Not very good analogy but when people tell me to fix their machine I say "I am the guy that designs the cars. I am not the mechanic!"


As a kid, I read a really good description of programming: it's like telling a robot how to do a common, everyday task, like going to school. So you can tell it to "Go to school!", but it doesn't know how. So you tell it to "go outside, take a left, keep walking until you come to the school, take a left, go in, and sit down". But there's a road in the way! So you have to tell it to "stop at the road, check that there is no traffic, cross the road, and keep walking" somewhere in the middle there. And what about doors? So you add "check if the school door is open. If it isn't, open it." in there. Eventually, you have a program that can tell your robot how to get to school by itself.

This dovetails very neatly with Logo, where you instruct the turtle in exactly this way to create complex shapes.


Programming is like a box of chocolates. Sometimes you find what you're looking for right away, but most of the time it takes a lot of trial and error. Sometimes you get coconut.

Traffic lights. Cars are either moving or stopping. One traffic light is easy to imagine setting up, but what happens if you add another? How about a third? What about an entire city? A transit system is made up of thousands of stop lights, each one simple in and of itself, but when taken as a whole, it becomes a complex system. If one of those traffic lights malfunctions or is off by just a few seconds, it throws the whole system into chaos. If everything is in sync, you just enjoy the ride.

A motivational speaker finds keys to unlock the puzzle of people's motivations, dreams, and ideas. Each situation, each person is different. What worked in the past may not be appropriate now. Sometimes a key can be reused, but needs to be adapted to the individual. Other times, the key must be fashioned anew. What is most rewarding is when the person has been unlocked and you see them go out and conquer the world. The most devastating is when you feel close, but just aren't able to unlock the potential.

A detective story, where the detective slowly builds his case by searching for clues and gathering evidence. Methodical, smart, and accurate will win the day. Sloppy, ignorant, and lazy will doom the case. Eventually, the work will stand or fall before a jury of peers.

A slot machine. You put all your coins in and pull the lever. Sometimes you win big, sometimes you sit there for hours and nothing happens. Sometimes someone else just casually walks by, pulls the lever once, and wins the jackpot.

Music. One note is simple enough, but a measure is more complex. A complete song has many measures with many notes. If one note is off, it can ruin the entire performance. If every note is perfectly delivered, the performance fades into the background and only the music exists.


The best metaphor for anything is itself. Anything different will lose some accuracy. As such, picking the best metaphor depends on what, specifically, you want to capture about programing. Since there will be a lot of answers given here about coding metaphors, I'll answer with the classic metaphor for the development process as a whole:

Building Construction

The most common aspect of this metaphor is that a physical architect is somewhat analogous to a software architect. Here are a few other parallels:

  • Changes are cheaper and cheaper the earlier you make them. That is, you can move one line on paper now or 10 tons in cement later.
  • A building without a proper plan will tend to collapse
  • The builders attempt to implement what the client wants. If the client doesn't accurately describe what they want the building to look like (or there is some other failure in communication), it'll be costly to change.
  • There are certain laws of physics that cannot be bent. Just as a three-hundred foot wide 2nd story cannot be built on a 100-foot wide 1st story, feature X cannot be built without a robust subsystem Y.

Of course, like any metaphor, it has its limitations. Some flaws with it:

  • Buildings are 1-time use; you build it somewhere, and there it stays. You can't copy it a million times for a million different users with a million different needs at zero incremental cost.
  • Buildings are considerably more immutable than software.
  • There's no clear analogy to building material cost. A line of code costs nothing- only the time it takes to produce it costs money.
  • The incremental architecture that is (depending on who you ask) possible with software is not possible with construction, where you design it once, then build it.

So, like any analogy, it depends what you're trying to explain. Be wary of over-relying on any one metaphor, or your customer will start wondering what the property taxes on his new payroll system will be.

  • Only that, if you have misaligned the kitchen door, the roof won't explode. Houses are robust, but software is as rigid as card house in comparison. It can't be avoided as the implicit and explicit rules (model) will become extremely complex rather soon.
    – KarlP
    Commented Sep 10, 2010 at 5:35
  • You can copy the blueprint! You can always extend the building, like adding an extra 25m^2 for your new jacuzzi!
    – Zolomon
    Commented Sep 18, 2010 at 11:18
  • The flaw in the analogy isn't really the 1x use and real/virtual nature of materials/location (each build is unique). The real flaw in the building analogy is the dynamic behavior for the building's matter is in being a barrier; providing a space within which activity is sheltered from space and activity outside. The dynamic behavior for software's "matter" is processing data. Commented Oct 14, 2010 at 4:06
  • Good illustration at the beginning of this blog post: orestis.gr/blog/2010/11/06/why-i-bill-hourly I was going to write my own "metaphor" question but then I found this one and found the answer most like the one I would give. Commented Nov 8, 2010 at 14:47

I love Chris McMahon's analogy of Software development being like the creation of music, particularly jazz music.

This is Ella Fitzgerald and Count Basie doing the song One O'Clock Jump. The song is a twelve-bar blues, which is the jazz equivalent of a database app with a UI. By which I mean: just as every programmer has built a database app with a UI, every American musician has played twelve-bar blues. It is a framework on which many many many songs are hung, from Count Basie to Jimi Hendrix to the Ramones.

This particular video is a great example of agile practice. Listen to how the voice and piano influence each other. This is a lot like pair programming, and it's a lot like TDD: voice does something; piano responds; piano does something; voice responds. And notice the eye contact. These people are intensely aware of what's going on instant-to-instant. They have no sheet music (BDUF). They are involved in an activity that takes intense concentration and skill, just like good software development. They are also clearly aware that there is an audience, just as good software development should be aware of the needs of the people paying the bills.

Here's the link to the blog post in which he discusses it: http://chrismcmahonsblog.blogspot.com/2007/05/example-of-analogy-monks-vs-music.html


Sometimes I refer to programming as to controlling mindless zombies. Summing up my blog post about it:

  • Like zombies, computers we operate with are very dumb. It's hard to instruct them to doing anything unless the instructions are detailed
  • The zombie is aggressive and if we miss tiny detail in instructions, leave the creature unhandled, it can crush everything around himself. The same with computers: a lack of a detail in instructions can make your program crash and destroy your data.
  • You have to know magic if you want to control a zombie. The same with programming.
  • The more people with brains gather in one place, the more computers they're likely to have. It seems that brains attract computers--the same way they attract zombies.

Programming is like building things with Lego:

  • You're sticking lots of small bits together to make bigger things
  • The small bits come in a limited number of shapes and sizes
  • The small things can only fit together in certain ways
  • Playing with this stuff can be a lot of fun

Programming a computer is like raising a child...

  • Everyone disagrees on the right way to do it
  • It keeps you up at night
  • It never does what you tell it to
  • No matter how many books you read on the topic, when you go to do it, you feel like you have no idea what you're doing
  • After a while you tend to get lazy
  • You expect it to have great returns in the future but you end up having to maintain it until its end-of-life
  • It's never quite as clean, clever, or secure as you wanted it to be
  • When you look back on it later, you wonder what the heck you were thinking
  • Despite all the stress it's caused you, you love it anyways.

The main difference is that we get upset if someone steals our source code, but we're often glad to have someone take our kids off our hands.


Programming is like building a factory or an assembly line.

Automated Production Line

Think of software as a machine or assembly line that exists inside the computer. Some raw materials and components are fed into the machine, and it follows a set of procedures to process them into some final product. The procedures are set up to perform a specific operation on some raw material or component to a specific set of parameters (eg, time, temperature, distance, etc) in a particular order. If the details of the operation to be performed were incorrect, or the machine's sensors aren't correctly calibrated, or if some raw material or component wasn't within expected quality standards, it could change the operation's outcome and the product would not turn out as expected.

Such a machine is very rigid in its operation and acceptable inputs. Machines don't question the designers' intelligence nor its current operating environment. It will continue to follow procedures as long as it's directed to. Even if a change in raw materials or components could have a drastic effect on what happened in later operations, the machine would still perform its procedures. The process would need to be reviewed to see what changes to the procedures were necessary to compensate and produce the desired result. A change to the product's design or configuration might also require a significant change to the operations performed or their order. Although those in charge of production quickly learned the importance of isolating operations as much as possible to reduce undesirable effects between them, a lot of assumptions are made of the condition components are in as they undergo processing; assumptions that might not be detected until the final product is in the hands of the user in some different operating environment.


Helping a fast idiot pass a math class that requires a written essay.


Computer programming is like playing a game of chess in which the size of the board, the amount of pieces in play and the rules that govern those pieces grow in size and complexity as the game goes on.


New students to C.S. / Programming classes are, practically, like non-programming users. The robot example is good.

Back, in the 80's, using Logo, Karel, (or similar programming enviroments), where the user learns to program, watching the computer like a robot, instead, of a T.V. set with a typewriter, helped a lot. Those tools where commonly used in Junior High School and High School.

That practical programming helped the students to adquire problem solving skills, even if they weren't computer related !!!

Or, even if the students didn't become programmers.

Some Collegues and Universities also applied those tools in first year courses.

I wonder why many high schools drop teaching Logo and Karel...


I like Fred Brooks analogy, from Mythical Man-Month, that programming is like performing magic.

(The) program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible output seperate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be. ...

(One) must perform correctly. The computer resembles the magic of myth and legend in this respect, too. If one character, one pause of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.


"[...] but I thought you were good with computers!"

This is usually an attempt to trick a geek into fixing a computer (you feel that urge to prove them wrong?). My standard answer:
I'm a programmer. That's like an automobile engineer - he probably won't know how to fix the brakes of you '72 Trabant, and certainly wouldn't do it if he knew. A mechanic would do that!


I am fond of the concept of a recipe for cooking.


Programming is like wielding massive amounts of power. You can make the computer do anything you want it to. You are only limited by your imagination and the amount of time you're willing to invest.

Programmers are like the makers of a house. We can tell you everything about the houses we've made. Yet, if you ask us ask a random house we happen to be passing on the road, chances are we probably won't know much about. But if you need something added to or changed on that house, we can make it happen provided the owner lets us.


In one of Chris Crawford's old articles about programming he likened a complex program to a bureaucracy, with multiple agencies that communicate by passing memos back and forth. I've found that to be a very useful metaphor when explaining software development.


I generally equate programming to a jigsaw puzzle.

For creating a new project - you have tons of pieces, a couple of which don't belong to this image, and you don't have a preview of what the puzzle looks like when it's done. But you do know the size and general colors, so estimates are possible, but not necessarily accurate.

For modifying an already-existing project - a cat came by and knocked off a chunk of the finished puzzle. It'll take some time, but the framework is already there, so it shouldn't be too bad (depending on how much needs to be changed).

It also helps for describing progress. One of my recent projects, at one point I was wondering how to describe it so that a non-technical person would understand why I don't know how much longer, and I came up with: Think of a jigsaw puzzle where all of the border pieces are done, as are a little over half if the inner pieces. The ones left are all separate from each other, what I have to do now is fill in the gaps.


It is sad but, programming is a work that can be understood only by learning how to do it.

Programming has several different levels of perception and different from different sides.

At low level it is "write very, very detailed instructions for a very, very dumb machine"

At next level it is dealing with complexity. Building new metaphor to simplify work. Like higher mathematics.

From different side its usage of auxiliary technologies like version control, self documented code, project building and testing.

From other side its building "user" interface (not literally, i mean API also UI), predict possible errors (done by user, data or even itself) and correct react on errors.

And finally.

Metaphor for programming is literature. First need to learn the alphabet. But writing a novel at this even not begins.

Not the answer you're looking for? Browse other questions tagged or ask your own question.