Often these are the product managers building follow-on features that don't get the usage they want. Users aren't using them, but monthly usage is the currency of so much PM work that they have to try to draw attention to it.

There will always be war crimes in a conflict of any scale. That is human nature even if we don't like it. If both sides aren't doing it with drones they are doing it with something else. You now see the action in every situation because there are cameras everywhere and incentive for all sides to shape the narrative with this content.

As far as AI is concerned, there is the huge risk for problems. That said, you can have entire sectors of a battlefield that are kill zones for artillery but now you have drones taking more targeted action. Western artillery capabilities and approaches are more precise than those used by the likes of Russia, but it's a still a case of pummeling certain places. Drones hitting within a sector aren't much different and possibly have some long-term benefits.

I can guarantee you that the class of problem you describe has been discussed at the individual contributor level, so is known to some extent. Getting it from recognition to action is the problem. It is a huge lift to get some of these small things through the gauntlet to execution. Meanwhile, as you say, competitors with taste and attention to detail are building a better product.

This is very much a problem of large organizations. Those same PMs at a small company. If Google Maps was an independent company, the impediments would be fewer and priorities more aligned with building the best Google Maps.

I don't work that closely with k8s, but have toyed with a cluster in my homelab, etc. Way back before it really got going, I observed some OpenStack folks make the jump to k8s.

Knowing what I knew about OpenStack, that gave me an inkling that what you describe would happen and we'd end up in this place where a reasonable thing exists but it has all of this crud layered on top. There are places where k8s makes sense and works well, but the people surrounding any project are the most important factor in the end result.

Today we have an industry around k8s. It keeps a lot of people busy and employed. These same folks will repeat k8s the next time, so the best thing people that who feel they have superior taste is to press forward with their own ideas as the behavior won't change.

I think the root of the complaints here is prioritization. The things they care about are prioritized. Qualitative feedback is likely already telling PMs that something is wrong and really should be fixed, but other feedback has more data supporting it.

They'd probably call the issue you see a "craft" issue. Some PM is likely raising it. What happens is that leaders in big companies want perspectives based on data. You can go in with issues like yours but if you don't have clear data that shows significant numbers of users leaving, or users piling in, then you might as well not show up. People care about craft primarily will really struggle in these large organizations. That's not a good thing but how it is.

In large organizations, you'll see a lot of A/B testing or experimentation. Some of the worst decisions from a craft perspective are ones where they only look for "did this cause some kind of negative impact on numbers?" situation. If your feature is neutral (on abandons, uninstalls, or whatever negative outcome), then it can get shipped which overrides any qualitative question around "should we ship this in this state?". Doesn't matter too much according to these folks because it's not making things worse (in terms of numbers.)

There is probably more to explore in modern "product management" that's at the root of many of these problems. HN tends to focus on engineering but within large companies there is now a bifurcation and development of a field that forgets lots of PM was already invented.

These people go to the extreme and feel they have to outdo each other in an arms race to win whatever category it is today.

You can have extreme ambitions without being a moron. It's possible for someone to be empathetic, but also really driven. The problem is that they are locked in a downward spiral and they can't possibly be vulnerable. It's only when they run out of money, or some other extreme event occurs that they change tack. That's moronic, especially when the outcomes are predictable.

There is a lot to be said about SV culture and the people that surround these VCs. A lot of people love these environments and more than tolerate the environment these VC folks create. It's hardly a new phenomenon.

How are they supposed to fund development? It's important to differentiate independent devs and the goliaths. When you release an app like this, it is "good enough" for more people. Your incentive to build the thing is that you can make a living off of it and continue crafting it with the intent of building other great things. The biggest software companies have many revenue streams and ways to cover costs that are very different from independent devs.

When you sell perpetual use software, you have the incentive to release yearly versions (or whatever cadence is best.) You are incentivized to only put bugfixes into next year's version to force upgrades. Users lose out because they don't get bug fixes and the developer is put in a spot where they have to look for more devious ways of making a profit.

