1. Hibernate system working great
2. Idiot notices that one of their queries is slow, blames Hibernate
3. Idiot writes their query in raw SQL because hurr durr SQL is faster than Hibernate. (Bonus points for never benchmarking anything. Extra bonus points for switching to SQL and adding an index at the same time, observing this makes it faster, and deciding it's probably the switch to SQL that made the difference)
4. Idiot notices their query is getting results that are inconsistent with recent changes that went via Hibernate.
5. Rather than making any effort to fix this properly, idiot disables all caching in Hibernate. There, I fixed it.
6. Idiot notices that Hibernate queries are now slow (gee, ya think?) and uses this as a reason to migrate all other queries to raw SQL.
Hibernate doesn't save you from having to design a good data model, nor from having to tune it for performance. You can't turn off your brain when using Hibernate, you do still have to figure out which entities own which side of their relationships, and when you get to a scale where performance becomes an issue you do have to spend a bit of time doing performance tuning, just as you do when using SQL. It does genuinely simplify a lot of things and save you from writing a lot of boilerplate. But if you spend a week tuning your SQL query and no time tuning your Hibernate query and use that as your benchmark, no shit the SQL will be faster, and if your first resort whenever you hit a slow query is going to be to bypass Hibernate rather than working with it then yeah you probably shouldn't be using Hibernate in the first place.
So don't use Hibernate if you are not an Hibernate expert?!
And don't expect to mix SQL and Hibernate operations freely in the same code, any more than you'd expect to freely mix e.g. encoding-aware String operations and manipulation of the underlying bytes. It's possible to make good use of the fact that Hibernate is implemented in SQL, CQRS-style: use Hibernate for your "live" operations in your application, use SQL for reporting/aggregation and ad-hoc querying, playing to both their strengths. But don't try to interleave them, especially in the same transaction.
People do this with SQL all the time; they see queries that aren't "fast enough" and they add indexes everywhere, or they "nudge" the query planner the wrong way, or anything else than to accept that maybe their data was wrongly modeled in the first place, or maybe they need to remove indexes, or actually, you know tune the DB.
In their fictional scenario they didn't learn to use hibernate or SQL.
>And the hypothetical developer in it is a woman.
Don't assume their pronouns!
I read the title as referring to the (male) author's career; I understood him to be telling his own story through these hypothetical characters.