Of course when you're gluing libraries together it is hard to know what they're doing under the hood. There are a lot of libraries with catastrophically stupid design decisions hidden behind the API, and then when everything runs like shit you find yourself having to dig into the libraries until you find the problem.

Anecdotal evidence of "just gluing libraries": I once had users complain about a web-application being slow. As it turns out, it needed 1 second to generate 1KiB of data. They must have been using some sort of slow ORM in the back-end doing 1 DB query per FK.

That's not a slow ORM. That's literally the model of every single ORM I've seen! Sets, who needs them!

I feel that you're driving "we're just gluing libraries" argument to the point of absurd. Do you think that designing database schema and queries that run over it is something that is extremely rare and high-level in modern web development?

It's not rare, yet I find myself redoing this over and over with every job. Web apps that are a HTML table fronting a CRUD back-end and simple database schema are all too common.

I hear you saying "well, that's your fault you keep working at those companies" - and that's not too far from the truth.

Details matter, quality development matters, and experience matters a LOT!