Sometimes I feel like a musician who can't play live shows. Programming is a pretty cool skill, and a very broad world, but a lot of it happens "off camera"- in your head, in your office, away from spectators.

You can of course talk about programming with other programmers, and there is peer programming, and you do get to create something that you can show to people, but when it comes to explaining to non programmers what is it that you do, or how was your day at work, it's sort of tricky.

How do you get the non programmers in your life to understand what is it that you do?

NOTE: this is not a repeat of Getting non-programmers to understand the development process, because that question was about managing client expectations.

  • That's the nature of the profession: there few tangible rewards for your effort because youre the only one who understands what you do. However knowledge, money are rewarding enough for most.
    – Nobody
    Oct 14, 2010 at 10:18
  • 1
    Related: How do I become more articulate.
    – Adam Lear
    Aug 29, 2011 at 13:19
  • 12
    Be glad you don't write stuff for security. Security is even less demonstrable than anything else. "See, it's doing the same thing it did before, only now it's secure..."
    – Shawn D.
    Sep 26, 2011 at 16:16
  • 2
    Can someone explain to me, which category this question fits in the programmers.stackexchange.com/faq
    – TheTechGuy
    Feb 2, 2012 at 14:28
  • 1
    @Dave it fits the category of questions that were posted when the site was still in beta, if memory serves me right. The rules weren't completely polished back then. Feb 2, 2012 at 16:24

18 Answers 18


Three Words:

dumb it down

Programming is complex. It takes a lot of work to understand it. And the joys of programming are even more subtle.

For me to communicate my successes and such to others (ie family) I have to communicate on a more common level. Compare programming to normal real world things.

(ie an object to a car with a dash board and seats and ....)

It is even better if you know something about your audience because you can use things that they understand that are more complex than normal everyday concepts.

For example, my wife was a school teacher, so I can compare some of my software development processes to teaching processes she had to use. It helps immensely.

But in the end you got to simplify, simplify and simplify some more. And even then, it is hard to get someone to understand how cool a well crafted class with good unit tests is. :)

  • 25
    +1 for "And even then, it is hard to get someone to understand how cool a well crafted class with good unit test is." I have a hard time getting some programmers to understand that.
    – CaffGeek
    Mar 3, 2011 at 15:52

I don't even try. If they aren't tech oriented enough to have at least a basic understanding of programming, I am only going to bore them with the details. Usually I just go with something very high level like "I create web sites" or "I write computer programs to do X"

  • 13
    +1 - I use this method all the time. If I really want them to know how my day went, I'll throw some terms at them and watch that glassy look take over their eyes. Then someone changes the subject. Mar 3, 2011 at 15:01
  • 7
    I've found that people tend to change the subject as soon as I mention computers. Either that or they start complaining about their computer and asking for advice. I guess doctors have the same problem. Mar 3, 2011 at 20:37
  • 3
    @Brian except most doctors fix problems rather than building new systems ;)
    – Armand
    Mar 4, 2011 at 14:50
  • 2
    Yes. The easiest answer is "I create stuff...more specifically, I create a high availability real-time cluster system, for..." - and here they are gone...
    – Sorantis
    Mar 4, 2011 at 14:53
  • This is what I do. Then I wait for the 5 seconds of silence and say "Annnnnd there's that conversation-killer out of the way. So what do you do?"
    – pdr
    Feb 1, 2012 at 22:46

I try to explain it in terms of solving a problem. I just choose to use a computer program to solve the problem. That way you can discuss what you have done in terms of the problem you are trying to solve. Once they understand that, the jump to solving it through programming is not very far and can usually be made by non techie types.


I had my brother Rob ask me about that. (He's an artist and illustrator, like of children's books, museum interiors, stuff like that.)

I tried to explain it by showing him Harry Porter's Relay Computer, because I think it captures the essence of computers and programming in a gut-feel kind of way.

That wasn't what he wanted, and I was kind of flummoxed.

Only later did I realize what the real issue was. I was reminded of this Oscar Wilde quote:

