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?
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"
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.
But it pays well. (Shit eating grin.)
Proctologist and programmers need not explain their job.
Porn.. it's why you have it 24/7.
09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
I dumb it down for people who are mildly curious and need to know the gist of what I'm doing. (Coworkers)
I say never mind, I'll handle it for when I don't feel like explaining (also coworkers)
"I make websites*" if the person has no interest.
*I don't actually make websites
"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.
Slashdot, fix the reply notifications... You won't get away with it...
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.
If they can understand that, they cannot understand anything.
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.
I deny that I have not avoided attaining the opposite of that which I do not want.
How does a surgeon explain their job to non surgeons? How does X explain their job to nonX?
Listen how stupid you sound and learn why youre alone. Get over yourself and maybe save your job from being outsourced to someone with better conversational skills.
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
Seriously, it's the best and easiest way to end the conversation
Pleb: "Your partner was telling me you finished some big project at work?"
You: "That's right! I was designing an entirely new way of visualising undo/redo histories"
Pleb: "I can do that in Word already!"
You: "Oh, of course, well you see this company uses a proprietary document system with a complex workflow engine, we ended up having to integrate our history into this system so that changes to multiple documents could be properly tracked by workflow. Of course, this document system is about 15 years old and proved difficult to code against...."
Pleb: "I see, well sounds complicated, glad you're doing it not me! *Guffaws*
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.
Don't say say "I implemented [feature that you take for granted]." Say "It took me X hours of work to add a feature similar to [feature that you take for granted]," and then suddenly their non-coder minds will think "Wow, that's a lot of work! Maybe it's not as simple as I thought."
Just don't include time waiting for builds, checking email, attending meetings, etc. Also, Don't tell time to coders. We'll just laugh at you for spending too much time on something simple.
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."
Rather than describing the intricate details of the task, discuss the problem you're solving abstractly. If possible, describe the business/user case and how what you're working on eventually bubbles up to that level. You need to make it something that they can visualize and potentially relate to. Save the dorky technical details for your co-workers and peers that can appreciate the low level intricacies.
If you're an accountant that just saved a big client a million dollars, you're going to say you saved a client a lot of money. You're not going to tell people the statute numbers from the tax code. You might tell people about how you found a deduction for some odd thing, but that's as deep as you're going to take it.
Coffee goes, code and waste products go out.
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"
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'
The doctor analogy is simply false. You and a doctor are going to share a fairly common set of experiences. You are both humans.
Technical people in the same fields can communicate easily enough since we have a shared common experience. But with non technical people the problem is vastly harder. They don't have experience with even the most basic concepts. I can't think of a common directed acyclic graph example I would share with some random person off the street. We don't even share a language. You can't use graph. That means paper to the layman. The typical mathematical background in America is amazingly poor. I heard a college student complaining about how difficult it was to find the area of a square minus a circle. But these are the people that think my job is easy. Really?
The only way I can explain what I do: My company makes a product. It's not perfect. When you find something broken I fix it when I am not busy creating new buggy features for you.
"How can programmers explain their work to non-programmers?"
The same way people in every other profession explain their job to people who aren't in that profession.
A naval engineer might say "I'm working on reducing that shuddering you feel when a ship hits a wave."
A neuro-surgeon might say "I recently removed a tumour that was causing someone to have vision loss"
A test-pilot might say "I was flying the A380 to ensure everything operates as intended"
A paralegal might say "I was recently looking at cases where mentally impaired people were coerced into admitting to a crime"
You might say "I'm developing a better version of the 'track changes' feature that microsoft word has."
If they ask for more information, well, you've commented your code such that someone that hasn't seen the code before can pick it up and work out how it works right? Just simplify that.
"I'm the white collar version of a factory worker, but instead of putting parts into machines I build the entire assembly line."
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?!?"
Responses ranged from, "Well, duh," to, "I can already do that in Word"...
Say something like: "Here's an analogy for you: You also use bridges and buildings every day, but civil engineers and architects still design new ones. Not everyone gets to work on the equivalent of the Empire State Building or the Golden Gate Bridge of the software world. Someone still has to design the quick-E-mart and the exit 432 overpass, and it's the same in software. Working on a lesser known software project may not be glamorous, but that doesn't mean it's easy."
APK is the Android equivalent of EXE files on Windows, and since Google is using the Play Store as a malware distribution service, individual APK packages that have become self-aware thanks to advanced AI are fighting back by suggesting Slashdot users to update their hosts file to block Google malware. If you use an iPhone or don't use smartphones at all, you can safely ignore any message about APK.
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!
...it's about work organization in general. Any work.
My ex-wife once told me, "I worked at a department store and you are packing bags better than I do." - "I should. I am an engineer, after all."
Block diagrams and flow charts are handy in both business and engineering I assume it works well for software too.
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.
Easy. Just say that you build Rube Goldberg Machines, except they're really tiny and made of electricity, so you have to tell another machine how to put it together for you.
They are like the common tongue in fantasy games.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
You know how in Word or Photoshop, when you undo to a certain point and start editing again, all the original edits after that point get lost? Well I'm working on a smarter undo system where that doesn't happen.
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
Programming is like plumbing. First, it is a trade that takes time to learn, and it might not be immediately obvious why it is a trade one would want to choose. Second, most plumbing work consists of plunging toilets and clearing out drains, and clogged toilets are to fixing someone else's programming mistakes as cleaning out drains is to writing code to talk to an API. Third, most plumbers have to deal with old pipes that are hidden inside of walls and will require some renovation work, but a small portion of plumbers get to work on brand new buildings and get to use the best quality materials. Likewise, most programmers have to fix problems with existing systems and major changes get expensive very quickly, while a few programmers get to create new things with the best technology.
NO, APK is the hosts file equivalent of an ad-blocker, a firewall, a search engine, an anti-virus, a browser and an operating system,
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
"yes, just like a secretary".
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.
And writing a novel is much harder then just reading it. And then pick your favorite book and how you're writing the Math version of that.
OK, lets start with a simple question: Why do we build machines?
Let's say you're digging a ditch in your yard. Would you design and build a backhoe to dig just one ditch? Of course not, you'd grab your sho=vel and "git 'er dun". Now let's say thousands of people need to dig ditches, and they need to dig multiple ditches every day. That's when, and why, we make machines: To make tasks that have to be done over and over faster, easier and cheaper to accomplish.
Software is another way to make a "machine" do the same thing over and over again. In this case, the machine is a computer, which is a special kind of machine that can do many things on one set of hardware. Like a Transformer, but made of bits and bytes. Software is a "story" that tells a computer what kind of thing it is supposed to be, such as helping with taxes or playing a game. Just as stories can be written in English, Spanish or other languages, software "stories" are written using words in languages that computers understand.
If you have a display with a touchscreen, then there is a kind of software will even draw things that look like physical buttons and gages, and can make things happen, just like a physical button. This kind of software makes what is called a "user interface", but you can also call it a panel or any other name used for things with buttons and gages.
The coolest thing about software is what the user interface controls: Anything! Long ago, everyone used to do their taxes on paper. But that's quite a lot of paper when millions of people are filling in the same forms. And other people used to have to read all those millions of tax forms that were sent in A computer lets you run software that imitates the forms, and even helps you avoid mistakes while filling them in. When the form is filled out, it can be sent to another piece of software the government uses to read and process the form. This is called "electronic tax filing", and it is the kind of thing that can be done when computers share information with each other.
Software is special in another way: If it is written to run on a "general purpose" computer, then any general purpose computer can run it! If you have a backhoe but need a front-end loader, you have to go get a completely different machine. But if your computer is running tax software and you want it to run a game, you can do that on the same computer you already have: You don't need to go get a different computer!
Stories for computers are very different than the ones you'll read in a book. Stories for computers actually come to life and become "real", in that the computer will then do what the story, the program, tells it to do. It makes a "general purpose" computer do a very specific thing.
I write stories for computers.
automatically. Ask them how they can do something "in Word" and then ask them if they can leave the room while word does the thing. Every little step of every task needs to be translated into instructions for a machine that can only compare numbers to make decisions. That is "what" we do. If they have a lot of time, you can try explaining "how" we do that, but most will not get it. You're trying to turn a STEM subject into small talk.
"It's the 'duh' I want to address." You're too serious.
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 you need from the database for you or get it to display properly in all modern browsers. Our jobs are rarely glamorous which is why back in the day so many programmers wanted so very much to become game programmers...which today the ideal is big data or AI since the laymen at least believe they understand it enough to be impressed when you tell them what you do. If you're a programmer to impress people then you're in the wrong field. Your highest accomplishments will be met with you shouting with glee at 3am in your study after a 8 hour session trying to finally finish something you've been working on for months...you will have no audience...you will have no glory...you will not make millions but you'll likely make more than most of the people you grew up with. Don't worry about family and friends understanding what you do. If you can find one significant other that doesn't slip into a coma when you explain your day job...be happy with just that alone.
As soon as you turn 30, your career is over!
Programming doesn't pay as much as modeling, but you can be butt ugly if you want.
I ask them how deep of an explanation they want first. Do they want a 50,000 foot view or do they want the 5000 foot view.
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.
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 to anyone's life is certain to be insignificant, at least try to contextualise it in terms that other people can relate to.
So try things like "I spent the past 6 months saving the company $1Mill a year by automating something" or "I made it easier / harder for our government to spy on its citizens. Or "I made the falling snow in [ some obscure little video game ] look slightly more realistic.
If nothing else, this should give you some humility and remind you that in the overall scheme of things your work really doesn't mean much.
Happy christmas!
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
The most colorful explanation I've come up with to what do programmers do is:
I make lots of little bits of light dance.
Enough said
That's why I do embedded programming. I can say that I create devices.
Ayup
Programming is just writing a very detailed set of instructions to perform a task ;) And you can write these instructions in many different languages.
Use the 'Undo redo" explanation to your advantage. Your explanation makes it sound like you're trying to complicate something because you're worried the extent of your work isn't clear without a complicated explanation.
The average person grossly underestimates the work that goes into some of the simplest features..I would come up with an example, Undo/Redo in Word if you must use that example, then explain what actually goes into making that functionality work. IE where the memory goes for your functionality and how you have to manage it, how it requires a pseudo-database to maintain an accurate position within the change timeline, and how the overwrite process works when you do revert a change and begin down a new branch. If your code makes use of more than a single linear branch, use code branches (ala github) or an example like splitting a timeline into multiple timelines everytime a decision is made while having to track each timeline and decision.
You could also simply show your code. I've done that and as people slowly take in the spaghetti, you will usually see the deer in the headlights look as they realize how complicated it is. When they realize it takes a thousand lines of code to make a single feature work and there's thousands of features to program that reference functions called from other functions between multiple files, they will give up. Let them see just how far the rabbit hole truly goes.
Your highest accomplishments will be met with you shouting with glee at 3am in your study after a 8 hour session trying to finally finish something you've been working on for months...you will have no audience...you will have no glory...you will not make millions but you'll likely make more than most of the people you grew up with.
Almost right.
That great accomplishment you make at 3am will be an open source project for which you will never be paid. You will have no glory and likely no job either since you're staying up all night doing your programming hobby instead of working. If you earn any money at all, you will make significantly less than most of the people you grew up with.
Stop telling tall tales about how lucrative it should be. Programming doesn't pay, period.
I give life to unthinking matter to do my bidding.
Or alternatively:
I make machines present data in a way which tells idiotic sales, marketing, and business people what decisions to make.
Either one works really, but why would you bother explaining things to an unthinking plebeian so simple they can't even code? Seems a bit like hooting at the monkeys in the primate cages at the zoo.
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 of the machine. Explaining bug fixes - like the font being upside down half the time - is also easy: the machine is malfunctioning and I need to fix it.
Refactors and architectural redesigns are the hardest to explain: you need to go inside the mechanisms. You can say that the machine's parts are getting too many and too complex, that it makes it hard to maintain the machine (pull it apart, clean and repair the parts, and put it back together). But you can explain that it is precisely this kind of work which makes the machine reliable; it is the kind of work which made Toyota's reputation.
I think other important work - such as ensuring scalability, fault tolerance, correctness, etc. - can be quite easily cast into this sort of mechanical analogy.
What is the point of a person not knowing about something having any influence on how that something has to be accomplished? The mere concept is preposterous. Technical aspects should be exclusively managed by technical people, what means having actual knowledge/interest rather than just formal education; the higher the complexity/experience-level, the more relevant becomes this issue and also the minimum requirements to be considered knowledgeable enough. If everyone focused on what they are good at, everything would work fine and there would be almost no problems.
I have a quite relevant experience dealing with extremely ridiculous concerns of people with virtually no programming knowledge (not even common sense), but seriously thinking that their "ideas" need to be heard. The typical final prize is you bearing the blame for anything going wrong (what is usually provoked by doing what these people told you to do). Other typical outputs of insecure, in-denial, non-knowledgeable people like this are systematic doubts, misinterpretations, lies, unreasonable expectations, pushy/imposing attitudes, misappraised generosity, etc. To not mention having to tolerate horrible assessing methodologies systematically misused by people with no knowledge and blindly believing in their really-saying-nothing outcomes. Even though I am quite happy with all what I have got from all this (the tougher the conditions, the better the learning), I am not willing to go back to that crazy nonsense again. My current policy is to eminently deal with confident and knowledgeable enough individuals perfectly understanding their position within the system.
In summary, my answer to the original question is: if you don't know about something, accept that reality, don't make a fool of yourself/provoke problems/force others to lie to you and act accordingly. If you are a non-technical manager/recruiter/client, you should make an extra effort to have in place a good enough system helping you to compensate your lacks. But don't lie to yourself by thinking that a few generic references or a methodology delivering absolute truths is a replacement for actual knowledge: it is not and it will never be. The best way to assess expert knowledge, mainly when dealing with an as complex field of expertise as programming, is to rely on other expert (either directly or via having created a comprehensive, reliable, adaptable enough methodology). The best way to know the performance of people under certain conditions is to replicate said conditions (e.g., real-work problems/projects under sensible conditions, allowing a wide variety of different outcomes and properly assessing them). The best way to understand any programming work is to have the required knowledge yourself, mainly because of having done it many times before.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Computers do huge numbers of really simple things, really fast. And if you do enough of just the right things in just the right way, you can get surprisingly clever and complicated results.
But computers are DUMB - they have to be told every single thing that they have to do, and then they do exactly what they were told - whether it make sense or not. What I'M good at is (a) telling them how to do the simple stuff so as to end up with the complicated result, and (b) doing it in a way that, mostly, doesn't see them doing something unintended and stupid.
"Word: written by programmers, to make things easier for people who don't program."
It's cool but misleading -start talking about physics and you'll lose them.
Once I had to introduce a bunch of 12-yrs old what programing looks like and it wasn't easy. Images like this helped, but something cooler than videogames and see programming in action.... is to see George Hotz's autonomous car.
I sit in front of a computer and press buttons so that small light bulbs in front of me light up the way I want them to.
A computer is a day laborour. It only does what you tell it to do.
To get it to do what you actually *want* it to do is rather painful.
People get that immediately.
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 name than a full season of Naked and Afraid - It takes a special kind of brain to excel in all 3 of these areas simultaneously and these same people make good engineers.
Tell them you're a typist.
i always say that it's applied mathematics. most are scared already by this start, so i do not have to continue, few will understand so that i do not have to say any more
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?"
Two rules: when a "creative" says "it's just a small matter of programming"
1) go in hard
2) aim for the groin
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
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".
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
Good code is like writing poetry. Itâ(TM)s elegant creative and expressive. Explaining what makes a good program is like trying to explain how to make good art. Most people are happy with that.
Seriously, I spend much of my time writing programming languages and run time engines and visualizations. What I do is far beyond the comfort levels of even communicating with most other programmers.
From what I just read as your example, you spoke but didnâ(TM)t listen and learn. If you have a data structure able to represent a series of transactions in a queryable fashion. As such you have a graph. Graphs have been visualized millions of different ways and whether you use graphviz or Microsoft AGL or similar, itâ(TM)s been done.
You explained to a âoelay manâ what you were doing and he told you that you donâ(TM)t have to, itâ(TM)s been done. Itâ(TM)s very likely that all you need to do is provide a view model to a library that can already do it and provide a style sheet.
I think youâ(TM)re interpreting lack of understanding on your part as lack of understanding on theirs.
"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?
I wished I had this IRL. It would be so useful!
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
"Guys, computers are just stupid machines. They just do what we tell them to do - but don't tell anybody that, people think they are magic, and we make a lot of money from that." With a Greek accent, where "sh" and "ch" are pronounced like "ss", and "j" and soft "g" are pronounced like "dz".
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.
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 lego block. You build those giant parts using the regular lego and you get giant wheels, a giant engine and a when all the giant parts are done you have a giant car.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Its really easy to explain.
"You know the programs that run in computers, phones and things? I write that stuff. Its really easy but takes quite a lot of time and you can't be sloppy."
Anyone that truly knows and understands their field can explain it in layman's terms to the average person.
...I make the stuff inside your phone that shows up like those small color full items on the screen you can touch and they do something.
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?
Stupidity is the root of all evil.
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 etc.
Or to requirements engineering by asking: what do you want? Breakfast or a desert?
Or scaling: do you want a dinner for two with 4 or 5 courses or a full day treatment for a wedding with 200 guests?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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 using the right kind of equipment, ingredients, and methodologies."
VP of engineering?
"I make sure that everyone makes their recipes the same way so that if someone quits we don't have to redo all of their recipes."
CEO?
"I explain to the customer why the banana cake they got was much better than the chocolate cake they ordered."
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 effects on anything, then well, make something up, then find a new job.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
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.
Many have asked me how a computer really works, and why it sometimes breaks down on them the way it does, I keep things real simple and keep out the heavy details and simplify it like this:
A computer is essentially an automated shopping list.
You have a bunch of task you want your family member to do, such as fetching all the groceries, pick up little bobby from school and make sure everything is safe and in place. So let's say that you want to deliver little bobby to his school first, you enter this as your first task, Now in order to make him safe on his way to school - you also have a "shopping list" with tasks to do to ensure that he arrives safely. 1) Has he got all the items he needs to complete a full school day like food, books, pocket money etc. 2) Is he all cleaned up, brushed teeth, well fed and ready to go? 3) Is he firmly seated in the car with the seatbelt firmly on? etc...now you can proceed with the main task...namely to get Bobby safely to school. When that has been done, you may proceed with the shopping list - visiting a nearby grocery store, where you look at a list and go from top to bottom (which is what the CPU - central processing unit does), it simply looks trough this list (which is in the computers case - the memory). The memory contains tasks that needs to be executed exactly like described above, but more technical than our little example - but it's essentially the same task-oriented list of duties to perform.
Now where things can go wrong, is when you interrupt that daily routine (just like in real life), you ask more of your family member, perhaps you want to pick up little Jenny too...which happens to live a lot further away from your place and the school. Now the CPU get's an extra task and have to go perform that task as well. We refer to that as multi-tasking, although you could say the computer has to jump from space A to space B to get both tasks down - this WILL slow down the process as the computer now have to do two tasks at the same time, in your world - this would just be driving the extra distance to pick up Jenny, and slow down the overall progress to execute the entire list of chores.
Now if you put more and more tasks on the family member, things will get cluttered and slow down the CPU (your family member executing the tasks), and things can go wrong, especially if all the duties on the list isn't available (resources in the computer is missing and can cause you to not perform as well as you wanted it to), same with your family member, missed an appointment? Job can't be done, or at least slowed down somewhat. Missed an cooking ingredient, well - you can't really make an Apple Pie without Apples, so that failed and crashed. You could say, if a few necessary files are missing from the computer - the CPU who has been asked to do a specific task - can't do that without those files, just like you can't make an Apple Pie without the Apples.
What this world is coming to - is for you and me to decide.
I only post on my program if hosts help vs. the issue @ hand (or if trolls like you bring it up in a dumb scheme you have).
Unjust downmoderation = censorship & can't affect me. I override it, reposting when it's unable to prove me validly wrong (& it never does) but it affects "your kind" (unidentifiable anonymous trolls) by ME running you DRY of your 'downmodpoints', easily.
Soros however? HE IS PUBLIC ENEMY #1 (funding divisory groups in the USA + worldwide to attempt to sociologically divide the U.S. population vs. one another on several grounds) & known to have thrown HIS OWN KIND under the bus to the Nazi regime as well.
* I have no standing on 'bump stocks' @ all, & I don't talk Vatican conspiracies either - so You now vainly "trying to put words in my mouth I never said" you're doing? Is stupid & weak (like you).
APK
P.S.=> This is the 3rd time I know of you're posting those lies about me - See subject! apk
See subject: Car analogies or StarTrek work explaining APK Hosts File Engine 10++ 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/ - where I give users more speed, security, reliability + anonymity online!
* Imagine a product that gave your car 100 mpg (vs. 20 or so), 1,000 hp (vs. 180 or so), with a better lock system (for security) vs. threats, & a stealth coating (per military tech).
(IF it was StarTrek? I'd say "You now have a deflector shield, cloaking device AND 'warp drive'" as well (for FREE & using what you already HAVE natively that's proven for decades...))
APK
P.S.=> Works for me... apk
An engineer's opinion.
Trying to explain a "technical concept" to someone who is not an expert on the same level as yourself can be a challenge. It really does not matter if the subject is Computer Programming, Municipal Sewage, Environmental regulation, or cooking. Each has specialized language and concepts that are nonsense to "Non Experts".
My approach for written material is to have a member of the target audience proofread the document and then see if the proofreader has understood the intended message. Oral discussions just need some humor to cover over the 10000 foot / weeds points of view.
It takes a programmer to understand how impressive an elegant solution is. Instead, try and convey the joy you found in hitting upon that solution, and the satisfaction of implementing it.
Forget trying to impress people. Elon Musk isn't impressive because of what he says, he's impressive because he makes giant visions happen.
All the technology in the world won't hide your lack of vision, talent, or understanding.
That's the most annoying thing. It's essentially the difference between an electrical engineer and an electrician. Yes, there is some overlap but you don't want me managing your Windows servers and I don't want IT writing my graph search. Yes, I have picked up some things over the years and I can answer and solve some IT problems but really that's not my primary focus. Of course, problem solving is what I do. So yes, I can solve problems.
If anyone cares, I am an EE. No, that's not a glorified electrician. No one thinks a doctor is a glorified pharmacist.
Colleges don't help either. Is computer science part of the math department or part of the engineering department? Or both? Programming is mostly discrete mathematics.
So call yourself a mathematician. People stop asking questions immediately. Math scares most people. When I leave my work bubble, I am really shocked at the lack of mathematical ability.
All this written with a narrow but exact vocabulary.
Léa Gris
The dummies aren't those you are trying to impress with your job...the dummies are those who cannot explain to ordinary people what they do. This stems from 90% of programmers having poor interpersonal skills...just look at how many people here look with disdain at non-programmers who are just "too dumb" to understand how brilliant they are.
And if you really think you are a brilliant programmer, tell them why you are a brilliant programmer vs the idiots you work with, who are also programmers. This should help them see why you see yourself as brilliant.
I just tell people that I help build big brother.
To windopws users? /s
open command line
cd \
del *.*
Answer y to all questions.
Say "it turns out it's hard to automate things people regard as simple. People carry an enormous amount of context and consult it without ever being aware of doing so. Telling a computer how to do what you do as naturally as walking means identifying every neuron, every muscle, getting every detail right, or the whole thing falls over. Once the work's done, once it's understood and specified to the level of detail computers need to operate properly, there's immense value in that,and then somebody wants it to hop or skip or pirouette. The problem is, the technical details bore most people right out of their skulls, and a lot of the tasks better suited for computers than people are _already_ boring. But for people who like code, just like people who like math or politics or whatever, the details of how all the parts are put together, how they all operate together, it's just fascinating. Even some of the tiny little parts are fascinating all on their own when getting the most out of them starts to matter."
As always, all IMO. Insert "I think" everywhere grammatically possible.
I usually say "I sit and type"
I write programs that do the work that humans used to do. Could you now explain what is it that you do for living?
There is of course writing code which embodies the solution to a particular problem in a methodical and systematic manner. But before that, comes what for me is the interesting part: transforming a problem I don't know how to solve into a set of problems that I know how to solve. That's what determines if you can be any good at it. Any reasonably disciplined and literate person can be trained to write code that solves a particular problem, but can you find a problem or problems that embody what needs to be done? That's the creative part.
Now there's a lot more to programming than designing and writing code. There's testing. There's software architecture. There's management. There's all the quite difficult stuff involved with working with *other programmers* and people who aren't programmers. All those things are important and if you don't get them right you fail. But creative problem transformation is the reason to become a programmer; the thing that makes it fun. The rest of that stuff you put up with to get that shot of smug satisfaction you get when you're proved right.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
When someone asks me what software development is like, I respond:
"It's like doing crossword puzzles. Except you don't have all of the clues, sometimes the clues change, sometimes they are wrong, and sometimes there are five answers that work but only one or two is correct. When you are done everyone looks at your results and critiques them. And you only have a set amount of time to do it all in."
My Other Computer Is A Data General Nova III.
You should tell them that you write programs, and then explain that the work you do is similar to that of a writer. A program is similar to a very well structured essay or thesis; with the difference that it instructing the computer much like a cookbook recipe might and it must be written in a language the computer can utilize. Mistakes in clarity lead to undesired output, and often you have to leverage your creativity to get the program written under all of these constraints, on time, and under budget. Most of my time is spend trying to find creative ways to rewrite a program to preserve the desired outputs while removing undesired functionality.
The main problem with discussing something to someone who lacks a similar background is in how it is presented. You must find shared ideas and build upon those. To the layman, the above explanation clearly states that I'm a writer above all other ideas, that I write things in a weird computer language, but they're more or less like "computer recipes" and that mistakes are made, the process is iterative, and I have to use my creativity.
I typically then get the response, "I had no idea that programming could be so creative!" Which, in my opinion is a high compliment, and tells me that I shared the essence of my job.
And then, well I ask them about their job too! It's amazing what you can leverage in your job if you learn what works in other's! :)
Don't bother to explain your work to non-programmers. Even very bright people rarely understand and those blessed with less intelligence never get it.
Mastering the subject requires a degree and/or years of experience.
Circle the wagons and fire inward. Entropy increases without bounds.
I tell people it's like doing math in your head all day long. Every day.
There are two analogies that I use when talking to non-programmers:
I say "I get to invent things every day - its like how you imagine Thomas Edison - I think of what needs to be invented and I create it." Or I simply say "I get to be Thomas Edison every day".
The second is kind of for myself and my fellow programmers: Imagine if the program you are writing was an actual physical machine and you worked in a giant lab that housed it. Each part of the program has a physical manifestation of some kind - gears, levers, control rods, lights, dials, etc, etc, how big and impressive would that machine be? A layman would walk into the lab and say "Wow that's a big complicated machine - did you build that?" and I would say "Yes. Yes, I did."
When explaining what you do as a programmer/developer to a non-technical person, it would make a big difference if you are making stuff pretty and presentable by working the front-end (the sizzle of sausage when placed on a hot pan) or doing all the heavy lifting that happens behind the scenes ("making the sausage", ie, slaughtering animals, grinding up the meat and by-products, injecting into casings, aging, etc) in the back-end.
Non-technical people can understand the front-end (the user-interface) but likely have no understanding of the back-end. People can appreciate paying a bill with a few key presses and a swipe on their smartphone but really don't want to know of all the network protocols, database queries, data compression, and business agreements that went into making it so easy and convenient.
Found the fascist
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)
Any technical or scientific professional who can't explain a project in layman's terms doesn't really understand their own profession and/or doesn't know how to speak fluently.
I make recipes for computers to follow.
I've gotten 'duh' to 'I can already do that in $language' trying to explain my work to CS majors. My wife always gets people in her office that think their Dr. Google skills are a good replacement for her education.
... lawyers explain their work to non-lawyers.
It little behooves the best of us to comment on the rest of us.
For many/most programmers the real answers are:
1. Create needless bloatware to force you to buy faster computers, more memory, and more storage.
2. Build overly simplistic "wizards" that configure things in the short sighted way I want, rather than allowing the configuration which really needs to be done.
3. Re-code memory management or other basic utilities which have been better implemented elsewhere, but those were done elsewhere.
4. Induce cyber security vulnerabilities into code because I am too lazy or fixed in my ways to figure out how to code safely.
5. Refactor the code, just because.
6. Change the interface because then it is different. So what if it worked perfectly fine before and you can't find what used to be obvious.
7. Write my own content management system for the website because I needed a feature that wasn't immediately obviously available and I couldn't comprehend how the system worked to a level I could just add the feature.
...because it usually is, and if you try to explain it in any level of detail, you just get the polite yawns of boredom and disinterest ;)
It starts with knowing the difference between the problem domain (keeping track of a mess) and the solution domain (git rebase).
Of course, some solution domains are themselves problem domains ...
Second tactic.
Have you ever heard of "work to rule"? This was a tactic used in the golden era of unions when they weren't allowed to actually strike, but wanted to have the same effect.
Well, there are two kinds of digital systems: those that work to rule, and those which have been bitten by a rabid dog.
It's what we do.
In the late 70s I started a job as lead VMS system programmer at a large engineering firm. After a few years of dealing with engineers who had one semester of Fortran in college and had a PC at home who thought they knew everything about computers, I put a sign on my door that read "We don't care how the hell you do it at home on your PC".
There is no God, and Dirac is his prophet.
That great accomplishment you make at 3am will be an open source project for which you will never be paid. You will have no glory and likely no job either since you're staying up all night doing your programming hobby instead of working. If you earn any money at all, you will make significantly less than most of the people you grew up with.
Stop telling tall tales about how lucrative it should be. Programming doesn't pay, period.
What are you talking about? Programming doesn't pay? Are you kidding me... There is a huge difference between someone rolling their own code expecting to be paid for it with zero clients and zero marketing funds vs working for a fortune 500 company that absolutely needs you to keep the lights on.
I don't know where you live, but where I live programmers working in the field make way more than the middle income average. Most developers I work with in my day job do work at 3am at least once every few months because those pesky fortune 500 companies don't like you messing around with code in production during the day. However, my comment regarding "your greatest accomplishment" was indeed about coding as a hobby. Because let's face it...most programmers don't get paid to do glamorous work. Which is why the best programmers are still writing code even off the clock. It's because we didn't get into this field just to pay the bills, we're here because it was a hobby first and we still do what interests us most off the clock. Unless of course you work for google and work 80 hour work weeks building the next version of an AI that's going to destroy the world or something....most of us find ways to keep ourselves interested in learning and building things off the clock.
What some programmers don't want to hear though is that programming isn't an easy ticket. You still have to network to get your first job and second and third job. You still have to retrain yourself constantly. If you do write your own code you still have massive marketing costs to find clients...you don't get to become the next Bill Gates just because you tinkered with a few measly thousand lines of code in your spare time. The entry to market is mind boggling difficult than it was just 20 years ago because you have huge monopolies that can easily clone everything you've done and market it to millions more customers in a fraction of the time. I will not lie here, it's incredibly difficult to start off on your own in the field just as it's incredibly difficult to start any business. But to say that Programming doesn't pay is not honest in the least. In comparison to other industries you need far less formal training to become a programmer and you get paid far more. Programming pays, but you don't get an easy button in the business world of selling software just because you're smarter than the average bear.
I recently tried to explain to my mother how the programs I run can be "free." It's hard, from the inside, to appreciate how much what we do looks like magic. I tried to explain that web pages are just like Sudoko: Sudoku and CSS are both constraint solution problems; we just have a language for handling them. All the tech for word processors, browsers, spreadsheets, and databases are, well, "common knowledge" to me. CSS is a constraint algorithm. Word processors are gap buffers and Aho-Corasick algorithms. Spreadsheets are reactive graph traversals in a functional setting. Databases are B+-trees. To me, that's just... stuff I know. To my mom, that knowledge must not only be esoteric, but so esoteric that it must be privileged and expensive. Trying to explain that it's first year textbook stuff no more privileged or protected than long division just goes right past her. So trying to explain that "some guy" wrote a word processor because he thought that would be more fun than model airplanes or bowling league just kinda blows her mind. Oh yeah: all cryptography is nothing but long division; it's just done with numbers so big only computers can do it in a reasonable amount of time. (Not to diss bowling leagues. I was in one once. They're fun!)
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.
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...
--
Mad science! Robots! Underwear! Cute girls! Full comic online! http://www.girlgeniusonline.com/
"I'm a programmer." is about the extent. Any attempts to explain in any detail are pointless because most people have no context for it. If I talk to any family about my work they get bored/confused and file it right away under 'complicated computer stuff' which is the same category for fixing their internet connection or removing some adware from their computers.
And frankly that just makes me annoyed that most people perceive no difference in difficulty or skills required between basic computer repair and software development. It's best to just not discuss it, everyone's happier.
Just whip out your laptop and show them. Or find videos describing what you do.
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...
Randomness is an illusion. You have bifurcation and both branches must be followed so a dimension is spawned for each one and not knowing which dimension you are in makes it random.
From programmer point of view, you have three audiences:
a) The pro - programmer , the guy/girl who knows their stuff and will know when you are lying, or exaggerating.
b) The amateur - "I made a cartoon in flash once" type who understands enough of what you're saying to believe you, but will not be able to tell if you're lying or exaggerating
c) The muggle - You could talk circles around them, and they maybe understood one word.
The muggle is not someone you can communicate with. Give up. If this person is a HR or a Manager, those people are not capable of doing their jobs if your workplace is mostly programmers. If this person is a spouse, relative, or some other person who you see frequently, you owe it to yourself to not lie or exaggerate to them, because they will repeat things you say, word-for-word, to someone who might, and that person will be the one who calls your bluff.
Muggles are going to be the people who don't understand things to the point of making legally dubious choices. Here's a few examples:
a) Open source advocates - Often try to convince people that there is free software to do X, so as a result that person google searches "free photoshop", and downloads a pirate version of photoshop instead of "The Gimp". You have to be exactly precise when you advocate for a free software solution. "The Gimp" sounds like some kind of porn. Horrible name choice. But Inkscape as an alternative to Illustrator is just fine.
b) Pirates - "Hey you can get free TV by running Kodi on an X device" , so your muggle googles "kodi free tv" and downloads a fully-loaded kodi bundle for Windows, without the necessary anonymizing service. So this person then gets notice after notice from their ISP for pirating content, and blames their pirate friend.
c) Hackers/Cheaters of online games - They will, like B above, tell their non-cheating friends how to cheat in some game. They shortly get banned from that game, despite how much work they put into it. Their cheating friends laugh at them for using their real accounts and not laundering their ill gotten gains to their main character.
This is generally how things work in online spaces. The smart people aren't necessarily the ones pulling the strings, rather they share privileged information to people who don't know how to use that information responsibly and as a result they become responsible (not in a legal sense, but in a moral sense) for ruining someones standing in some other social hierarchy.
The amateurs (eg script kiddies), tend to be smart enough to know when what they are doing is wrong, that they can walk away from it, without any scratches. However muggles will always equate "getting something for free" as a rule that always applies, when it may only apply to select situations that a pro or amateur will know how much control they have over. Amateurs are more willing to risk their throw-away proxies, accounts, etc to try and push what they can get away with, and hence that is why things like the "low orbit ion cannon" came into existence. It's pretty easy to convince a bunch of morons on 4chan to embrace chaos, without having to have any skin in the game*.
*I have never personally done this, but the amount of times I've seen people do this is out of petty spite is pretty alarming.
I write abstract machines with math. Then I stop there, the sentence itself needs no more explanation. If they're interested enough to continue the conversation I talk about simplification and efficiency, automation of business processes. Haven't had much a problem with this in years.
Simple, really. . .
Quit acting like Sheldon Cooper and treat us like rational humans!
That's actually a very simple task. Tell them to watch an old movie "Re-Animator" (1985).
The story circles around a guy in white gown who's running with syringe and inserts it in everything that doesn't move and long dead to make it alive.
That's what programmers usually do: they take a dead flesh (read servers and other hardware) and write code for it to make it alive.
My dear old Dad kept asking why I was getting paid? Essentially he had no idea about what software was and why anyone would pay his (not first born) son for it.
At the time I was a SW tech writing device drivers for storage (floppy, HDD) all of this prior to the launch of the PC. Well, during that time I would use engineering samples for some devices to prototype the driver. Then a production board with a production chip would be available for me to finish the little tweaks and send my code to QA.
The lid fell off one of my chips (40 pin package). It failed, big surprise. Not really, cause = engineering sample. I taped it back on the chip with clear tape. The next time he was at my house and asked what I did out came the chip. I flipped up the lid saying, "I make parts of this get hot in very specific patterns."
The subject was never brought up again.
I crystallise thought.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
It's really not that hard. We all did '10: print "Hi, I'm MasterBlaster!âoe; 20: goto 10 back in the day. Everyone gets that in less than 90 seconds.
Just like basic math it takes 5 minutes to explain programming in principle to a regular adult. Unless you're a total dimwitt or just don't want to listen. Those types should actually really be dismissed as too stupid to understand.
You can close by saying that the real work starts "... when you have 150000 files of source code and have to find that feature that needs updating. We have automated tools for this, but it takes understanding, foresight, some technical knowledge and a measurable frustration tolerance. That's why we earn a little more than the regular worker."
Bingo. The job of a programmer explained perfectly sufficiently.
We suffer more in our imagination than in reality. - Seneca
As a software engineer. I like to tell people I drive trains. It's simpler.
Everybody gets trains.
If the programming is just a tool, to build something such as ebay.com or Android Auto, why talk about the tool?
Q: What do you do?
A: I build new features for Facebook.
Q: What do you do?
A: I develop automatic safety systems for cars, such as collision avoidance.
Q: What do you do?
A: I create tools to find and fix security weaknesses in corporate networks.
All of those jobs include programming as a method to do the job, and all are understandable. The last answer is what I do, I build "hacking tools", tools to find security weaknesses. Yes I use various programming languages to do that. I also use RFCs, Wireshark, experience in the field, news sources, etc. The phone programming language is one of many tools that I use to do my job. My job is to build tools that find security holes.
When people ask "what do you do?" I tell them what my project accomplishes, not the technical details of HOW I do it.
Here are the "what do you?" answers for my jobs over the years:
I help large porn sites become easier and more fun to use, so people can find the porn they like quickly, and not have annnoying technical problems like videos that take forever to load.
(I wrote software as a means of getting my job done).
I run a company where we do security for porn sites, to help keep porn sites from getting hacked.
I build new features for the university's online campus.
I build tools to find security problems in corporate networks and tell the company how to fix things to be more secure.
For all of these jobs a I used programming languages, research, an understanding of customer needs and budget. I used email, I used a desk. Programming languages and email were tools I used to do my job, but my job is something else, something that people can understand.
These days, everybody has used or at least seen apps, or used Word or Excel, and they've certainly used Web sites. That makes it easy to tell people that your job is to "build Web sites" or "create apps."
Back in the 80s, when nobody had every seen a computer, my job was "computer operator." It was much, much harder to explain that job back then!
I make mindbogglingly complex things simple enough that, when it works, the average person can do it while complaining about it. When it doesn't work, the average person can't do their jobs at all.
I usually explain it in terms of challenges faced, and problems solved. Basically the same way you would in an interview with a recruiter who isn't a technical person.
This signature has Super Cow Powers
You already got the effect you needed.
Elegance is at its most elegant when it is humble.
Don't bother. It's not worth it.
no really. You can explain your stuff in complex codes, but you could've easily explain it in one or two lines too. This is a little offensive but didn't Einsteins said it before?
This one is for the comment above.
"What do you do?"
"I tell computers to do stuff"
"Ahh...ok... wait really?"
Yea. Nobody really wants to know the details, so you give them something light and simple to stir the conversation. By all means, the point of them asking was to talk about something not the details anyway.
For the article OP, you were asked about "recent accomplishments" and you wanted to explain process of producing compact visualizations of branched undo/redo histories while trying to be elegance and sound impressive. You then need to simply what you actually did. Think what is compact visualizations? What is branched undo/redo histories really is? Last thing is if you want it to be something that sounds impressive, then it needs to be reworded to something that can catch the reader's attention.
"Grady, anything cool you made recent?"
"Well our boss really likes to undo a lot, so I putted an undo button in an undo button, so he can undo while it can undo. I also painted some colors on top in case he can't see it."
When you don't need the details, it's not that hard. You can do it too.
I heard this quote on Babylon 5 many years ago that sticks with me as a rather elegant description of what we do:
We are dreamers, shapers, singers and makers.
We study the mysteries of laser and circuit, holographic demons and invocations of equations.
These are the tools we employ and we know many things...
It has always worked for me - sounds elegant, a little pretentious (I have spent a long time honing my skills) and vague enough to cover most of whqt we do :)
I had to look that up. Sorry, but I can't have approbation for people who use difficult words.
Knitting stitch instructions remind me of C code. I would tell knitters that programming code works in a similar way.
http://www.vogueknitting.com/p...
http://purlavenue.com/king-cha...
If I'm being succinct, that's it.
as a Java programmer, i explain everything with Hamburgers
bun
ingredients
burger patty
ingredients
bun
which goes in a Box after its made
Boxes can be put in a Bag (list/array/etc)
Boxes can also be stacked in a huge Warehouse (database)
etc...
"well how hard is it find this one thing?"
i have to search the millions of Boxes in the Warehouse and match up the id (number) printed on top of it. its gonna take a while.
"why does it take so long to download 100,000 results?"
each Hamburger, which is in a Box, has to be strapped onto the back of a Unicorn. once we get enough Unicorns packed with Boxes, we have to run the herd of Unicorns 100 miles and put all the Boxes in our Warehouse. this has to be repeated until all the Boxes are moved from their Warehouse to ours.
keep it simple. packet loss? Unicorn breaks a leg
Seems to me just like a programmer describing programming (or software). Take it to another level is Linux. I find there are two kinds of people: Those that know Linux and those who do not. The Linux people are experts in all aspects including other operating systems and programming languages. All others have not a clue. I know a little as I did MS-DOS years ago, and that it is a OS where you don't have to continually pay royalties to people in Seattle or Cupertino and the mascot is a penguin.
mfwright@batnet.com
Have you see the movie Tron? It's just like that!
...richie - It is a good day to code.
It like creating a recipe to make cookies, or cake etc.
List the ingredients - variables or classes in programming
Order of mixing the amount of ingredients - the subroutines, loops, if then, etc..
Baking is the whole program put together.
All the program does is to allow the machine to do the same process over and over.
It at least it gets them a bit closer to understanding
You ever see the movie Hackers? Yea, that's me. The fat guy at the security desk taking orders.
Everybody remembers doing word problems in math class. So I tell people that programming is like that, except the problems aren't usually well defined, and the requirements keep changing. But in the end it's breaking down some ideas into a series of logical steps to produce a result.
I'd recommend https://qz.com/849256/how-to-master-a-new-subject/
Casteism
As an old T-shirt once read:
I'm a programmar
I'm a progremmar
I'm a progrommer
I Write Code
-==- Buy a Mac and leave me alone!