
Ask HN: What is a commonly known tech topic that non-techies fail to understand? - gcatalfamo
Targeting managers and executives. If you were to help them make better decisions by explaining to them - in a sort of &quot;ELI5&quot; approach - useful tech topics (e.g. &quot;How cookies work&quot;), what topics would you bring?
======
makecheck
That technical people are not easily swapped like workers in some other
industries.

That technical industries move faster than perhaps any other industry, and in
the time you're taking to ponder a single decision your competitors may have
built an entire product.

------
tbirrell
The TV trope of "I can do this in 4 hours" "You have 1" is not actually how
things work.

~~~
bioapparatus
...but "I need this yesterday."

------
bjourne
Bayesian inference. Someone looking like the suspect was at the murder scene.
But there are millions of people looking like the suspect. The murderer was
wearing a yellow jacket and the suspect has a yellow jacket in his wardrobe.
But there are millions of people owning yellow jackets. If you know how
Bayesian inference works, you know that the suspect is very likely the
murderer.

------
bioapparatus
Assume the topic is a difficult one. The manager / exec you are talking to can
always interrupt and tell you to skip to the more technical.

If you prepare to explain it to a five year old, and you could already explain
it well to someone with domain experience, you can probably explain it to
someone that lies in between.

------
ccdev
That the devil is always in the details. How well you can explain your problem
to someone is not an indication of how easy it is to solve. The difference
between "simple" and "easy".

------
wizzerking
In Windows Development knowledge half life is 3 - 4 years In other words;
every 3- 4 years half of my Windows knowledge becomes obsolete

------
goldenbeet
How data retrieval and storage with DBs works.

How an API works

What tech stack the company uses and why (what benefits are you utilizing)

------
zephyrfalcon
Net neutrality...

------
borplk
A mixed bag here (not all technical but relevant nonetheless),

\- No free lunch

You can't invent outcome out of thin air. Laws of physics apply.

I have been often asked to "achieve outcome that requires a lot of effort" but
somehow ... somehow find a way to do it without any of the effort.

"Bullet proof our backup systems .... in 2 weeks"

The problem with this is there's always some subset of people who will claim
they can do it.

(By diluting the meaning of words such as "bullet proof" low enough to fit the
time-frame)

\- HTML is not photoshop

So many people think a webpage is just a fancy poster.

\- The ability of programmers to solve your problems is directly proportional
to how well the business domain and the problem itself is specified.

Software is the outcome of a process/function. If you don't provide your share
of the input to it it will not magically come about from the ether. The lack
of that information will be obvious in the end product.

If you go to the doctor but are too lazy to talk about which part of your body
hurts ... well don't expect miracles.

\- Not all problems can be universally and indiscriminately broken down into
smaller pieces

Also refer to the mythical man-month. I have seen a lot of people with what I
call "lego-world mentality".

They think anything and everything can be broken down into smaller pieces and
the output collected and stitched back together and they think that has no
effect on anything (quality/timeline/integration).

It's like asking 4 chefs to each cook 1 egg to make one big omelette.

Even things that sometimes look like obvious separate systems/sections only
look like that on the surface.

("You do the X part" .. "I do the Y part")

Again, It's not a lego world.

\- A sequence of next-best moves does not always lead to the absolute best
solution (Local minima/maxima, lazy algorithm to the travelling salesman
problem)

Sometimes you have to zoom out. In practice this means progress doesn't look
like a consistent straight line over time. Sometimes you pull back to be able
to gain more speed and jump further.

Not understanding this results in execs viewing anything that is not strictly
and overtly progress as a waste. Further discouraging a class of important
work and shaking the carrot on the stick for people to pump out features
mindlessly.

\- Everything is much more flimsy than what you are lead to believe

Similar to the lego-world mentality. You see execs applying that (imaginary)
mindset to certain things such as APIs and cross-system integrations.

They think it's like plumbing. You connect the Zendesk pipe over here to this
other pipe and it just all flows nicely. Like a nice clean diagram in your
head.

This perception is created because they only consume the surface-level
marketing material but don't see the ugly crap under the hood.

As a result they under-estimate how fragile software is.

This happens in a lot of domains. For domains that people are not an expert in
they tend to over-estimate how sophisticated/accurate the technology/processes
are.

------
lsiebert
Technical Debt

------
whoami_nr
Bitcoin

