
Never attribute to stupidity what is adequately explained by opportunity cost - focodev
https://erikbern.com/2020/03/10/never-attribute-to-stupidity-that-which-is-adequately-explained-by-opportunity-cost.html
======
frandroid
Y'all missing the most important paragraph in the whole article:

 _> I spent many years working in a satellite office. A lot of the time when I
had some deep technical disagreement about something, I'd fly to the main HQ,
and go out for dinner with the other team. I wouldn't even talk about
technology, just about random stuff. Once they knew me, and realize I was a
human (and not a faceless blob), most technical disagreements tended to go
away. People are more likely to assume positive intent and not
malice/stupidity/laziness._

Building relationships is important important to get bug fixed/features built.
Bug prioritization isn't a just a technical nor a business exercise.

Now, I want to hear which company this is that this guy could just "fly to HQ"
(I'm assuming Microsoft Back in the Day) but the geographic gaps aren't always
that large... :P

~~~
schnevets
I've always believed telecommuting needs the remote equivalent of the golf
course. There are certain human elements that cannot be built over a Zoom
call, but do not inherently require a physical presence.

I have never started a company and I was hire #76 at my current place, but if
I were to start something remote, I would find a game or hobby appreciated by
all the founders and make sure that remained a bedrock of our culture.

~~~
hrktb
I see the good intention behind all of these, but also feel there is the other
side that is too often overlooked.

Going on golf courses together, dining with the team etc. are the traditional
recipes to create trust. But it's walking that fine line between personal and
professional life, while also bridging the technical abilities parts and the
personal chemistry parts.

I understand we are all human and personal feelings have an impact on work, it
can't be extracted up to a point. I'm just not sure we should see it as
something that should be perpetuated, moved online or adapted to new
environments if those were by default devoid of these elements.

Basically I'd hope we can prioritise other ways to create trust than building
personal bonds (TBH, being good at one's job for a decent amount of time seems
plenty enough to me)

~~~
sacks2k
"But it's walking that fine line between personal and professional life, while
also bridging the technical abilities parts and the personal chemistry parts."

This is called networking and I don't think it's going away anytime soon.

I'm a consultant and I get along very well with the director of engineering
where I'm working now. When cuts happen, I won't be the first to go. The first
to go will be the people that have no relationship with upper management.

Career advancement isn't all about the job that you do.

"Basically I'd hope we can prioritise other ways to create trust than building
personal bonds (TBH, being good at one's job for a decent amount of time seems
plenty enough to me)"

Being only good at one's job is a great way to keep your current job and
position forever. If that's what you want, it's fine. However, if you want to
get into management or advance, you need to get noticed and build
relationships so your potential can also be noticed.

~~~
WalterBright
> This is called networking and I don't think it's going away anytime soon.

It's never going away. It's human nature to trust and favor the people you
know over those you don't.

A friend of mine who was one of the top salesmen in his outfit would eat his
lunch at his desk to save money. But he wasn't getting promoted, while others
were. He eventually realized the "do lunch" socializing with coworkers was
essential to success.

The idea is to adapt to reality, it's far easier than to try to change human
nature.

------
leoedin
This rings really true with my experience at a startup. Everyone involved in
the product could see it's weaknesses, we just didn't have the manpower to
change them.

I've definitely fallen into the "attribute to malice/stupidity" trap as well,
even when I _know_ that the people responsible are working flat out, if you're
not in the trenches it's so easy to say "but it's so simple! I could do it in
an hour". It's something you have to constantly keep in check.

Honestly, I think the prioritisation thing is absolutely the most important
thing any team or company can do. The person working on a feature almost never
has the overall context to accurately prioritise. The next feature or bug on
whatever they're working on will always feel more important than someone
else's problem. Building a working environment which empowers people to work
towards a common goal - and not just whatever feels important to them in the
moment - is really hard.

~~~
branko_d
On the other hand, the importance of a specific task can sometimes be
adequately assessed only by a narrow group of people, making it difficult to
convey the importance to the larger organization. This usually falls in the
realm of performance, "rare" bugs (especially non-deterministic bugs) and code
quality.

Such "invisible" work may be difficult to justify over "visible" work, yet is
crucial for the long-term quality of the product.

There is a decades-old ERP system (that shall remain unnamed), which to this
day doesn't use foreign keys in its database. The consequences of this are not
immediately visible, but are very serious in the long term, including data
corruption (which I have actually seen with their customer) and (somewhat
counter-intuitively) performance
([https://stackoverflow.com/a/8154375/533120](https://stackoverflow.com/a/8154375/533120)).

Having had a glimpse of their internal culture, I'm not surprised. Any
"foreign key champion" would have been quickly assigned to "more important"
tasks.

------
sfvisser
I don't get the use of the terminology here.

Opportunity cost is the cost associated by not reaping the benefits of an
alternative not being picked. This is a cost from the perspective of the party
making the choice.

So in this story, 'opportunity cost' is not an _explanation_ why something
didn't happen. It is a side effect of something not happening.

You could say the real opportunity cost in this story is the startup teams
having a bunch of unhappy users. The _explanation_ for the missing features is
simply: they did something else.

So better: "Never attribute to stupidity what is adequately explained by
prioritisation"

~~~
jasode
_> So in this story, 'opportunity cost' is not an explanation why something
didn't happen. It is a side effect of something not happening.

>You could say the real opportunity cost in this story is the startup teams
having a bunch of unhappy users. The explanation for the missing features is
simply: they did something else._

The "opportunity cost" _is_ an explanation and your suggestion of shifting the
label "opportunity costs" to apply to something else such as "unhappy users"
is just adding to the misinterpretation.

Let me try to bridge the gap between what the author wrote and your critique
of it...

Think of "explanations" as different levels:

\- level 1: Why is feature X missing? _Because they did something else._

\- level 2: Why did they do something else? _Because of opportunity costs._

\- level 3: Why are there opportunity costs? _Because no company has infinite
budgets, infinite programmers, and infinite time, and therefore, they must
choose what _not_ to work on._

\- level 4: Why does the company not have infinite <anything>? _Because that
's what economists, philosophers, theoretical physicists, etc have observed in
the visible universe so far and that's the framework of reality we're stuck
with for the _practical_ purposes of running a company on Earth._

The level 1 cause & effect is "correct" and "true" but also _trivial, obvious,
and uninteresting_.

The level 2 cause & effect is what the author is trying to explain.

The levels 3 and 4 start getting into metaphysical discussion which might be
intellectually entertaining but hard to apply to real life.

~~~
JoshuaDavid
I think the level 1 explanation isn't entirely trivial, actually. There are
several level 1 hypotheses one might have at that point.

"Why is feature X missing?"

1\. They decided to do something else, and by extension, not this (e.g.
because of opportunity costs)

2\. They decided not to do anything (e.g. because the product is abandoned)

3\. They evaluated the possibility of adding feature X, and decided it doesn't
make sense now, even if the resources to implement it were available (similar
to the above 2 but it means feature X is unlikely to get implemented without
some external thing happening to make it make more sense)

4\. They evaluated the possibility of adding feature X, and decided it doesn't
make sense ever (e.g. because it directly cannibalizes their primary business
model)

If you would like feature X as a customer or potential customer, you may care
which of those is actually the case. If you are responsible for a large chunk
of their revenue, and feature X is make-or-break for you, 1 and 3 are ok
scenarios for you, but in scenarios 2 and 4 you're unlikely to have much luck.
If you are evaluating whether or not to start using this product, scenario 2
may be alarming enough to make you choose another product entirely, and
scenario 4 tells you important things about their business model.

The article is suggesting that people overestimate the probability of
explanations 2, 3, and 4, and that most of the time explanation 1 is the real
one, especially for obvious shortcomings in a product. By the author's
evaluation, explanation 1 is "opportunity cost", explanations 3 and 4 are
"strategic reason", and explanation 2 isn't really covered (though it could
fall under "opportunity cost" if you stretch).

------
Geeflow
I believe this is one of those things that are really hard to understand
unless you have experienced it first hand. Although I always knew how
important prioritization is, I understand it way better since working on my
resource-constrained side project. You often fail to appreciate just how many
obviously good things you can't do because there are even more important
things to do.

Or, to quote Steve Jobs: "People think focus means saying yes to the thing
you’ve got to focus on. But that’s not what it means at all. It means saying
no to the hundred other good ideas that there are."

~~~
nicbou
It's much more obvious with side projects because there is no one else to
blame. You have a complete view of the picture.

I find personal projects very humbling. Even with no one stepping on my toes
or setting unrealistic requirements, I still make dumb mistakes and write
subpar code.

------
mcqueenjordan
This is such an important concept. I was just explaining this to
product/leadership the other week:

"It's not a matter of convincing me we should do this. Obviously, we should.
But we also have a hundred other things that we should do, and a few dozen
things that we need to do. So it's not a discussion of 'should we'; it's a
discussion of understanding how important this thing is in relation to all of
the other things."

Triage and prioritization is hard.

~~~
chris_st
I had a kind of... manipulative co-worker who often tried to work around the
Product Owner. He'd come into my office and ask, "Can we do <some feature>?",
hoping to trigger my inner engineer to be interested in how to solve that
problem.

He finally got tired of me saying, "Given enough time and resources, yes, we
can do pretty much anything! Talk to <Product Owner> about what we SHOULD do."

~~~
tehlike
And probably the moment you do it, he'd take all the credit from you too.

~~~
chris_st
Well, no, he wasn't that much of a jerk, thankfully.

~~~
tehlike
Good. When you said manipulative, it suddenly brought back memories :)

------
bobbytherobot
I learned a lesson about opportunity costs while worked at an IT company. When
I started, the company managed the IT for small companies, most being three to
five people companies. We had full control of decisions so we kept them up-to-
date with the latest best practices. I'm sure there was a bias of the types of
companies who went with us as we charged more than competitors.

We started to gain larger clients. We thought that a 5,000 person company
would be ahead of the 5 person company when it came to technology. Not so.
Here is what we learned: there are political risks for changing technology. A
CTO (these are not tech companies) would wait until people were complaining so
extremely that people would have to feel that changes were good. It all arose
from that bias most people have about change being bad unless it is ten times
better.

~~~
pnutjam
This is so true. I've been in plenty of small business that are trying to do
the best and their constraints are usually based on the ability of early
hires.

Big companies have inertia to deal with for every change and once you get
burned by something trivial that gets blamed for problems, you get very shy
about improvements.

I'm in the process of building a system that had to make alot of compromises
based on existing expectations. It's probably a year away from being where I
want it to be because every change is so slow...

It's frustrating to defend these decisions every time someone comes along and
notices how hard it is to use the system. I have to explain that every part of
the system is broken out currently to find issues and fix them, the end goal
is to stack everything together, but right now all the sausage making is on
display and frankly it's appalling...

(edited for readability) end goal is turning a push button system that had to
be carefully monitored for breakage (while it was running after hours) into a
staged system that gets checked and verified during business hours, but still
fires off after hours.

------
trwhite
You often hear people in engineering teams say something to the effect of "I
can't understand why this was built this way. It's been done stupidly", but
invariably there's some key piece of contextual information that's missing
like, as you say, there simply wasn't enough time.

I also wrote about this recently: [https://timwhite.digital/building-software-
sharing-knowledge](https://timwhite.digital/building-software-sharing-
knowledge)

~~~
jaclaz
Well, the "I can't understand why this was built this way. It's been done
stupidly" can also be a case of Chesterton's Fence:

[https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence](https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence)

~~~
trwhite
Yes, exactly. The point I make in my article is that stupidity isn't at all as
common a reason (for why something's been done a certain way) as we'd like to
think it is. I think the true split is about 80/20.

This is from someone who's had the [dis]pleasure of working on all manner of
steaming piles of rubbish.

If there are any Junior devs reading this, Chesterton's Fence is a great
concept to understand and abide by!

------
runawaybottle
I mostly disagree with this.

At a certain point it becomes inexcusable, and I personally never judge them
as being stupid or lazy, I just attribute it to lack of empathy.

It’s painful for people that have to regularly deal with something not
straightforward (over complex) or just plain old messy (no concern over what
it would be like to revisit the code for anyone, even themselves).

Ruins my day(s), and it takes some mental gymnastics to justify serial
offenses of this kind (e.g We got it done , that’s what matters - great, but
you slowed down velocity at every later stage).

Lastly, I think when you find yourself asking ‘why is it done this way’,
you’ll notice it’s a pattern. It’s never a few pieces here and there where you
can reasonably understand, it’s always endemic throughout the codebase.

So sure, not stupidity, just a pungent disregard for others.

~~~
artsyca
False corporacy makes people do stupid things

A casual company culture is an implied pungent disregard for others and it
comes with its own pungent smell of entitlement too

------
dade_
Some of the worst managers I have worked for didn't understand opportunity
cost. Good idea to test during a job interview or before starting a
partnership. Nothing more maddening than working for an Ahab chasing whales.

~~~
artsyca
Or a canine chasing tails

------
pnw_hazor
In IP law, if I see terrible work product that cost my clients $5-$25K in
waste, I try to be charitable and remind myself that sometimes there is
context that I am not aware of that may have been the cause. Such context may
be client driven immutable deadlines, client-side delays, client-side lack of
communication, and so on.

In reality there probably was incompetence bordering on malpractice by the
prior firm that did the work. But you never know.

If $100Ks (and multiple years) have been wasted, I know it is incompetence
bordering on malpractice. Especially, if the firms that did the bad work have
well known brands.

In professions like law, medicine, or professional engineering prioritizing is
important and useful but providing shoddy work product or corner cutting
should be unacceptable. And often corner cutting is malpractice.

In software development I used to push hard to get people to focus on getting
from A to B efficiently while using an architecture that supports flexibility
rather than over-engineering from the beginning. It seemed to work well.

Though I did run into some managers/directors/VPs that would carefully listen
to a reasonable proposal and ignore it or in one case do the opposite. I
always took that as the sign to move somewhere else. Eventually leading me to
go law school.

------
JanisL
I worked with a company last year that consistently made poor decisions due to
lack of resources, especially time. Sometimes "opportunity cost" was used as
an excuse for a lot of things. Now sure if you have a few different immediate
options and a lack of capacity you will be forced to choose certain options
and ignore others. Scarcity is a real thing and I'm not arguing otherwise. But
the bit that might be classified as stupid was that very little thought was
given to hiring or any form of capacity planning. As such I think just
categorizing this as "opportunity cost" would be missing a very important part
of the bigger picture. People can make decisions that impact the amount of
resources that are available and over a longer period this is especially
important. If you consistently find that you are passing up on profitable
opportunities it shows that you may have a very profitable situation to hire
people, if you don't pay any attention to that you risk making opportunity
costs a self fulfilling prophecy.

~~~
wefarrell
It sounds like they were focusing on the urgent at the expense of the
important: [https://www.eisenhower.me/eisenhower-
matrix/](https://www.eisenhower.me/eisenhower-matrix/)

~~~
ghaff
Yes, although note in the Eisenhower matrix, you "delegate" urgent but less
important tasks. If there's no one to delegate to, that falls apart a bit.
Now, if you're so under-resourced that you're doing nothing but putting out
fires, that's a problem. And you probably have to add resources (of whatever
type including delegating to a third party), fix root causes, or decide that
what you're treating as urgent really isn't.

------
ImaCake
What if the opportunity cost is borne out of malice? I briefly worked as a
quality control microbiologist at a manufacturing facility. We were constantly
understaffed and unable to meet requirements. Heaps of missed opportunity to
improve things. But my feeling was the the company didn't care beyond the
facade of having some micro testing. There was always talk of improving
things, but things never improved.

------
bernulli
This is then made even more frustrating due to the asymmetry when the
opportunity cost for you for not having your problem fixed is much higher than
for the person you are trying to reach.

Or, more succinctly, asking `Who has the problem?' has helped me over the
years to adjust my expectations, because more often than not, it is me who has
the problem, and not the person I am reaching out to.

~~~
tehlike
The part that sucks the most is when opportunity cost of not doing something
is "globally" high, but the other party only optimizes locally for themselves.

You will see, especially at work, when you have something that makes a ton of
money, but people will be uninterested because it doesn't benefit them as
much. At that point you require lots of escalations.

------
csours
> "People love to conclude that something wasn't done because they are stupid,
> or possibly lazy.

This happens about 95% of the time when you don't know a certain person/team."

I used to do plant floor support in a manufacturing plant. Over the radio,
people treated me like an idiot. When I walked out to the plant floor they
treated me like a genius.

------
eythian
I usually find that when I have to go "why is this the way it is, that's
stupid!" I usually end up finding out that there is (sometimes was) some
design constraint I wasn't aware of that caused to to need to be that way, and
actually it makes sense.

~~~
artsyca
Hear hear and that is usually some trifling corporate rumour that keeps
circling and lending itself legitimacy but nobody recognizes as hearsay and
everybody accepts as fact

------
amelius
> I've found that neither malice nor stupidity is the most common reason when
> you don't understand why something is in a certain way. Instead, the root
> cause is probably just that they didn't have time yet.

Ok, let's leave security for later!

~~~
Ma8ee
And even that is sometimes the right decision.

I personally experienced an important delivery being delayed several days
because the tech lead wasn’t happy with the security settings on the database
server. If the DB was accessible outside our internal network or contain any
information that wasn’t publicly available, I would have understood.

~~~
wccrawford
Someone that concerned with security is either fanatical, or they've been
burned by it before.

I also will not sign off on security concerns unless they are correct. I'm
happy to let management override me, but I won't back down and say things are
finished when they aren't.

IMO, your tech lead wasn't the problem here. Their boss was. Their boss
decided that the security was more important than the delivery date, or they
decided that they didn't care enough to get involved, which amounts to the
same thing.

------
harimau777
The issue that I see is that the benefits of implementing something the
"stupid" way (e.g. it's faster or easier to implement) are often enjoyed by
different people than those who have to bear the associated future pain.

~~~
ReactiveJelly
Then it becomes an externality.

Why should sales stop littering when development is the one cleaning up the
highway?

------
firebird84
His statement about bigcos doesn't really jibe with mine. Bigcos are just as
concerned with opportunity cost as startups, at least if they're concerned
about earnings at all or are run well. You will not have headcount to attack
all the problems you have at once, and you'll constantly be chasing
revenue/COGS-R opportunities instead of fixing those UI glitches QA found 2
years ago that have workarounds. The day you stop chasing opportunities is the
day your headcount gets taken away. It's simply not worth paying someone 6
figures to tackle those issues.

~~~
jefftk
Startups will often have many obvious relatively simple things they're not
doing. They're moving very quickly, but they have a small team and have to
ruthlessly prioritize.

A larger company is generally not moving as quickly, and the scale of the
things that they're choosing not to do for opportunity-cost reasons gets much
smaller.

I worked for a money transfer startup at one point. You could use it on
Android and iOS but not on desktop/web. We just hadn't gotten to it yet. If
they're successful but still mobile-app only in five years, though, I'll
expect that it's for reasons like "we looked into web but fraud rates were
much higher" instead of it just being a matter of priorities.

------
7532yahoogmail
There's a lot to like in this article. I like how the author tries to remove
manipulative motions (correspondingly paranoia) from the context in hopes
people can see truer. Nontheless (I am 25+ years in software dev),

\- some 20pct of people think the office is where politics and games are
played. Thus they try to play it better. That's because openness at the office
is usually quite low. Such people are unmoved by push back thinking themselves
the smarter, grayer haired guy. Survivors of this kind of BS actually are
smart, and do have experience with effective but distorting coping skills

\- software should be a formal science. It's not almost all the time

\- the chief issue unaddressed here but smartly lead up to is the management
function: as the normal scenario is that resources are vastly drwafed by
problems what do we say no to?

The management question when examined is complex and when it unfolds to
systemic issues that are chiefly human not technical viz any of the corporate
histories on quality improvement in the 80s/90s esp with company turnarounds.
Ex. Detroit, Xerox, IBM under gerstner. While technical issues remain on the
table, sustained under performance is ultimately rooted in management and
company culture.

------
breischl
I tend to agree with this. I do think that this article (as with most) brushes
far too easily over the tension between tech debt and new features.

It's not uncommon to have a product person (or even team) that spend tons of
time doing analysis to find high-value features. When they show up with some
slick Powerpoint/Excel thing that says "If we build this feature we make
$BIGNUM", it's extremely difficult for some dev (or dev manager) to come up
with an effective counterargument for working on tech debt. Partially because
it's not their main job, and partially because quantifying the impact of tech
debt is extremely difficult. And it's very easy for that to happen every
single planning cycle, even while everyone makes appropriate noises about tech
debt being _super important_ and we're _totally gonna address that_ but we
just can't justify not going for that $BIGNUM cash first!

I wish I had a solution for that - I don't. If anybody else does I'd love to
hear it. :)

------
adrianmonk
I agree, but only partly. Yes, prioritization is likely the explanation for a
lot of things. It's absolutely true that the responsible team cannot do
everything you'd wish.

But, sometimes there's stupidity at a different level. Just because someone is
_making an effort at_ prioritization doesn't mean they are _doing a good job
of_ prioritization.

It's hard to tell from the outside (where you lack the relevant knowledge), so
you're kind of forced into giving them the benefit of the doubt. But sometimes
that internal tools bug which they never get around to fixing is eating up 5
minutes of every employee's time every day for 2 years, and it adds up to a
lot of wasted time, and they should have prioritized it but they didn't. Maybe
because they didn't appreciate what the cost was, or maybe because they had
some bias toward certain kinds of tasks, or maybe some other reason.

------
air7
Wow.

Well put. I'm going to use this. It feels quite true that when analyzing the
behavior of any entity (and to a lesser degree, a person) it's rare to take
_time_ into account. If something wasn't done it's either stupidity, malice,
or something-I-don't-understand. It's refreshing to think that it might just
not have happened yet, and perhaps never will because there will always be
more important things in the pipeline.

So perhaps this idea is a corollary of my own pet aphorism: "Things take way,
way, waaayyy longer than you'd think". Everything seems simple and easy until
you set to actually do it. The kicker is that even looking back on my _own_
work, I sometimes can't understand "What took me so long?!"

------
Rerarom
Like when I asked my friend when we were kids: why don't you have money? And
he said we have money, but it's for something else. I said well what could be
more important than this? (Forgot what "this" was, most probably a new PC.)

------
jessriedel
So the fact that I can't filter my Amazon search by price until I choose one
of multiple plausible "departments" is attributable to Amazon simply not
having enough software engineers to spare for the past decade? I doubt it.

------
artsyca
Inefficiency is a form of stupidity and always being busy is a form of
inefficiency

------
lowdose
If something is more valuable than the opportunity costs it is stupidity not
to pursue it .If something is less valuable than the opportunity cost it is
stupid to mention.

------
maerF0x0
> Never attribute to stupidity that which is adequately explained by
> opportunity cost

"Why didn't we invest in long term issues?" (say virus research...)

Because I can make lots in finance this quarter."

As I understand it humans have (at least) 2 really big problems in rational
thought: 1) A bias towards the short term and 2) unknown unknowns (cue Nassim
Taleb)

Never attribute to higher order stupidity that which can be attributed to
lower order brain functions.

------
k__
_" It might seem obvious the way I put it that opportunity cost is the thing
to blame. But it's not."_

You just have to look at the k8s hype to see that _it 's not_.

In this industry, I often have the feeling that people are fetishizing complex
solutions even if the problem at hand doesn't require them.

But I have to admit, it's not easy to focus on the problem space and really
work out what is needed. Most people do too much or not enough.

------
luckylion
"Listen, we just had better things to do than securing our database and
customer data. It's not that we don't care about the effect this leak has on
the affected individuals, it's just that you can't make money by providing
secure systems, so we prioritized animated emojis higher"

------
bauk
Similarly, people sometimes don't change their opinion on an issue - not
because they're stupid, but because changing your mind about something takes
work, work takes resources, and these resources are already invested in
something you perceive as important.

------
amflare
I think the author is saying "opportunity cost" when he really means "ROI".

------
heymartinadams
Bernhardsson’s razor. Someone should make a Wikipedia entry for that.

------
austincheney
As a JavaScript developer I find the stupidity versus opportunity cost
virtually impossible to distinguish. After all, its how I involuntarily became
a developer in the first place.

I was hired by Travelocity late in 2007 to be a designer. In early 2008 I was
a UI developer and if I wanted to continue to be employed I would have to
figure it out. JavaScript developers, at least competent ones, were nearly
impossible to find, so it made sense for the company to convert me into a
developer instead of struggling to hire somebody who probably couldn't do the
job anyways. Keep in mind this is before jQuery became popular, before
JavaScript became fast, and before massive MVC frameworks did your entire job
for you. Competent JavaScript developers were nearly impossible to find for
what companies were willing to pay. Also, keep in mind that at that time
JavaScript developers earned about half what a Java developer earned but had a
wider distribution of responsibilities to account for. My incompetence that
first year writing logic was a profitable opportunity cost to the employer.

As an aside I can remember Google Web Toolkit (GWT) from that time. It would
compile Java logic to JavaScript, which was great for barely competent Java
developers who couldn't figure out JavaScript. The compiled JavaScript was
garbage though. The logic was a mess that often broke. The people who
generated that code were afraid of it and hid from it leaving nobody to own or
maintain it. It was like some horrid combination of pride, insecurity, hubris,
and negligence rolled up in a ball. Was this an opportunity cost or just
stupid, it is a challenge to distinguish.

Fast forward to modern times and people who write JavaScript are easy to find
and are paid much better. Actual JavaScript developers are still almost as
rare though. Most people who write JavaScript are not actually JavaScript
developers, but rather something like: Angular, React, or Vue developers. They
do not write original code, but supplement a framework. If you put a gun to
these guys heads and told them they had to write an application without their
favorite framework they would happily take the gun from you and shoot
themselves in the face. They have no idea what the DOM is, how to architect
anything, and in many cases writing any original logic scares them to death.

In many cases people who write JavaScript have absolutely no idea what to
write, so they only write browser facing single page applications, because
that is the preference of their pet framework. To be fair some of the React
developers might possess some vague half notion about the DOM, but they would
call it a virtual DOM and get angry when I ask them to find _" virtual DOM"_
in the standard DOM specification. In fact many technical requests that are
explicitly outside the immediate documentation of their favorite pet framework
might make these developers immediately angry (inwardly insecure). This folly
is commonly known and accepted as an opportunity costs so employers set the
expectations very low and don't ask for such things. The stupidity and
incompetence are also distinguished by hiring employers during hiring and
candidate selection whether they are looking for a Node.js developer or a UI
developer even though its all the same language.

The better pay and frequent incompetence are opportunity costs, because
somebody has to write this code. The business need is present and so factors
are adjusted to ensure delivery of necessary business solutions while reducing
hiring risks. It made sense to hire people who could get by just writing
minimal logic over a framework tool, because developers are interchangeable
assets of the business that come and go rapidly in the marketplace. When there
is a shortage of talent you take what you can and ensure it is commonly
replaceable. It should also be stated the conditions for hiring developers
were well in the developers' favor because the business need was clear and
businesses could afford to hire more people while enjoying the longest running
bull market in history.

I suspect, though, this party is over. We now exist in a period of rapid
economic contraction unlike anything in history. Before the recent bull market
developers primarily existed to provide automation. The value of most
developers was in the reduction of expenditure on the employer's internal
operating costs. During this bull market that value became lost as the lines
between automation and product creation frequently blurred. Regardless
employers just knew they need people to write code and could happily afford
it.

COVID has put many developers out of work and economists are anticipating the
economic hardships will continue for about 2 more years. From a business
perspective developers are expensive cost centers. Developers do not add to
the revenue of the employer. They only exist to substitute business expense
for automation. The people who actually generate revenue are called something
like sales, marketing, or merchandising. So, for a hiring manager of a
business struggling to stay afloat why would they hire 12 barely competent
people who write a few lines of code here and there for a framework SPA when
instead they could hire 2 or 3 developers at a slightly hire rate that focus
on automation in general? In other words the safe expectation moving forwards
is to expect that developers will require more from fewer developers or will
find a completely different medium with which to engage their users/clients.
With many developers suddenly out of work talent is no longer rare.

The opportunity costs have drastically changed in response to market
pressures. The employers who will most rapidly adapt their hiring and use of
developers are those under greatest financial pressure. The employers who are
currently safe from market pressures, whether by their essential status or
cash liquidity, will not feel this pressure and will become the new dinosaurs
as they retain older and less efficient ways of shipping products.

~~~
GoToRO
What I realized is that companies that think developers are a cost, are not
really software companies. Maybe they need software, but it's the same way one
needs a visit to the doctor: you go because you have to, you have no passion
for it.

What really upsets developers is the extra work that is generated by managers
that should not manage anything really.

If you are competent enough to be able to create from zero and deliver a
software product/service it seems the only way is to have your own
product/service.

~~~
austincheney
I have never worked for a software company. Most of my career was in travel:
Travelocity/Sabre, Southwest, Orbitz, Expedia and now I work for a bank.
Developers are a cost center even for software companies. It isn’t developers
at Microsoft that are selling Microsoft products.

A software company is one that generates revenue directly from the software
they write. In that regard I do not consider Facebook to be a software
company, their revenue is from advertising and media. They are a software
company the way CNN is. I consider Google to be a software company because
their revenue is from micro-auctions to their search engine.

