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

Simple, easy to understand projects

[darkain]

I've been programming computers for 20 years. The majority of my friends cared fuck all for what I was doing... here in 2017, I picked up Arduino and other micro controllers, and started playing with LEDs... Guess what? All of a sudden, one of my projects went viral within one of the communities I'm in. So now that's how I explain what I do. I make little LEDs blink n shit, and everyone loses their fucking minds. My ACTUAL day job is managing a full ecommerce platform, but that's boring and uninteresting, simply because it isn't as easily relatable. But 20 lines of code where someone can press a button and change the colors/patterns of some simple LEDs? Goddamn, everyone loses their minds!

Re:Simple

[v1]

I sort of go along the same lines.

"A computer can follow my instructions quickly and flawlessly, but they have to be VERY simple instructions and they will make NO attempt to deviate from their plan regardless of what comes up. So I have to train something much stupider than your average four-year-old how to reliably perform a complex task, despite the child being both blind and deaf."

They usually either "get it", or insist it can't be that difficult.

If they want more, I usually start going into how the key is to plan for as many different situations as you can, make as few assumptions as possible at the beginning of and throughout the process, and add in as many contingencies as is practical. Imagine a car repair manual where you have to specifically tell the mechanic to shut off the engine and open the hood when describing an air filter change. (or any of a limitless number of other relatable examples)

My specialty is process automation, so I tend to go the extra mile to make my code as autonomous as possible and log the piss out of everything so malfunctions are easily identifiable and can be coded for down the road when Murphy starts getting extra-creative.

Start them early

[lhowaf]

An programmer/author named T.D. (Tyler) Smith wrote a children's book called, "Goodnight Server Room" for kids aged 1 to 5. He said he and his children knew all about firetrucks and front-loaders because that was the sort of subject matter available for a lot of kid's books. He wanted to give his kids a start at understanding what Daddy did all day so he wrote the book.
As for adults...