To make money the cost of perpetual software is also very high. Devs make terrible compromises here to seem reasonable, but you need to move a lot of units to reduce the price to the level possible with subscription software.

Subscriptions are far from perfect, but they bring some balance. Next time you complain, it would be an interesting exercise to state what you would be prepared to pay and how often.

Windows was really picking up steam and there was a move to web development in the Windows-based developer space. Visual Basic and Delphi were popular but desktop development had peaked. ASP was for building your apps and SQL Server was the natural backend. SQL Server fed off this wave. It wasn't dislodging Oracle, but rather than every app being built on Oracle, more apps started to use SQL Server as the backend.

Then ASP.NET appeared on the scene and demand grew even more. It was a well-integrated combo that appealed to a lot of shops. I started my career in a global pharma and there was a split between tech budget. IT was a Windows shop for many reasons and ran as much on SQL Server as possible. R&D was Unix/Linux with Oracle. There was a real battle going on in the .NET vs Java (how about some EJB 1) and the databases followed the growth curves of both rather than competing against each other.

The SQL Slammer worm brought a lot of attention to the product. There were instances running everywhere and IT didn't expect so much adoption. Back then you had a lot more servers running inside offices than you do today. My office was much like my homelab today. This validated the need so the patches got applies, IT got involved in the upkeep, and adoption continued to grow.

Oracle's sales folk and lawyers were horrible to deal with. I had some experience of this directly as they tried pushing Java-related products and my boss dragged me into the evals. One of my in-laws was outside counsel in the IT space doing work with enterprise-sized companies. He claims they are the worst company he's ever had to deal with and wouldn't delegate any decision-making locally which endlessly dragged out deals. They had a good product but felt they could get away with anything. Over time he saw customers run lots of taskforces to chip away Oracle usage. This accelerated with SaaS because you could eliminate the app AND Oracle in one swoop.

People have a superficial knowledge of the space (I think this extends beyond Codeberg) but feel strongly that they need to advocate for something. Codeberg themselves seem to have opinions about what they want to do but people are suggesting they can do more simply because it gives them an outlet.

The constraints that Codeberg set seem to, on the surface at least, ensure they can scale based on their needs and protect them from external threats. Hosting random sites comes with a range of liabilities they probably understand and want to avoid right now. There are EU regulations which can be challenging to handle.

I think you miss the more common reasoning though. This starts with "can we build a Windows app?" The answer to that was "no" for many more people until relatively recently. The .NET Framework wasn't as available by default until the second half of the 2000s which caused some Windows app devs to hold off beyond the performance reasons and WinForms vs WPF. Electron and React go hand-in-hand here as they made a (crappy) Windows app easy.

What I feel popularized this was the webview approach on mobile. In 2010, there were a ton of frameworks popping up for hybrid mobile development. This was carried forward to desktop although some of us had been embedding IE webviews much earlier. This let people say "yes" and it went from one thing to the next with diversions into React Native.

Kids already are well aware of iPhone upgrades. Parents will get them this machine. They'll get going and soon enough be badgering their parents for an upgrade to a more competent machine. That is all by design while being an affordance for people who can only get in at the cheap end.

It was a much bigger struggle with conversations where I was putting extra pressure on myself. Being able to have those other conversations was helpful though. Eventually, I found a therapist and am in a better place with this.

You expect the humans to follow laws, follow orders, apply ethics, look for opportunities, etc. That said, you very quickly have people circling the wagons and protecting the autonomy of JSOC when there is some problem. In my mind it's similar with AI because the point is serving someone. As soon as that power is undermined, they start to push back. Similarly, they aren't motivated to constrain their power on their own. It needs external forces.

edit: missed word.

Fast forward twelve years and my wife did the MCIT at UPenn (https://catalog.upenn.edu/graduate/programs/computer-informa...) where git and other topics woven into the curriculum. Even then, they were perhaps a novelty because their focus was bringing non-CS undergrads into a CS Masters program. So-called "conversion" master's degrees were the norm in the UK in 2002.