I'll say it again: software developers assist organizational learning. They don't produce things.
Which is what all those factory jobs used to be seen as, too. Much as I dislike Taylor, that's the attitude he was fighting against and he showed it was untrue. Same independently with Ford.
> just rehashing ideas from the past
Back atcha!
So here we are with two entrenched groups of people who "just know" that they're correct but are unable to prove it to one another. What's next?
Whenever I'm presented with a stark dichotomy, I assume there are other branches that people are ignoring.
Obviously (!) it's a bit of both, and mostly it's just like any other job nowadays. Full of its own mysticism, a ton of idiosyncrasies (but everyone has their own interpretation of which parts are exactly constitute the bad ones or the good ones), a huge ecosystem full of variety across many spatial and social dimensions, from code for microcontrollers for 1 dollar toys and fire and forget missile controller code to hyperscale web search engines and ChatGPT, GFW of China, and so on.
Just as every skyscraper, bridge, factory looks similar they are still unique. The sites, the soil, the permitting environment, the people involved almost always result in a similar yet unique mix.
And some similarities can be exploited, standardized, homogenized and treated as uniform or even virtually identical parts. From nuts and bolts to battery manager chips and k8s APIs and whatnot. But some similarities hide the classic devil in their details.
Of course the whole "industry" is in so much flux that it's prone to super embarrassing category errors (picking/selling the wrong tool, wrong platform, wrong experts) that end up costing a lot of money, lead to classic project failure modes (angry client, resentment, death marches, waste of expertise, crisis management meetings, sunk cost fallacies and aborted projects).
This regularly happens in many other jobs too. Again, the more megaprojectish something the more it'll go wrong like almost all megaprojectish things. ( https://en.wikipedia.org/wiki/Unfinished_building ... https://medium.com/@interestingshit/the-8-tallest-abandoned-... )
There are likely very few iron laws of project management, but the overhead due to impedance mismatch between teams, members, and requirements is probably one of them. It simply follows from this that any project that has either new teams or requirements is gambling on this, and as long as folks (up and down the hierarchy) are not up to speed on the domain they'll continue to roll the dice. And depending on the situation and luck we sometimes see mighty implosions (healthcare.gov, cyberpunk 2077, google stadia, and https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_... ) and sometimes it seems like smooth sailing.
Software is codification of knowledge about domain and business process. If you wanna endorse and foster some form or another of cajoling it into making overtly complicated products for a boost on quarter revenues, we're just fundamentally of different world views.
I endorse healthy workplaces, hobbyist endeavors, coding challenges, navigating the murky waters of customer-supplier relationship with integrity, and absolutely despise how awful they are in many-many-many cases, and yes, it's mostly because of the absolutely fucked up incentives, like squeezing short-term revenue.
More domains than you would expect benefit from highly innovative work, and get less benefit from simply writing code as fast as possible.
Infoquake/Jump 225 series had an amazing fun-in-a-dystopian-way visions of this Taylor-ian model of programmers percussively hammering away on code.