Ask Slashdot: How Can Programmers Explain Their Work To Non-Programmers?

Slashdot reader Grady Martin writes: I disrespect people who describe their work in highfalutin terms... However, describing my own work as "programming solutions to problems" is little more than codifying what just about anyone can perceive through intuition. Case in point: Home for the holidays, I was asked about recent accomplishments and attempted to explain the process of producing compact visualizations of branched undo/redo histories.

Responses ranged from, "Well, duh," to, "I can already do that in Word"...

It's the "duh" that I want to address, because of course an elegant solution seem obvious after the fact: Such is the nature of elegance itself. Does anyone have advice on making elegance sound impressive?
An anonymous Slashdot reader left this suggestion for explaining your work to non-programmers. "Don't. I get sick when I hear the bullshit artists spew crap out of their mouth when they have no idea wtf they're talking about. Especially managers..."

But how about the rest of you? How can programmers explain their work to non-programmers?

Comments

Waste of effort

[inflex]

Don't even bother, waste of effort. If you want to expend energy, then focus it back on yourself and learn to accept that unless you're talking to peers you're always going to be misunderstood, not out of malice or intent, but simply because there's almost always a large collection of context and assumptions that you simply cannot impart on to those who ask the question.

Just keep it simple even and deal with accepting that it'll grind your soul. Same applies to a lot of other fields of work. Try hard and you'll just come off as self-important.

Like a Medical Doctor

[djbckr]

Like a medical doctor would explain a disease to you in layman's terms, you would describe what you do in layman's terms. Since they aren't professional, they wouldn't know anything about visualizing branched undo/redo histories. Use common words in contexts they understand. They won't understand the depth of what you do, but as long as the get the gist, that's all you can hope for.

Re:Like a Medical Doctor

[LesFerg]

Precisely that. If you can't explain the convenience or purpose provided for the end-user of your software in layman's terms, maybe you shouldn't be writing the software.
My relatives are happy to hear something like "I reduced the amount of copying and re-typing that nurses have to do when producing a discharge summary to be sent to the patient's doctor".
Nobody needs to know the complexities of database retrievals and layout crap that goes on in the code. Why would they want to know the details? They only ask what you have been doing to be polite, be polite in response.

Re:Like a Medical Doctor

[Anubis IV]

Agreed. If something is elegant and you don’t have a good way to describe it, don’t. Your goal isn’t to describe why something was hard or get them to the point where they can recognize elegance in a field other than their own. It’s to convey an accomplishment, its results, and the sensations it elicited.

Is the person listening to you a craftsman? They already know what it feels like to make something that’s well-crafted. Are they an engineer or artist? They know what it’s like to struggle through a problem and then find the perfect solution. Even though they can’t recognize elegance in your field, they already know what it is. Put it in familiar terms and focus on what made it personal to you, rather than getting bogged down in technical minutiae. They don’t need to understand how you managed to wrangle spaghetti code or have an understanding of hash tables before they can appreciate that you made everything go a few orders of magnitude faster.

About the only non-techie person I actually try (with limited success) to explain this stuff to is my wife, but that’s because we each make an effort to try understanding what’s going on in the other’s life so that we can share in those victories.

Coding is magic

[ITRambo]

Tell them that coding is magic. You write lines of code that translate into a program that does what you want it to do, every time. It's like casting a spell ,except that coding is real.

My high school physics teacher

[Leuf]

One day in class we were working in groups of four. There were two of us that kind of understood what we were supposed to be doing and two that didn't and the two of us were stuck at how to explain it to the others. So we call the teacher over and the exchange went something like this: Me: "Mr Edwards, Ryan and I understand the problem but we can't explain it to the others." Mr Edwards: "If you can't explain it then you don't understand it. So do you understand it or not?" Me, after thinking for a bit: "Yes." Mr Edwards walks away without another word. And we explained it to them. I hope. Well they graduated at least. That's always stuck with me. When there's a situation where you can't make yourself understood to someone else don't blame them. Look within and ask if you really understand what it is you are trying to convey. If you can't make someone who doesn't do what you do understand why what you do is important then maybe it's you that doesn't really understand why it's important.

Take their argument back a level....

[mark-t]

If they say that they can do that in Word, ask them where they suppose that Word comes from.

There will probably be a few seconds of silence while they let the concept sink in, and then they'll probably get it.

I say its like cooking ...

[perpenso]

I say its like cooking. A program is like a recipe. Its a series of very detailed instructions on how to take a bunch of ingredients and turn them into something else. For the computer program the ingredients may be numbers, letters, pictures, sounds, keystrokes, mouse clicks, ... all sorts of different things; the instruction are how to manipulate those numbers, letters, pictures, sounds, etc. Bugs are like a recipe where something was written down incorrectly or left out and you end up with something that tastes bad.

Yes its dumbed down and oversimplified but people usually get it. Its how the professor explained it on day one of the "Introduction to Computer Programming" class.

Re:Simple

[Tablizer]

No, that's the 1970's.

Now it's more like:

1. Google for the shiny new framework the PHB likes
2. Read the poor instructions and take a brave guess
3. Run the APIs and pray it works on most browsers
4. Throw it out in 6 months for the next shiny toy that catches the PHB's eyes

Re:Need no explanation

[sycodon]

"What do you do?"

"I'm in computers"

"Ahh...ok"

Then the conversation proceeds about other, more important stuff, like what to have for dinner, what time to meet for the movie, trip, etc.

Nobody really wants to know what other people do in detail unless they are considering a career change into that field.