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.
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
[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.
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 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.