What are the craziest misconceptions you’ve heard about programming from people not familiar with it?
As someone who spends time programming, I of course find myself in conversations with people who aren't as familiar with it. It doesn't happen all the time, but these discussions can lead to people coming up with some pretty wild misconceptions about what programming is and what programmers do.
I'm sure many of you have had similar experiences. So, I thought it would be interesting to ask.
That just because I'm a programmer that must mean I'm a master of anything technology related and can totally help out with their niche problems.
"Hey computer guy, how do I search for new channels on my receiver?"
"Hey computer guy, my excel spreadsheet is acting weird"
"My mobile data isn't working. Fix this."
My friend was a programmer and served in the army, people ordered him to go fix a sattelite. He said he has no idea how but they made him try anyways. It didn't work and everyone was disappointed.
You're a hacker (only if you count the shit I program as hacks, being hack jobs)
You can fix printers
You're some sort of super sherlock for guessing the reason behind problems (they'll tell you "my computer is giving me an error", fail to provide further details and fume at your inability to guess what's wrong when they fail to replicate)
That IT subject matter like cybersecurity and admin work is exactly the same as coding,
At least my dad was the one who bore the brunt of that mistake, and now I have a shiny master's degree to show to all the recruiters that still don't give my resume a second glance!
I mean the classic is that you must be "really good at computers" like I'm okay at debugging, just by being methodical, but if you plop me in front of a Windows desktop and ask me to fix your printer; brother, I haven't fucked with any of those 3 things in over a decade.
I would be as a baby, learning everything anew, to solve your problem.
That the business idea, the design, the architecture, and code for the next multimillion dollar app is just sitting in my head waiting for the next guy with enough motivation to extract from me.
I found it useful when explaining programming to lay people to try to put various programming paradigms in everyday terms.
Imperative programming is like a cooking recipe. You need specific ingredients in certain amounts and you need to perform actions in a very specific order, or the recipe won't turn out right.
OOP is like a bicycle. Lots of pieces interconnected and working together, hopefully interchangeable and standardized. It can also be used to explain unit testing to juniors. Clock mechanisms or engines can also work but people tend to relate better to bicycles.
Declarative programming (SQL) works like ordering at the restaurant. You still need to know how restaurants work and about meal courses and how to read the menu etc. but you don't need to know how the sausage was made, only if it's good or not.
That it's mostly sitting behind a computer writing code. More than half my time is spent in the exploration phase: math, research, communication and developing a concept. The actual writing of code is typically less than 1/3.
Also as someone mentioned before, that it's considered something 'dry'. I honestly wouldn't be able to code properly without my intuition. Take for example code smell. I don't know why the code is bad, I just feel that it's off somehow, and I keep chipping away until it feels just right.
Doesn't happen as much, but family and non tech friends would present me to other people that "worked with computers" thinking I could take new job opportunities. They were always wildly unrelated to my field.
I know I know,.. they acted in good faith, and probably could have adapted a bit, but like 30 years ago there was a lot of overlap and systems where somewhat similar, but now somebody trained in Linux kernel maintenance isn't going to learn how to create SharePoint SPFx webparts. Development is very specific now!
The speed at which it takes to make something. We had a vulnerability with a JavaScript library in an old app that I do minimal support on, I said that it only uses like 3 or 4 libraries, so depending on what it is the whole frontend may need to be re-written. IT: "Ok well we have to get that expensed." Sure bro let me just bill the client that is paying for it and error support 20k for new dev time. Nah, the fix is gonna have to be a workaround on your end, we do not have the bandwidth and they don't have the capital.
It has been a long time since I've interacted with people who are largely tech ignorant, but back in the day people always assumed I could hack anything since I'm a website developer. It wasn't uncommon for people to ask me if I can hack Facebook. I mean the answer is "probably not, but maybe", but they think that means furiously typing for 20 seconds and yelling "I'm in!", when the reality would be months worth of snooping and social engineering.
Not programming per se but my sister thinks it's okay to have 300+ Chrome tabs open and just memorize the relative locations of them whenever she needs something. She's lucky she has a beefy computer.
Based on some places I used to work, upper management seemed convinced that the "idea" stage was the hardest and most important part of any project, and that the easy part is planning, gathering requirements, building, testing, changing, and maintaining custom business applications for needlessly complex and ever changing requirements.
I think that non-tech people think that tech just goes. Like you pull it out of a box and turn it on and it just works. They have no idea how much jenk is in everything and how much jenk was eradicated before a user came went anywhere near.
I was at a party explaining that we were finishing up a release trying to decide which bugs were critical to fix. The person that I was talking to was shocked that we would release software with known bugs.
When I explained that all software has bugs, known bugs, he didn't believe me.
As a non-dev (tinker for fun) observer- it sounds like your friends and family think you're working in IT, but their assumptions thereafter are fair. Is that accurate? That the misconception is software dev does not equal IT?
I had some dude here trying to tell me, a mathematician and data scientist who is developing AIs for fun and is a holder of an MA in Visual Effects specializing in procedural design, who has worked on algorithmic video game development, what AIs are or are going to be capable of in procedural/generative/algorithmic game design "because he has played a lot of games" and argued for days with me, cherry-picking everything I wrote attempting to use my words refuting him to support his arguments.
Programming and Software Engineering are related, but distinct fields. Programming is relatively easy, Software Engineering is a bit harder and requires more discipline in my opinion.