Ownership of something you have little control over is a great way to burn yourself out.
If you constantly have to push back against the eager puppy jr dev who’s 1000% sure their vibe slop is prod ready and has proudly told the admiring crowd of stake holders it’s ready to go, wtf kind of life is that? Now the senior/lead is the bad guy and is in the no win scenario.
> If you constantly have to push back against the eager puppy jr dev who’s 1000% sure their vibe slop is prod ready and has proudly told the admiring crowd of stake holders it’s ready to go, wtf kind of life is that? Now the senior/lead is the bad guy and is in the no win scenario
Oh.
You just described my last couple of jobs
I guess that partly explains why I've been miserable and exhausted all the time
If you are joining 12 tables for operational data, you have a design flaw. That’s a reporting query pattern.
Often temp tables, CTEs etc are needed as an immediate fix with redesign as a long term fix. The query planner simply can’t optimize that in a reasonable time or it’s beyond there scope if what it can optimize. Also their solution to “joining in memory” is common.
My DB query rule of thumb:
If the query is hard for you to understand, it’s hard for the planner to understand.
Default to small fast simple queries and pipeline them together.
Sometimes longer and more complex queries run much, much faster. The users complain about "complexity", but when they see the performance comparison they change their minds.
My rule: ORMs first, if there are performance problems it's probably the db structure so don't be afraid of reworking the underlying database. In some cases though SQL gets you the specific thing you need so don't be afraid to use it occasionally in the code (fully parameterized of course and using as much of the ORM as possible for getting things like the table name rather than hardcoding).
Forever wars, the Patriot Act and a financial crises that took years to recover from under another president?
reply