The fact is, that civilisation requires slaves. The Greeks were quite right there. Unless there are slaves to do the ugly, horrible, uninteresting work, culture and contemplation become almost impossible. Human slavery is wrong, insecure, and demoralizing. On mechanical slavery, on the slavery of the machine, the future of the world depends.

What excites me as an engineer is that I am building mechanical slaves. As a kid I wanted to put a dam in the creek, and have a water wheel make electricity, so it could do something for me, while I just watched. In the engine in a car, there is a camshaft. It's actually a primitive program. It opens and closes the valves when I want it to so I don't have to do it.

The world of an artist is completely different. If you listen, with eyes closed, to a rendition of Beethoven's 9th symphony, you are transported. You must give it your complete attention, and when it is finished, you long for it. If you visit Frank LLoyd Wright's masterpiece house Falling Water, you are transported. I honestly don't know how anyone could live in it. Where can you make a mess? It captures you completely. It's an architectural symphony.

Art doesn't do something for you, it does something to you.

I have tried to find the art in what I do. There is beauty in it, if you look, but you have to look. That's what would have connected us.


Tell a story. Don't focus on what you do, but on how you feel when you do it, how you are passionate or bored about it, on relationships with your coworkers.

  • 1
    +1 for concentrating on relationships with co-workers. Everybody can relate to that kind of thing. "I went for lunch with the boss and he was saying ..." is far relatable than "I spent half my day trying to remove race conditions"
    – Andy Hunt
    Feb 2, 2012 at 13:57

My two go-to analogies for this purpose are: a recipe, and a massive bureaucracy. That's what I explained in this QA: 30 minutes to explain programming to a 15 year old

I've used the recipe analogy many times to explain how programming is about writing a rigorous set of instructions that have a tangible and predictable result when followed.

I've only used the bureaucracy analogy a couple times actually, because most people don't really need to understand beyond the recipe analogy, but both times were very illuminating for the person. They seemed to think programming meant total recall of every line of code (eg. "But if you have such a crappy memory, then how can you program a computer?") but really it's about building lots of self-contained modules that work together to accomplish the larger goal. The modules of a program are like the departments in a big company: self-contained units that mostly deal with their own bit of the whole and communicate with other departments through memos.


I think I get the most response when I explain something in terms of the idea behind the code instead of the code itself. I just strip out all the technical jargon, avoid mentioning programming related terms and just talk about the idea and what is actually being done.

For example, I recently tried explaining how a spam filter works. I just said it keeps a record of the words typically found in spam and those not found in spam. The record is built up using known spam and non-spam mails. After that, whenever a new email arrives, we just check how many of the words there look spammy (i.e. occur in our record of spammy words) and how many look non-spammy. If there are too many spammy words, it is probably spam and so gets sent to the spam bin. The non-tech people I was talking to followed the idea quite well.



A lot of times, I don't describe it as a program at all, I try to represent it as a completely different concept with similar interrelationships.

It makes visualizing the program a lot more interesting and sometimes it helps me look at it in a new light.

You don't describe electricity to someone who has never worked with it before by talking about current and voltages do you? Plus, it's fun to describe some concepts as if some ultra aware computer process makes them happen as if by means of magic. A little story imagination doesn't hurt them as the reality of how cold and rational computers really are.


I've answered a similar question in more detail, but the gist is, "Programming is like building a factory or an assembly line."


Many people who have not programmed seem to believe that a programmers spend a lot of time tediously hunting bugs, visually searching thousands of lines of code for an errant comma. So I first assure them that this is not the case, and if it were, I would be completely hopeless at it.

I often compare computer programming to writing a cookbook. A cookbook is a set of instructions for people, while a computer program is a set of instructions for a computer. Some programs are a lot more complex than cookbooks, and programs are modified more frequently, but there is some similarity in the structure. If a cookbook contains seven copies of the instructions for making a sauce, and the recipe has to be changed, someone has to find all those copies and fix them all.

  • It would be a hurting world where you couldn't program your computer to make programming easier ("visually searching . . . for an errant comma").
    – compman
    Feb 2, 2012 at 1:55

