Yep, working with bundler and npm for a decade plus has made me appreciate these tools more than you can know. I had just recently moved to Python for a project and was delighted to learn that Python had something similar, and indeed uv is more than just a package manager like bundler. It’s like bundler + rvenv/rvm.
Agree with this sentiment - it’s easy to be judgmental about these things, but project-level issues and decisions can be very complicated and engineers often have little to no visibility into them. We’re using Kafka for a gigantic pipeline where IMO any reasonably modern database would suffice (and may even be superior), but our performance requirements are unclear. At some point in the distant future, we may have a significant surge in data quantity and speed, requiring greater throughput and (de)serialization speed, but I am not convinced that Kafka ultimately helps us there. I imagine this is a case where the program leadership was sold a solution which we are now obligated to use. This happens a LOT, and I have seen unnecessary and unused products cost companies millions over the years. For example, my team was doing analysis on replacing our existing Atlassian Data Center with other solutions, and in doing so, we discovered several underused/unused Atlassian plugins for which we are paying very high license fees. At some point, users over the years had requested some functionality for a specific workflow and the plugins were purchased. The people and projects went away or otherwise processes became OBE, but the plugins happily hummed along while the bills were paid.
This is disturbing. There is absolutely no valid reason to make OTA updates to your ECU or other essential components. Never.
Ever. If there ever was a need to do such an update, it should be made in the dealership by a professional who can roll it back if there’s a problem. Automakers have become far too complacent while at the same time over-automating everything and profiteering by turning things into a subscription model. This is why so many car enthusiasts (myself included) prefer older cars.
Love the design and concept of a tiny planet - reminds me of Super Mario Galaxy in that way. Definitely needs a tutorial or a short “How to Play” dialog or page.
Second this. Pretty much standard/intuitive controls, it was fun discovering what the game was about while captivated by the beautiful music and graphics.
All text should be selectable (and therefore readable) to support accessibility tools - at least if you’re app or site is Section 508 compliant or similar.
About a decade ago, I was the sole developer for a special project. The code took 2 weeks to complete (a very simple Java servlet + JDBC app) but an entire year to actually deliver due to indecisive leadership, politics, and extremely overzealous security policies. By the time it was successfully deployed to prod, I had been chewed out by management countless times, who usually asked questions like “how on Earth can it take so long to do this one simple thing??”.
I saw two projects in a row in a German Fintech (the one that has AI in its name that forbids usage of AI) go exactly the same way.
Two/three months to code everything ("It's maximum priority!"), about four to QA, and then about a year to deploy to individual country services by ops team.
During test and deploy phases, the developers were just twiddling thumbs because ops refused to allow them access and product refused to take in new projects due to possibility of developers having to go back to code.
It took the CEO to intervene and investigate the issues, and the CTO's college best friend that was running DevOps was demoted.
I see that a lot too. Something is super urgent, you work your ass off to deliver and then somebody sits on it for months before actually shipping. If ever.
I don’t actually mind (because I won’t work my ass off). So when enthusiasm fizzle out, I just take a lot of notes (to onboard myself quickly) and shelve the project.
IME, in most cases, it's the dickhead's fault in the first place.
This is often a CTO putting pressure on a dev manager when the bottleneck is ops, or product, or putting pressure on product when the bottleneck is dev.
The normal rationalization is that "you should be putting pressure on them".
The actual reason is that they are putting pressure on you as a show of force, rather than actually wanted it to go faster.
This is why the only response to a bad manager is to run away.
