Slashdot Mirror
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?
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?
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 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.
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.
I tell them that my type of programming is almost all mathematics. Few programmers use this much math. I look at all kinds of problems and find solutions for them.
I use linear algebra all the time. You might have been exposed to matrix math, using 3x3 and 4x4 matrices, multiplying them together, finding inverses and transposes, working with vectors and dot products and cross products. That's the basic math of the 3D world, much like addition and subtraction are the basics of the math for processing a budget. I do linear algebra on paper and on calculators at my desk, plus I tell the computer to do that stuff. I read technical math research papers about many systems, often two or three per month, and I implement the algorithms they describe.
I look for errors in code and fix them. When people say "this isn't working right", I find the errors and fix them no matter who wrote the buggy code. Sometimes it is very difficult to understand other people's code, sometimes it is like a giant knot that needs to be untangled so it can be understood. When people say "this is running slow", I study the math that they use, I figure out what math can be faster, and I tell the computer to use that math instead.
I work with designers who say "I need a game system that does such-and-such", I figure out a way to make that happen. For example, on {project they would understand} I programmed the computer how to {action they would understand}.
Many times I am given very difficult problems that are studied by mathematicians and scientists, problems that are known to be impossible to solve at speeds games need. That's why the impossible problems, intractable problems, and fast-growing problems are important to study in college. In those cases my job is to figure out other ways to solve the problem that are fast enough to run in microseconds. Usually that means cheating and taking shortcuts. As one example, finding the perfect organization for objects inside a container is very difficult and slow, since the perfect organization requires testing every option. Instead we can cheat by taking the biggest items and stuffing them in the container first, getting smaller and smaller pieces until they are all present. Another is choosing the perfect path which takes a lot of processing, versus cheating and taking the first really good path. It often isn't the perfect solution, but it is good enough for what we need.
//TODO: Think of witty sig statement
Learn the art of self-deprecation and explain your job badly instead.
Examples:
I'm a digital plumber = Network Admin
I'm a janitor/groundskeeper in an imaginary world, I clean up other people's messes and fix crap they break = Sys Admin>
Etc...
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.
"Well, you see, that form is actually an instance of a subclass that inherits from that object which can be stored into that templated array thanks to polymorphism", then no more question from the non-programmer.
if you're looking for a way to justify your existence (as opposed to *genuinely* explaining what it is that you do to an outsider) then i would suggest prefacing that with, "i'm going to start at a high level. i'm then going to go into detail. my ability *to* go into detail is precisely why you employ me rather than someone who can do stuff with a spreadsheet. please feel free to stop me at any time when you have heard enough"
followed by going into detail and not stopping until they tell you to. when they've had enough, you can finish up with, "so do you now appreciate that this is far beyond the skill set of a lay person, to cope with this level of excruciating detail? i deal with it so that you don't have to. it's extremely challenging and tedious in a mind-numbing but extremely rewarding way for me, but only in that it's a massive challenge well achieved. can we please, therefore, in future, keep our conversations to the high-level requirements, and more than that, when i tell you that i *don't know how long something will take* please be patient and trust me to work through it until i know more, okay?"
if on the other hand they *genuinely* wish to know about programming, my favourite way to explain that is as follows:
okay, the idea is, you're going to give me a series of written instructions - a recipe - which i can give to absolutely any person, for them to follow in order to get from one corner of a tiled room to the other, negotiating around obstacles. that person will be BLINDFOLDED so that they only have a sense of touch in any direction of distance equal to ONE tile.
you then give them the following example:
step 1: go forward one step
step 2: if you didn't bash into an obstacle, go to step 1
step 3: go right one step
step 4: if you didn't bash into an obstacle, go to step 3
step 5: are you in the far corner? if yes HURRAH
step 6: repeat from step 1
*we* know what the flaws are in that algorithm... but they won't. so, you LITERALLY get them to walk through it. as in, LITERALLY follow those instructions on a tiled kitchen floor. then you DELIBERATELY place obstacles so that they will get stuck, and ask them, "ok, so now how would you fix that?"
and when they go, "ahhh okaaay i get it. it's step-by-step stuff but you can get into trouble if you don't give the right instructions", then that really is the lightbulb moment for them in *truly* understanding the basics of programming. at *that* point you can explain to them that, unlike that very simple 6-step algorithm you write algorithms of TENS of THOUSANDS OF LINES every few months, and that the linux kernel is what... thirty MILLION lines or something insane, then they'll finally start to really and truly Get It.
if that's your boss they might even actually give you a payrise or at the very least treat you with a little more respect.
[perl...] If they can understand that, they cannot understand anything.
dude. i am a software libre advocate and developer of 25 years experience. i've worked with million-line codebases for two decades. i have done reverse-engineering of ARM and x86 instructions. i've programmed PICs, Z80 and 68000 processors in assembler. i'm going to be working on designing and bringing to market a libre RISC-V SoC... and *I* do not want you to explain perl to me.
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.
File under 'M' for 'Manic ranting'
Porn.. it's why you have it 24/7.
In the case of porn especially, it's "24x7", not "24/7". Try those two formulas in excel, you'll see.
lucm, indeed.
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!
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.
You've gone into the wrong kind of detail. The useful answer generally has the form "X is the general problem that people have which you can relate to in some way from your personal experience. Y is the state of the art. I've improved upon the state of the art in Z."
Thus: "You know how sometimes in Word you type a paragraph, then want to undo it and start again, but you sometimes want to keep a sentence or two from the thing you typed even though you undid it? People usually use copy+paste, if they remember, but it gets hard to keep track and sometimes you accidentally mess things up so you can't redo back to your first draft. You're confused at this stage? -- exactly! :) Well, I've been working on a new way that avoids the pitfalls. It seems to be working, and users have been giving good reports so far. I'm not adding it in Word of course. But who knows? maybe my idea will catch on."
People aren't interested in the technical details of your solution. They're more interested in the general scope of human endeavor, and the conflicts and social dynamics in the research field. So if you meet a researcher or a PhD student, the second question you ask them (after "what's your field?") is "what are the main opposing ideas in the field?"
If you're not advancing the state of the art in any way, and if you're just implementing a solution that someone else has done, again don't talk about the technical details of the implementation. For instance you're doing a back-end database and you're copying some scaling algorithm/implementation from someone else, you can say "Imagine how Amazon must have to process like two hundred million order requests every day? My company also needs to process one hundred million widgets. We're not quite at the same scale as Amazon, but I've been copying some of their techniques too. It's fun. I've learned [incidental social fact about the human endeavor that is software development]".
My day job is doing technical implementation of language features inside a code editor (think autocomplete, signature-help, hover, ...). Even when I'm speaking with my MANAGERS and PEERS I don't talk about the technical side. The first and last thing to talk about is always what's my overall mission? and specifically, what user-facing problems/scenarios am I trying to solve? The technical details is always an afterthought. Successful software engineers are primarily good communicators.
Most people advise trying to dumb down the descriptions to make them more understandable the uninitiated. I don't typically do this, unless I'm dealing with children. When you simplify your descriptions, you are effectively simplifying (in their minds) what it is you do. You make it sound simple, and they suddenly think you're paid to do simple things.
Hit them with the complexity. You probably don't have to force it and go overboard with jargon (no need to activate peoples BS meters). Talk to them as if you were talking to a colleague. This will generally have one of two outcomes:
Yaz
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.
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.
I work for the Department of Redundancy Department.
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
Table-ized A.I.
Fire up a computer
Click on a program, or a game
Then, turn to that non-programmer and say "All these happen because of programmers"
They will still have gobs of clueless questions that will waste even more of your time and leave them still without a clue.
This problem was addressed many years ago. It's not in English (or German, really) but the meaning still comes through.
ACHTUNG!
ALLES TURISTEN UND NONTEKNISCHEN LOOKENPEEPERS!
DAS KOMPUTERMASCHINE IST NICHT FUR DER GEFINGERPOKEN UND MITTENGRABEN!
ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND POPPENCORKEN MIT SPITZENSPARKEN.
IST NICHT FUR GEWERKEN BEI DUMMKOPFEN. DER RUBBERNECKEN SIGHTSEEREN KEEPEN DAS COTTONPICKEN HANDER IN DAS POCKETS MUSS.
ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.
HTH
HAND :)
Strat
Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
"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.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
I describe it as giving instructions to person with absolutely no intuition but will do everything precisely as you say.
Ask them to give you basic instructions on a simple thing like open a door or draw a picture and follow there instructions PRECISELY.
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...