I think a good analogy is building a factory. Most people have seen something like "How it's Made" where you see some item getting shuffled through different conveyor belts and machines with hopefully a finished product coming out at the end. I tell people that I build things like that, but instead of being physical factories working on physical items, they are virtual and they work on data. Of course this is not a good analogy for everything kind of programming, but I think if gives a good idea of the complexity and does parallel many kinds of applications.


You kinda can't really share your craft - just headlines about your job with others

However, what you can do is instead of sharing your craft , is share your life with people who are in the same craft as you (:


I usually don't talk about how it's done, but rather features of the work.

I usually stress that it's incredibly complicated, so complicated that no single person could possibly hope to begin to understand in perfect detail exactly what is going on. It would probably require 30 years of studying the various interacting parts (electronics through frameworks), plus about an hour per active line of code, and by that time you'd have to go back to study because the hardware would have changed so much that it's another 10 years grokking the latest version.

The other important part is how rewarding it can be to create something so flexible that thousands, perhaps millions of people could use it to enrich their lives, something unique (at least in detail), and something that you have learned a great deal from.

If nobody has stuffed my mouth with socks at this point, I'd happily demonstrate an application, showing a bit of the complexity involved and flexibility possible.


I tell them that outside of writing symphonies and mathematical theses and novels, programming is the only chance you'll get to engage with tasks/structures with this level of complexity and intricacy. Of course, not saying that a decent web app is a historic masterpiece, but once people realise you get to use your mind at this sort of level every single day, then they 'get it.' Many jobs are worthy and high paid, yet come down to a fairly simple, procedural task repeated again and again and again.

At least, that's how I look at it. I could be wrong.


As a different take to the other 15 answers...

Instead of explaining the details of my work (programming), I try to focus on the solutions that the work solves, i.e. what problems do the systems/software I build actually solve for the user. That's usually a non-programming domain, unless you're writing a compiler or something, in which case you'd have to explain why that's useful.

That way, it makes it easier for people to grasp that it's complex nature and how it relates to the "real world".

As an analogy, as a medieval smith, I'd probably explain (to lady in the local tavern) that I make swords to hack the enemy into pieces, not how I temper steel and hammer on it with a certain angle and force (unless they ask). Hopefully, she'd understand that hacking an enemy into pieces is useful (...) and can be tricky to do (shortage of steel, armored foes, smoky workplace, etc) and thus you gain some appreciation for performing a complex task.

(So, casting anvils would be equivalent to making compilers, and you'd have to explain what they're used for... )


I compare it to building a house, if we lived in a strange universe with exotic particles and anti time:

You have an idea for a really cool house, so you build a rough sketch of what it will look like, and have a general plan of how to proceed. You go to the hardware store and buy some lumber to build the walls, but they keep falling over because the ground is uneven. So you go and buy cement to set the foundation, but the cement won't dry and you can't figure out why. You go back to the hardware store and ask why, but the employee goes catatonic. You go to 8 different hardware stores until one tells you that the cement you used was developed in fall 1989, but you bought your property in the winter of 1989, so they are incompatible, and he sells you the most recent 2013.1.1 cement. You go back to lay the foundation and soon as you do, the cement disappears. This time all employees go catatonic, so you google your house and find that it was once a nuclear testing site. Then you google the effects of nuclear testing on soil and find that it causes free radicals. You google that and start researching electromagnetic radiation, then fermions, then boson, then string theory, and something about a cat. You don't want to give up because you've wasted so much time, so you hit the bottle hard. You come home late and take out your anger on your wife, claiming that she is the reason you can't build the house because her and the kids are taking up all your time...About 3 months in you realize you went from almost finishing the house, to not even knowing why you wanted to build the house in the first place.


I just tell them that what I do is look at what they do for their job and create computer software that will make their job easier.

  • or replace their job, oh noes!!!
    – jhocking
    Sep 26, 2011 at 16:11

Like some of you said, use analogies, that make sense to them. I always try to bring in Google somehow, if my code does something google-like, or show the financial benefits, or how this helps people in some way...

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