This is not really true, in fact products become worse the farther away from the problem a developer is kept.

Best products I worked with and on (early in my career, before getting digested by big tech) had developers working closely with the users of the software. The worst were things like banking software for branches, where developers were kept as far as possible from the actual domain (and decision making) and driven with endless sterile spec documents.

There are daily syncs for things that take weeks to do due to compliance, endless war rooms to solve things that would be done offline in half the time, and random bullshit process and committees introduced by management which generate even more meetings...

It's common all over the world, motion instead of progress. It's incredible to me how all those companies don't realize where their money is spent. But alas you cannot make people see a problem if their salary depends on it, and I may be no different.

The real issue with US tech dominance is B2B (i.e. Microsoft)

Now the network effects have set in and it's hard to remove "naturally" WhatsApp, combined with the rise of VoIP spam callers which operators are too happy to tolerate (like they tolerated things like premium ringtones and numbers until they were forced not to)

You can use suspend+hibernate to accomplish that and it works well. Unless the gods of kernel lockdown decide you cannot for your own good (and it doesn't matter if your disk is fully encrypted, you're not worthy anyway) of course. It's their kernel running on your laptop after all.

The complete, unapologetic desire of devs and security teams (but also many infra teams) to not have any kind of ownership was horrifying to me.

In the end there's not a single solution or strategy, it really goes back to the organization and where your weaknesses and strength are as an org. If you have a gazillion consultants following the "best practice" of the day and exceptions on top of exceptions you are dead, devops or otherwise. You will still make billions if you are the right company though regardless of your software practices, so...

The foundation of the internet is something that gets bigger and bigger every year. I understand the sentiment and the reasoning of declaring software a "public good", but it won't scale.

Building a nuclear power plant incurs in a massive set up stage with a lot of unknowns unknowns and requiring impressive material engineering and QC.

Solar is much more "incremental", you can almost start producing electricity and recouping costs immediately.

But a nuclear reactor is an extremely dense power generator compared to a solar panel plant by orders of magnitude. I'm not really sure why are they compared this way.

Enshittification is all around us and is unstoppable. Because we have deadlines to hit and goals to shows we reached to the VP. We broke everything and the software is just half working? Come on that's an issue for the support and ops teams. On to the next beautiful feature we can put on marketing slides!

I actually recovered a laptop my family was using to launch firefox by installing linux on it (soldered ram went bad, linux is the only OS I could use to tell it to skip the bad blocks through kernel command line) but I hold no illusion about its level of "user experience". Just look at the comments in this recent thread [2]. And as a power user I am baffled by some of the choices at the kernel level (which I mentioned in that thread) and others closer to the user by distros (ubuntu and snaps, name an iconic duo), or things like flatpak not being close to ready and still shoved down user's throats...

I spent years when I was younger submitting bug reports for the papercuts I noticed - some ignored for years, some closed and forgotten forever when some project decided to move on from bugzilla - and I have no more time or energy to continue doing so. The maintainers after all write the code, I'm just a user and get no voice :)

I've been reading about the "year of linux" for years now, it's a meme for a reason. People that are not "prosumer" will keep using the preinstalled OS even if it's garbage - assuming they buy a laptop or desktop at all - and the prosumer will probably keep an OSX or a Windows machine close by anyway. Linux is usable as a browser kiosk sure but there is still plenty of friction on everything else. Enshittification will continue, and possibly infect also linux.

[1] https://www.omglinux.com/gnome-thumbnails-file-picker/

[2] https://news.ycombinator.com/item?id=43945373

I'm seeing another now in $current_job and I'm seeing similar symptoms (though the system being rewritten is far less important) and customers of the old system essentially abandoned to themselves and marketing and sales are scrambling to try to retain them.

Anecdotal experience is not so good. Rewriting a tiny component? Ok. Full on rewrite of a big system? I feel it's a bad idea and the wisdom holds true.

Turning lights off, closing shutters when it goes dark, handling temperature and CO2 concentrations, etc.

I feel people have a need to look at dashboards, have screens, etc (maybe it's some sort of sympathetic reaction about looking at dashboards all day at work?) instead of letting go. Dashboards should be looked at if something is wrong and automation is failing.

From little things to kernel lockdown breaking hibernate on a fully encrypted system just because you should be happy to get your laptop battery killed by s2idle or disable secure boot. Yay, security.

I can only imagine the pain of all the accessibility issues on top of what I experience.

In my experience at least if you're oncall during a sprint you would have less work assigned to you than otherwise (2 week sprint and 1 week you are oncall? 50% allocation) as the expectation is that week you will spend responding to alerts, or investigating issues, or even improving alerting and dashboard and fixing bugs. If this does not happen, devs don't push for it and management is completely blind to it you have an organization issue. If leadership does not care about the problem it's time to jump ship ASAP.

But I've seen people stubbornly defending an alert on >60% CPU usage of their 1 CPU allocated kubernetes pods where there was no impact in p99.9 latency (which was measured and was the actual metric that mattered as agreed with the rest of the business and internal customers of the service). Or alerting on each single pod restart. That is self inflicted pain.

I see normally in oncall threads people complaining about "I got paged by an alerts because of another system X" - but in at least in a big enough organization this should not happen and it's an organizational failure. There should be an operations center on 24h/24h able to triage, escalate and evaluate, possibly not staffed only with L1 techs and given enough freedom to actually improve and automate. I know there are places where that is not true, and I ran away screaming from some in my career once I understood tech leadership had no understanding why it was needed.

But you would be surprised how much of the oncall pain is actually self inflicted by application teams themselves (some examples I encountered in the last year: TCP connect timeouts in the minutes and with no retries, no retry policies in general and things that should be idempotent that are not, no circuit breaker strategies, connection pools churning as they're shared between 10+ remote endpoints, wrong expectations about transaction isolation levels and how to handle conflicts at least in simple scenarios).