I fully agree with your sentiment, and it also drives me crazy sometimes.
I wonder if the main problem was all the min maxing interview patterns that rewarded algorithm problem solvers back in the 2010's onwards.
People applied for software engineering jobs because they wanted to play with tech, not because they wanted to solve product problems (which should have a direct correlation with revenue impact)
Then you have the ego boosting blog post era, where everyone wanted to explain how they used Kafka and DDD and functional programming to solve a problem. If you start reading some of those posts, you'll understand that the actual underlying problem was actually not well understood (especially the big picture).
This led the developer down a wild goose chase (willingly), where they end up spending tons of time burning through engineering time, which arguably could be better spent in understanding the domain.
This is not the case for everyone, but the examples are few.
It makes me wonder if the incentives are misaligned, and engineering contributing to revenue ends up not translating to hard cash, promos and bonuses.
In this new AI era, you can see the craftsman style devs going full luddite mode, IMO due to what I've mentioned above. As a craftsman style dev myself. I can only set up the same async job queue pattern that many times. I'm actually enjoying the rubber ducking with the AI more and more. Mostly for digging into the domain and potential approaches for simplification (or even product refinement).
Tbh, I much prefer ORY's API first approach. I looked into Keycloak when I was trying to have a multi-purpose auth server that allowed me to peek into the auth flows.
The sheer complexity of Keycloak's configuration and deployment vs. something like ORY's Hydra was night and day.
And the fact that I could intercept the auth flow through a callback and use their RESTful API to drive it was amazing. No more "package this JAR" and hope that it works. Hydra would run on its own and I don't have to touch it, except when I have to upgrade it.
I believe the difference between ICE degradation and EV degradation is that the EV one actually affects the car's range.
While it is true that your car might consume more oil, and some other component might need replacing, its range, assuming it has been serviced properly, should be similar to what you could get out of it new.
I do wonder if the sum of the costs of getting the ICE car back to mint condition will be the same as getting some cells replaced so you get full range again.
> Are there really enough benefits from uv to justify it as the only option?
The author probably really likes uv, thus the biased instructions.
I also think uv is great, but I wouldn't mention it in the user facing installation instructions. People are used to pip/pipx, thus asking them to install yet another tool might drive potential users away.