Software development topics I've changed my mind on

First we have to make sure we're talking about the same thing. There are "active record" ORMs (like Django, Ruby on Rails, etc.), there are "data mapper" ORMs (Hibernate, SQLAlchemy etc.), then there are things like LINQ which are not ORMs at all but merely SQL generators (but you could build an ORM with it if you want).

The arguments against them, I think, are most strong for active record and much less strong for data mapper.

The problem really is complexity, aka coupling. An active record ORM naturally pervades an entire codebase that uses it. People pass around these "objects" that are really just thinly-veiled database rows. But that's all they are. They are at exactly the same abstraction level as the relational database itself, they just look like objects. But in fact they are filled with footguns because accessing those attributes could trigger database requests.

So you'll see business-level code written that has to "know" about the ORM and "know" about N+1 queries and therefore essentially "know" about SQL and the underlying relationships (or, conversely, data access layers that have to "know" about the business logic, e.g. "I know this logic needs to access this bit so I'll prefetch it"). So you're not really gaining anything. These ORMs are the complete opposite of a good software architecture that gives you flexibility and ability to reason about components in isolation.

A good data mapper ORM at least lets you map data from relational tables to real objects. That way you are able to build a new abstraction layer upon which to write business logic etc. A programmer writing those business rules should be able to fully write and test logic with no knowledge of the ORM at all. But in active record projects you'll find each and every developer has to have the full stack in their heads at all times.

I would be interested to know if there are strong reasons to avoid data mapper ORMs too.

> - Ten hours of programming saves one hour of planning...

If the planning is done with 5 or more people in a meeting, there still might be some time savings...

What language are you using that will automatically infer this at compilation time?(*)

If I understand properly what you are suggesting, to make it work with my goto language (OCaml), I believe that I would have to make every function return a polymorphic variant for the error (aka technicaly equivalent to mandatory try blocks and boxed return types). The only time I had to deal with a library doing that it was not pleasant but it was too long ago for me to remember the details, probably related to complex compilation error messages.

(*) looking at your github, I guess Scala?

What I am pointing out is, that one might have an idea how to build a FE in a sane way, but as soon as it becomes a team decision and people don't trust your experience or knowledge, then it often quickly becomes a game of who can represent the next modern hyped thing best, repeating the arguments heard elsewhere, rather than staying with a maintainable solution. If later they need to hire 2 more FE only roles, just in order to maintain the thing they built, they will still not see how silly the decision was and think, that this must be so. Work that could be done by a single person in a few months turns into work done by 3 people working FE only, just to maintain the thing built with the next hyped framework, while all they needed was static content rendering, with tiny sprinkles of JS for some dynamic check boxes.

Besides that, people tend to jump to the extremes in FE. Want some component (in terms of React component)? Immediately they think the whole site(!) has to be a whole React FE, because they like using sledgehammers. Most people don't even think about serving dynamic widgets only on the very few pages/parts of a platform, where they are needed, using frameworks which have this capability for many years now (for example VueJS), and keep the rest of the entirely static website just that. Static. Workable on by any capable software developer or engineer. No. They must build themselves a FE moat! Make things ever more complex, to justify their roles. When you step back and look at what their site actually does, it is extremely laughable, how much time it took to get there and how much time still goes into it, maintaining it.

The examples I wrote about earlier are not just imagined. I have personally witnessed multiple FE people taking 3 weeks to switch out an app router for a pages router (or other way around) in a nextjs project. This is a problem entirely of their own making. 3 weeks for 3 people, that is 9 work weeks. Someone please transfer 2 months of salary onto my account!

I know how to make completely responsive and well accessible websites, more responsive than 99% of websites that call themselves responsive. More responsive than what most FE people cook up with their JS frameworks and non-standard component systems. That is because I care when I build things and I inform myself about how to do things in standard conform ways and use HTML in the way its elements are meant to be semantically used. I have done FE stuff before. In 20 years my site will probably still work just the same, and it will be simple to maintain, because it uses standard HTML and CSS. Meanwhile their frameworks will be long abandoned for the next shiny thing by then. They will rebuild and rebuild and churn and churn.

Still, managements will rather trust a FE(only) dev to build a convoluted mess, because they label it as "modern" and want to jump on the hype trains. FE devs are often like drug dealers figuratively speaking. The incentives are just like that. The more complex a thing they build, the safer their job. Same is true for backend btw. There are lots of grifter out there.

IMO Rust is hard until you gain some intuition, then it becomes MUCH easier.

The real frustrating part is claiming to embrace errors by returns, but then still just panicing all over the place, dependencies piled upon dependencies piled upon dependencies, just about 0 documentation on doing anything asynchronous without external dependencies, important features being kept in unstable for basically ever, one of the highest barriers to contribute to language features, highly questionable leadership processes and the worst of all:

Openly embracing design complexity. When I learned about extension traits for the first time, I thought "That's awesome", only to find not much later crates, that seem to have some features, which I couldn't find the implementation for anywhere. Turns out external crates were pulled in, which then were used to extend anything carrying certain marker-traits from the previous crate. Like WHY?