Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming

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

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?
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Waste of effort (Score:5, Insightful)

    by inflex ( 123318 ) on Sunday December 17, 2017 @01:18AM (#55753959) Homepage Journal

    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.

    • Maybe I'm more optimistic, but I'll at least try briefly. Yeah, I'll give up if 30 seconds seems like it's not making progress, but fuck it I may as well try, right?

      So the analogy I use is this:

      A programming language is an instrument. I can use it to express ideas, but the instrument itself isn't the focus of my work. It's what I can create with the instrument So if I learn some language that alone doesn't mean much. It's what I do with the instrument (programming anguage) that makes the whole thing wo

      • Why are you comparing a programming language to an instrument?

        Why not just compare it to a normal human language, and say that writing a program is like writing a choose-your-own-adventure novel?

      • Comment removed based on user account deletion
    • I just say "I program videogames", and pretty much leave it at that. There's almost no way to effectively convey what I actually do beyond that. That's enough for 99% of people anyhow. In a way, I'm sort of lucky that the "videogames" part of my job distracts them from the "programming" part.

      Of course, there's always the oft-retorted line of "man, it must be nice to play videogames all day," and I simply smile and lie "Yep, it sure is!"

    • by jrumney ( 197329 )

      Just keep it simple even and deal with...

      I've had this problem with Word for the past few months, can you come around and fix it for me next week.

  • Porn.. it's why you have it 24/7.

  • "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.
    • Re:Simple (Score:5, Interesting)

      by lkcl ( 517947 ) <lkcl@lkcl.net> on Sunday December 17, 2017 @01:47AM (#55754055) Homepage

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

      • Re:Simple (Score:5, Informative)

        by v1 ( 525388 ) on Sunday December 17, 2017 @03:27AM (#55754269) Homepage Journal

        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.

      • Re: (Score:3, Insightful)

        by Tablizer ( 95088 )

        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

      • If layman is in charge of assessing a professional he should invite independent professionals. Period

        That's all there is to it. The "need" to explain something professional to a layman comes from the stupid idea of universal participation in decisions people have no idea about. The stupid bullshit "democracy".

    • "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.

      "Inherits from that object.. inherits what?"

      (tapping toe)

  • by djbckr ( 673156 ) on Sunday December 17, 2017 @01:27AM (#55753991)
    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.
    • by LesFerg ( 452838 ) on Sunday December 17, 2017 @02:23AM (#55754163) Homepage

      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.

      • by Anubis IV ( 1279820 ) on Sunday December 17, 2017 @03:10AM (#55754243)

        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.

      • 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

        I disagree: the whole point of division of labour is that not everyone has to be good at everything.

        You're requiring programmers be god at two quite different jobs, one to program, the other to explain to lay people. Both are skills, and neither are easy. This is why we have companies with management structures and so on, it's so people who

        • You're requiring programmers be god at two quite different jobs, one to program, the other to explain to lay people. Both are skills, and neither are easy.

          If you can't communicate with other humans, you're gonna have a bad time. Most people are terrible at communication in one way or another, though, and it usually boils down to being inconsiderate.

          • If you can't communicate with other humans, you're gonna have a bad time.

            How's that relevant? If you're a junior programmer in a team, you'll be communicating to your cow-orkers and your manager.

            If you want to go far up in your career, then you'll ned to learn to communicate better. Nonetheless the whole idea behind companies is that not everyone has to be good at every job.

            Most people are terrible at communication in one way or another,

            Yep.

            hough, and it usually boils down to being inconsiderate.

            I disagree.

      • by tlhIngan ( 30335 )

        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 a

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

        Mostly agreed, but branched undo/redo is one of those esoteric things which not every user uses or knows how to use, but for the user who does it can be a godsend. Sometimes you do aim a feature at a subset of the userbase.

        Unlike Apple's approach of dumbing everything down so every user can use it, I prefer keeping the basic application easy to use.

    • by Kjella ( 173770 )

      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 think you're confusing a doctor describing your condition - or often not even that, but the practical consequences of your condition - in layman's terms rather than his/her working methods to reach that diagnosis. People rarely scuff at what doctors do and think they can wing it because they recognize the common cold and dumbing that down would only encourage people to think even less of your job. In my experience, the main challenge is trying to think of everything up front. Sure I can sit in Excel and t

  • If they can understand that, they cannot understand anything.

    • by lkcl ( 517947 ) <lkcl@lkcl.net> on Sunday December 17, 2017 @01:50AM (#55754069) Homepage

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

      • by lucm ( 889690 )

        It's all strings and if you turn off the strict mode it rarely crash even if there's a problem. That's Perl in a nutshell. Also, regex.

      • by fisted ( 2295862 )

        programmed [...] in assembler

        But you do program in compiler these days, right?

    • by gweihir ( 88907 )

      Perl has a formal semantics? I think you are confused my friend...

  • Coding is magic (Score:4, Insightful)

    by ITRambo ( 1467509 ) on Sunday December 17, 2017 @01:32AM (#55754003)
    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.
  • Answer: any fucking way they want.
  • Trying to explain developer work to non-developers just isn't worth the trouble, and I mean that with a tinge of sadness after decades of going through the same questions again and again i.e. "WTF are they working on down there, and why do they have such weird work spaces?" My typical response has been to first ask what the questioner would like to do with the information, then tailor the response as best I can in a polite and non-patronizing way to suit that answer. I've also tried to use humour to let them know that "you can't get there from here" and so forth. For some reason I've always gotten laughs from senior execs when I've mentioned that they don't WANT to know what the developers have been up to lately due to persistent rumours that they've become quite handy with rib-spreaders. The execs tend to scurry off chuckling at that point. Good, my plan to get them the hell out of the area worked perfectly.

  • by Frobnicator ( 565869 ) on Sunday December 17, 2017 @01:41AM (#55754037) Journal

    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.

  • by JDShewey ( 1060926 ) on Sunday December 17, 2017 @01:42AM (#55754043)
    Learn the art of self-deprecation and explain your job badly instead. [twitter.com]

    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...
  • by Leuf ( 918654 ) on Sunday December 17, 2017 @01:47AM (#55754051)
    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.
  • I say "You know those computers in movies, where the protagonist types madly on a keyboard, the screen shows lots of columns of numbers scrolling up and then in just a few seconds there's a big 'ACCESS GRANTED' that comes, up, flashing? And then there's expanding circles, a 3D rotation of a thing or a person, and lines of computer code?
    Well, that's exactly what it's like."
  • Coffee goes, code and waste products go out.

  • by zugmeister ( 1050414 ) on Sunday December 17, 2017 @02:01AM (#55754101)
    I've explained it in the past with a car analogy. You get in your car, turn the key and just drive away, right? Everyone understands there is a TON more going on with their car and that they don't understand how it works though it's obvious it does. Explain that just like the car, doing better / faster / more elegantly gets more difficult to accomplish on the back end the simpler it looks to the end user on the front end. This is why it's not really fair to look at a well done piece of code and decide it's not an accomplishment.
  • There's also the diversity of tech jobs, which all tend to look like "the same thing" to most lay people. Heck, just take every Slashdot headline that uses the phrase "IT Workers" as a blanket term for our entire industry and all its subsets.

    I've often found it quite difficult to explain to the lay person that being a "programmer" is different from being "that creepy IT guy who fixes their random Windows problems".

  • I love when my boss says, "This is only going to take an hour right? it's easy... Just do some booleans and loop it with the database"
  • by mark-t ( 151149 ) <markt.nerdflat@com> on Sunday December 17, 2017 @02:07AM (#55754119) Journal

    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.

  • by pepsikid ( 2226416 ) on Sunday December 17, 2017 @02:16AM (#55754139)

    I tell them it's like this: Imagine a gigantic pinball machine, and inside among the bumpers and bells and paddles is a million enraged pussy cats.

    What I do is set up thousands of precise walls and chambers in there, so that when I move the paddles, the cats line up in orderly patterns which represent useful information.

    And if one cat gets out, the pinball machine explodes.

    And I have a boss breathing down my neck every 15 minutes screaming "I simply asked for a clean and simple multilingual economic failure prediction utility! How can it take more than half an hour or so?!?"

  • by darkain ( 749283 ) on Sunday December 17, 2017 @02:21AM (#55754153) Homepage

    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!

  • It's easy (Score:4, Interesting)

    by ljw1004 ( 764174 ) on Sunday December 17, 2017 @02:28AM (#55754177)

    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.

  • by Yaztromo ( 655250 ) on Sunday December 17, 2017 @02:46AM (#55754211) Homepage Journal

    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:

    1. 0. They are genuinely interested and ask relevant follow-up questions and are impressed with your knowledge, or
    2. 1. It goes over their heads, they assume you're some sort of wizard, and they never ever ask you these questions ever again.

    Yaz

  • "yes, just like a secretary".

  • by cstacy ( 534252 ) on Sunday December 17, 2017 @03:44AM (#55754313)
    Most people believe that if something is easy to use (such as programs on their large and small and ubiquitous devices), then it must have been simple to make it so. They do not have any comprehension about how it could be otherwise, and any attempt to make them understand will ultimately fail. My recommendation is to give up, and let them think whatever nonsense they're going to think. You can't win.
  • I hate to break it to you but the majority of what we all do is not special or snow flakey enough to impress anyone that isn't a programmer. If by chance you do build something that would impress the likes of many non programmers...it's highly likely you could just pay someone to explain how awesome your programming skills are to said person 24/7...yes even while they are sleeping. Sometimes you spend days building something that can easily be done in excel because excel isn't going to extract all the data
  • by quietwalker ( 969769 ) <pdughi@gmail.com> on Sunday December 17, 2017 @03:59AM (#55754349)

    I've been at this programming thing for 20 years. I've seen the cycles, I've worked for startups, I've worked for fortune 100 companies, I've been the grunt and the guy writing the script grunts use, I've managed, I've had to deal with every client from the guy who wrote the software I used to write his, to customers who couldn't spell IBM. I know this problem, and it still is a hard one to get right every time.

    Like elegant programming constructs, it's obvious after the fact, so you're not going to be shocked about how to talk to them about it: Use terms that you both understand, in a CONTEXT you both understand.

    99% of the time, that's a business context. "What did you do today?":
      - "I wrote software to produce custom sales brochures so our sales people can personalize their pitch to the client: they're up 10% year over year!"
      - "Ever get an alert on your phone saying someone might be using your credit card? I made it so you can say 'It was me,' by responding to the text message."
      - "You know how a company has to keep track of everyone's payrolls and vacation days? Yeah, that was me."
      - "Our warehouse has to scan thousands of packages, and I simplified their process so it takes a few seconds less. Sounds like nothing, but we can now handle nearly twice as many packages with the same number of people!"

    They're not going to care if you used the flash in the pan framework of the week, or that you optimized a sort, or that you managed a tricky event based distributed caching mechanism, with all the problems cache invalidation requires you to solve. They won't even want to know that you identified a compiler issue and submitted a patch. They don't understand those things.

    See ljw1004's post above, they get it.

    Maybe this will clear things up in a context you're familiar with: You're tasked with integrating a single sign on solution from a vendor. Their spec shows a very basic REST API, and when you discuss it with the vendor's guys, they confirm it's pretty straight forward. So you write it up. But for some reason, the response looks like it's a SOAP response (and aside from you not sending a properly formatted request, it looks like there's an unrelated error that hints at a bad client configuration on their end) and when you talk to the tech on the other end and ask what you need to do to get SSO running with the REST interface, they say, "Oh, the problem is that you're not using a web UI with React and mongo to backend your data," and points you to an example he has running on his own personal desktop. He sends connection info with screenshots showing raw diagnostic screenspam - whipped up for personal debugging obviously. When you can't connect because it's internal to their network he explains that the fix is to migrate it all to the cloud, both your app and his.

    Get the feeling that the guy on the other end has no idea what you asked, what your goal is (to get SSO working with REST), and in fact, he might not only be completely wrong - besides going off in the wrong direction - but that spending time dealing with him is now a liability to your work and workday? Like he's too enamored with his own pet project to actually treat you like a person?

    This is what it's like for non-developers to hear developers speak about development in purely technical terms to non-developers. You don't need to 'bring it down to their level" - you're just speaking the wrong language. There's a crud load in their domain that you're not going to understand either, so you have to use terms, metrics, and values from the perspectives you do share.

  • Nobody cares what your code does. Don't even try to explain the nuts'n'bolts. You would be bored stiff if other people recounted every intricate detail of what they do.

    If you can't suppress the urge to talk "geek" over the holidays (and really: you should - it's only a job, it says nothing about you as a person and that is what your family and real friends care about) then express your work in terms of how you have made things better. Although you won't have changed the world and your total contribution t

  • The most colorful explanation I've come up with to what do programmers do is:
    I make lots of little bits of light dance.
  • Programming is just writing a very detailed set of instructions to perform a task ;) And you can write these instructions in many different languages.
  • What if you describe a program as a simulated machine; not the VM that goes on a hypervisor, but a simulated gearbox in your computer. Making this physical by analogy will go a long way to making the abstract concrete.

    Say you are writing a program that does some typesetting conversions like Pandoc; you can say 'I am making a virtual printing press'. The easiest part to explain is adding new features - like printing in color as well as black and white - because users are always exposed to the functionality o

  • Comment removed based on user account deletion
  • Programmers take ideas and specifications and use mathematical algorithms, logic and creativity to turn them into reality. Just like anything involving math and logic problems, programmers may make mathematical errors, forget steps, make typos or not fully understand (or completely misinterpret) a mathematical algorithm, specification or idea. When that happens, we call them bugs. Most programmers only excel in 2 out of the 3 core areas (based on my own anecdotal evidence) and have more bugs to their na
  • Personally I say it's like building imaginary machines... They can't be seen but they exist inside the machine, and inside my imagination. There's cogs and movement and whatever, but those things aren't really there they are constructs of the computer logic and how I manipulate it.

  • The answer is no. People asking these kinds of questions watch too much Star Trek, and want a Geordi La Forge explanation for something that exists outside TV-land.

    I mean, if we had a working warp engine, would you attempt to explain its mechanics to the lay person? "Umm, see, there's this stuff, called physics...wait, have you heard of chemistry? Well, there's this stuff called chemistry...Actually, have you ever heard of the scientific method?"

  • An anonymous Slashdot reader left this suggestion for explaining your work to non-programmers. "Don't.

  • "Does anyone have advice on making elegance sound impressive?"

    Look around you, does it seem as if anybody would notice elegance if it bit them in the face?

  • by antdude ( 79039 )

    I wished I had this IRL. It would be so useful!

  • Get to the point. Few words as possible.

    I usually explain what the end product is and assume they will ask if they're interested details.

  • by John.Banister ( 1291556 ) * on Sunday December 17, 2017 @07:39AM (#55754735) Homepage
    I seldom get paid for anything that resembles programming, but if someone wants to know more than "writing instructions for computers," I generally point them to a tutorial for a scripting language, preferably one that can be used to automate tasks in a program that they regularly use. After they've learned a little, I say "now imagine writing the program that runs your script or the operating system for the computer that hosts that program." As I've gotten older, I find that I don't put a lot of effort into coming up with simple explanations for people who don't want to make an effort at doing any learning, because if them gaining the understanding isn't worth their effort, then it also isn't worth mine.
  • I always assume whoever asking doesn't know what programming is and wouldn't be able to understand a detailed accurate description. So I tell them It's like lego but instead of wonderful coloured blocks, I'm building structures using words on a computer. Programming is taking a set of vanilla standard blocks and putting them together to build something coherent. I like the Lego car analogy, you want to build a giant car. There is no giant car lego block, there's no giant engine lego block, or giant wheel le
  • Just say "I am a programmer that uses a very fast and highly optimized language that needs advanced skills to master". You will not get anything more across anyways, trying is a waste of time. Even coders in, for example, Java, do not get what C gives you in speed and control, and what, on the other hand, it demands in actual understanding.

  • Do not even bother explaining the technical part. A mechanic or an accountant you socialize with will usually not spend hours detailing his/her job, so do not. What kind of software do you work on? What does it automate? What is the process you company use to build software?
  • I usually use a cooking recipe analogy.

    On top you have the items, like onions, eggs and bacon, this are "kind of variables" or values.
    Then you have your cooking gear, that is more or less a variable (the values get stored and transformed there)

    And now the procedure how to prepare the meal.

    If you can come up with a "correct" cooking recipe you can basically program.

    The rest are details.

    Of course you can jump to multiprocessing by explaining that a cooking pot can only be used by one cook/processor at a time

  • I used to say "I store bits for scientists that they want to get back later" (archive and file systems). Now I say "I help save people's lives" (medical devices).
  • You know, it's not that freaking hard to explain what you do.

    Programmer:

    "Computers are like 4 year olds. You have to tell them exactly what to do. That's what I do, I write recipes for the computer so it knows what to do."

    How about a solutions architect?

    "I try to understand everything that we're trying to bake so I can tell programmers what recipes to write."

    Project manager?

    "I make sure that all the recipes are written on-time so we can publish the cookbook and make the cakes."

    CTO?

    "I make sure that we're us

  • I've been asked this question before, and I'll tell you what I told then: don't try to explain what you do in technical terms, it's no use. Try to describe the applicability and usefulness aspects of what you do, and its effects. In essence, don't try to describe the invisible, instead describe it's effects on its surroundings. Obviously, it's the easiest when you do something connected to something they know about. If what you do has no applicability, it's not useful to anyone or for anything, or it has no
  • As an IT-Service helpdesk guy, I do this all the time. I've also been a teacher large parts of my life so that helps a lot too.

    Curiosity is a natural part of us all, even if you don't have the slightest clue or interest in computers, you want these things to work for you - help supporting your everyday work to make it easier for you to do your job.

    My job as an IT-Service helpdesk support is to make sure you're happy with whatever tool you need to make your job easier and smoother for you and your customers.

  • by LetterRip ( 30937 ) on Sunday December 17, 2017 @12:12PM (#55755479)

    One part solving extremely complicated math word problems. (algorithm creation)
    One part extreme proof reading for a grammar nazi. (debugging)
    One part playing charades or pictionary with the worlds most inept clue giver. (gathering requirements from clients)

  • by ewibble ( 1655195 ) on Sunday December 17, 2017 @02:00PM (#55756069)

    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.

  • by SysKoll ( 48967 ) on Sunday December 17, 2017 @02:12PM (#55756163)

    This is an age-old question. Engineers always seem to be hard-pressed to explain what they are doing all day long.

    This can lead to problems when the people asking the question are non-technical AND have the power to defund projects or departments they don't understand.

    My favorite comic strip on the topic (oldie but goldie): http://revoltingregulations.bl... [blogspot.com]

  • Start them early (Score:4, Informative)

    by lhowaf ( 3348065 ) on Sunday December 17, 2017 @02:50PM (#55756433)
    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...

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Working...