Is this because it's so easy to get started with new tech? I'd be interested to know what people's experiences are like.
Computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understand Shakespeare. What television was able to do was to capture people as they were. So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture.
Basically everyone roots for their favorite team.
Just look at the comments of this thread right now. https://news.ycombinator.com/item?id=20672051
In other words, there are fewer decisions that can be resolved by "option A is the only way to meet constraints x, y, and z simultaneously."
IMO, many combinations are just impossible, just like in mechanical engineering, and even worse, complexity is often much higher.
And if you don't know both sides, you're judging a side that you know less well against a side that you know better. That is, you're judging your experience of X against your opinion of Y. When you're talking to someone who knows Y better than X, you can get fireworks.
Also, I can't help but draw parallels to this other discussion [1] where people claim that veterans in the programming community have to "live" with python because beginners adore the syntax.
I interpreted it as being an issue that there are so many options that being an expert in the relevant two so you can can make an educated decision is uncommon.
This is probably somewhat unique to programming. There are easily more than 25 programming languages that would be important to know trade-offs between in any given programmer's career. And in each, there are competing libraries and frameworks. Woodworking is the only other profession that comes to mind for having so many competing tools.
Do you thoroughly know all the web frameworks? Does anyone? No.
Do you thoroughly know all the major languages? Does anyone? No.
Is that because everyone is incompetent? No.
As an analogy, there was a time when a "renaissance man" could know much of the world's (or at least Europe's) knowledge. Then, in the late 1800s, there was a time when one person could pretty thoroughly know most of physics. Those days are over. Physics is too big. Even the best people know one area deeply, and nearby areas fairly well, and are sort of familiar with the rest of the areas.
So it is with programming. It's too big to really know it all. You can't. Nobody can.
On top of that, there are almost zero objective facts in the field. Faster and smaller are about the only factual statements that can be made about computability. Everything else is an opinion. With no physical truth to disprove wrong opinions, people get accustomed to putting forward passionate arguments without every worrying about being proven wrong.
Finally, it usually takes significant effort to even have a few sample cases to compare opinions when it comes to coding. And usually it's not under scientific controlled environment.
There are no two decades long arguments about "does a ball roll down a hill". Noone is taking a strong opinion against. Before it would get that far, someone would just put a ball on a hill and see the end result. You can't do that with software, the problem space is too large and there is no little bearing to an objective way to measure to results, or they often aren't generally applicable.
There is no definitive evidence.
You can't even prove that rust is definitively better than assembly language.
Hence where no evidence exists, decisions without evidence are made constantly.
You also need to realize that this not baffling. Collecting hard scientific evidence for every freaking detail is incredibally hard and time consuming. It's part of why the medical industry moves so slowly to get medicine out.
In fact any problem with the word design means that you are working on a problem with no definitive evidence pointing to a definitive solution. You are literally designing a possible solution out of thin air. There's a whole segment of people who do this, they are called ux and ui designers and a large portion of the the content they spit out is not evidence based at all.
do people bother to gather the evidence though? like perhaps performance, number of bugs per coding day, quantity and quality of output etc.
At our workplace, it's clear that Cordova hybrid is worse than maintaining both iOS/Swift and Android/Kotlin, in terms of bugs, development time, hiring/retention cost, user experience. But we still do it.
Sometimes it's just that there's less unknowns involved. A bug in Cordova might take a week to fix. A bug in Android or iOS might take 1-2 days. Statistically it would be a no brainer. But bugs are dreadful things and there's the possibility that it could take much longer than usual or go unnoticed.
Agile points are an example of something quantified in a way that isn't meaningful, while performance timing on an algorithm can be meaningful. Many things in programming languages like a for loop vs. recursion cannot be quantified meaningfully.
One of the "crises of mathematics" is that computerized proofs by exhaustion, by applying brute force to find all possibilities, make the field more empirical in nature and hence subject to experimental error.
When pragmatic arguments are used to create a premise like "this design will work best for the software", the question that needs asking is whether all stakeholders can buy into the most core assumptions, and whether all assumptions retain conceptual coherence when taken together. If the UX designer, the developer, the product manager, and the end user agree on a pragmatic theory, and all theories in play align without issue, there isn't an problem as to whether it's "really" true - and with software, the concepts and data are thoroughly enmeshed in pragmatic thinking from the very beginning: numbers are modelled to limited ranges or precisions, strings are encoded according to arbitrary mappings, and so forth.
I would not describe using computer aided proofs as "more empirical in nature". Generally such proofs are held to the same standard as human proofs; there is not any "experimental error" that is not present in normal proof review.
> When pragmatic arguments are used to create a premise like "this design will work best for the software", the question that needs asking is whether all stakeholders can buy into the most core assumptions, and whether all assumptions retain conceptual coherence when taken together. If the UX designer, the developer, the product manager, and the end user agree on a pragmatic theory, and all theories in play align without issue, there isn't an problem as to whether it's "really" true
If your definition of "best" is something measurable in the real world, it doesn't matter what pragmatic theory is agreed upon. Only the systems that "really" achieve the best state are the best. Systems that rely on agreed upon assumptions, but fail to achieve their promises are not relevant.
In simple terms, philosophy and mathematics doesn't matter if it fails to match reality.
In my limited experience, most programmers learn real world software development using the internet.
Some might learn CS theory in formal education, but most real world tools and frameworks are just taught by random people on the internet, or worse, giant corporates that have business interest in promoting the use of X. (Flutter, React, etc.)
Internet cannot possibly provide the scientific temperament and rigour that formal education in say, Physics, is able to provide.
The general consensus among the public seems to be that internet has made CS education highly accessible to the masses. This is of course, very convenient for countries like India, where higher education is often unaffordable and unpractical.
What's not so clear however, is whether this is enough for a real engineering discipline to exist.
I could never afford college, so I took it upon myself to learn whatever I wanted from the Internet. It is astounding how rich the resources for CS are, if you know where to look on the web.
Going back to the topic at hand, I often find myself being defensive and supportive of stacks I use and learnt about. When I dig deeper, I find myself at a lack of words, regarding why I like React or Python. It mostly boils down to "I like x because I know x". I often don't have reasons backed by technical knowledge.
Many times I've not given a certain language/stack a chance just because I heard/read one guy write something negative about it online.
I see my error and will try not to be blindly biased.
Reddit on the other hand seems to dish out fairly crap advice on a regular basis for the subs I subscribe to (not that all Reddit advice is bad, just that bad answers don't get the same down voting that SO answers do).
Because evidence that isolates the effect of the technical choices under discussion from all outside effects and is directly and unambiguously applicable to the context in which it needs to be applied basically doesn't exist for most technical decisions in our industry.
The evidence which is clear tends to be on questions which are distant from business value, the questions the get directly at business value tend to have unclear/ambiguous evidence.
It seems tough to avoid. You need a system, and we don't really have one yet.
I doubt it is only me, but every first attempt with a new language is a fairly crappy effort, as its a learning experience. I prefer to be solving the problem at hand rather than having to google something about the framework every half hour.
A second factor is the difficulty in measuring success. Once a solution is adopted it is very hard to demonstrate the opportunity cost incurred by not selecting a simpler solution. And the costs themselves may not be evident until long after delivery. And since measurement is hard, the lack of data also makes it difficult to articulate effective counter arguments to gratuitous complexity
Once this decision is made at the top, the middle managers and aspirational employees believe in the upper echelon's dogma because their jobs depend on it, and going against the organization might = getting fired.
Conversely, when you look at self organized teams that are just making a hobby project, they tend to go with "we will do whatever we want to do given the reality of the tech landscape".
"Strong opinions come from strong experiences."
But at least one of them is quite valid. We have a lot of garbage in our industry. People perceive that correctly and call it out. Simple as that.
This in combination with a high level of innovation means there is a big risk perceived in taking the time to truely evaluate and test new technologies.
And in the end, because most of this is venture capitalist driven, long term effects are not really important: a road to a rewarding exit (ipo or company purchase) is what really drives most investment decisions.