@laurel

> It's very on point, things have only gotten worse and the problems much more pervasive, he even talks about neural nets.

Yeah, buzzwords end up being adopted with this insane fervor, nobody remembers the last thing that fizzled out, nobody notices they're repeating the pattern.

> It reminded of Erlang type rpc functionality as a band aid to the rat's nest problem you mentioned.

Yeah, you notice the "microservices" stuff is just the industry going ass-backwards, right, like that's something you see a lot. CSP is probably the best way to design most software, but it's not as concrete as "Erlang" or "gRPC", people cargo-cult those. Getting a good team that works well together and keeping communication open allows for high productivity, but what people get excited about was "eXtreme Programming", "Agile", "Scrum". Automated testing helps you delegate tedious tasks to the robot and helps you catch bugs, but people get excited about "unit tests", "TravisCI". Having the coders read each other's code is great for transferring knowledge, but this turns into a policy where two other people need to approve a pull request and the result is a backlog and a rubber stamp. The list goes on and on and on. Studying patterns in code and sketching out the patterns in your own codebase helps you reason and communicate about software and helps people read code faster--if you can recognize a sort or you recognize an API adapter or you know what filter/map/reduce looks like, you'll understand faster and you'll be able to recall benefits and drawbacks instead of analyzing every time, it feels almost too obvious to write--but "the design patterns in the GoF's 'Design Patterns' book are the patterns we have to use everywhere, are you even programming if it's not a FactoryFactory?"

Most programmers fail to grasp the concept underlying the thing they're all so excited about, and this means that the number of managers that grasp the underlying concept is near enough to zero to make no difference. Since managers set the policy, the tail wags the dog more often than not.

> I doubt the people pushing for these can manage their own systems the traditional way.

That is probably also a component of it. People that only know how to use Docker tend to build a Docker image to run their tests. Maybe there are people that don't know how to construct a pipeline in the shell without Docker and nix.

You mention C, even on fedi where there tend to be a lot of technical people, and fifty dicks jump in to yell that you shouldn't use C and no one uses C and C sucks and pointers are scary and it's too low-level and manual memory management sucks (and, in recent years, "But none of the mean things I said about C apply if you use Rust!") and BEAM is written in C, Postgres is written in C, Linux is C, the shell is C, nginx is C: *somebody* has to know how to write C. Someone has to know how to write a compiler, someone has to know how to write an interrupt routine, someone has to know how to make an OS, or we end up with people that can only work in feature factories: nobody to do research, nobody to fix the OS, nobody to actually write the code that makes the feature factories function. The equivalent of a yuppie that never considered whether or not the food existed before it was wrapped in plastic and sent to the store, let alone how it got out of the ground and into the plastic to begin with.

> Just whoever is funding a big chunk of OSS projects trying to terraform the landscape into something more centralized and easily controlled.

The VCs are saying coders make too much, because there aren't enough. One way to solve that problem is forcibly lowering the bar by squeezing things into these mechanical processes (whether they fit or not) so that it's a rote exercise and GPT-4 can do most of the work. (This is not going to go well, as you can guess from watching someone try to debug AI-generated code that the robot insists is fine.)

This is probably one of the best things I have read lately: https://www.schneier.com/blog/archives/2024/06/seeing-like-a-data-structure.html . Nobody ever listens to the guy and he is remarkably insightful, which means that everything bad he predicts will happen and every problem he notices will compound.