From the OP:

> I hope I’m not alone at this. I hope
there are people out there who want to do
the same. I’d appreciate if we at least
start talking about how absurdly bad our
current situation in the software industry
is. And then we maybe figure out how to
get out.

Okay, I'll respond, especially on the last
part "how to get out".

For the problems and struggles in the OP,
I've seen not all of them but too many and
sympathize. Mostly though, I don't have
those problems, and the main reason is in
the simple, old advice in the KISS
Principle where KISS abbreviates Keep it
Simple Silly although the last S does
not always abbreviate silly.

In particular my startup is a Web site and
seems to avoid all of the problems in the
OP. Some details:

(1) Bloated Unreliable Infrastructure?

My Web site is based on Microsoft's .NET
with ASP.NET for Web pages and ADO.NET for
access to SQL Server (relational
database). The version of .NET I'm using
is some 4.x. So far I've seen essentially
no significant revisions or bugs.

For the software for my Web pages I just
used one of the languages that comes with
.NET. I wanted to select between two, the
.NET version of C# and the .NET version of
Visual Basic. As far as I can tell, both
languages are plenty good ways to get to
the .NET classes and make use of
Microsoft's managed code, e.g., garbage
collection, and their CLR (common language
run time) code. And IIRC there is a
source code translator that will convert
either language to the other one, a point
which suggests that really the two
language are deeply equivalent.

I've written some C code off and on for
20+ years; mostly I remember the remark in
the Kernighan and Ritchie book on C that
the language has an "idiosyncratic syntax"
or some such -- I agree. I never could
understand the full generality of a
declaration of a function -- IIRC there is
some code in the book that helps parsing
such a statement. I do remember that

i = ++j+++++k++

is legal; I don't want any such code in my
startup; also my old tests showed that two
compilers gave different results.

I find Visual Basic to have a less
"idiosyncratic syntax" and a more
traditional syntax closer to the original
Basic and then Fortran, Algol, PL/I,
Pascal, etc. So, my 100,000 lines of
typing are in the .NET version of Visual
Basic (VB).

For my Web site, part of the code is for a
server process for some of the applied
math computing. The file of the VB
source code is 478,396 bytes long (the
source code is awash in comments), and the
EXE version is 94,720 bytes long. As far
as I can tell, the code loads and runs
right away. Looks nicely small and fast
and not bloated or slow to me.

(2) A bloated IDE (integrated development
environment).

I have no problems at all with IDEs. The
reason is simple: I don't use one.

Instead of an IDE, I typed all my code,
all 100,000 lines, into my favorite text
editor, KEdit. It has a macro language,
KEXX, a version of REXX, and in that
language I've typed about 200 little
macros. Some of those macros let KEdit be
plenty good enough for typing in software.

E.g., I have about 4000 Web pages of .NET
documentation from Microsoft's MSDN site.
Many of the comments in my VB source code
refer to some one of those pages by having
the tree name on my computer of the HTML
file; then a simple command displays the
Web page. When reading code and checking
the relevant documentation, that little
tool works fine.

After all, VB source code and HTML code
are just simple text; so are my Web site
log files, the KEXX code, Rexx language
scripting code, all the documentation I
write either in the code or in external
files (just simple text or TeX language
input), etc. So, a good general purpose
text editor can do well. And, "Look, Ma:
I get to use the same spell checker for
all such text!" The spell checker?
ASPELL with the TeX distribution I use.
It's terrific, really smart, blindingly
fast, runs in just a console window.

For KEdit, it seems to load and run right
away. I just looked and saw that what
appears to be the main EXE file
KEDITW32.exe is

1,074,456

bytes long -- not so bloated.

(3) Windows 10 Home Edition Reliability.

For a move, I got an HP laptop; it came
with Windows 10 Home Edition. I leave it
running 24 x 7. It hasn't quit in months.
It appears that now the Microsoft updates
get applied without stopping the programs
I usually have running, e.g., KEdit, the
video player VLC, Firefox, etc.

Using carefully selected options for
ROBOCOPY, I do full and incremental
backups of my files. I keep the
ROBOCOPY log output; that output shows the
data rate of the backup, and I have not
seen that to grow slower over time. The
disk in that laptop is rotating, and
I've never done a de-fragmentation. So, I
can't complain about performance growing
slower from bloat, disk fragmentation, etc.

(4) Windows 7 64 bit Professional Server.

For a first Web server, I plugged together
a mid-tower case with an AMD FX-8350
processor, 64 bit addressing, 8 cores, 4.0
GHz standard clock speed and installed
from a legal CD and authentication code
Windows 7 64 bit Professional SP1. As I
left that pair running 24 x 7,
occasionally it would stop with a memory
error of some kind. I installed an
update and never again saw any
reliability problem in months of 24 x 7
operation.

Since then I looked into Windows 7 64 bit
updates and concluded that (i) there was a
big roll-up of about 2016 or some such;
(ii) since then there have been updates
and fixes monthly and cumulative since the
big roll-up, and (iii) the updates for
Windows 7 64 bits and Windows Server 2008
are the same.

I can believe that Windows Server 2008
long ran and still runs some of the most
important computing in the world. So if
my Windows 7 64 bit Professional has the
same updates as Windows Server 2008, maybe
for use as a server my Windows 7
installation will be about the most
reliable major operating system in
computing so far. Fine with me.

So, I am not screaming bloody murder about
operating system or software reliability.

(5) Smart Phone Bloat and Reliability.

I have no problems with smartphones if
only because I have no smartphone and
don't want one: When smartphones first
came out, I saw the display as way too
small and the keyboard as just absurd.
Heck, in my desktop computing I have a
quite good keyboard but would like a
better one and, of course, would like a
larger screen -- no way do I want to
retreat to an absurd keyboard and a tiny
screen.

Next I guessed that there would be
problems in security, bloat, reliability,
system management, documentation, and
cost. Maybe history has confirmed some of
these guesses!

For a recent move, I got a $15 cell phone
and did use it a few times. Then I junked
it.

My phone is just what I want -- a land
line touch tone desk set with a phone
message function from my provider. Works
fine. So, I have a phone with lower cost
and no problems with keyboard, screen,
security, bloat, or documentation. Ah,
old Bell Tel built some solid hardware!

(6) Web Site Speed, Reliability, and
Bloat.

My Web site apparently has few or no
problems with speed, ....

Why? The site is simple, just some very
standard HTML code sent from now old and
apparently rock solid ASP.NET.

Fast? The largest Web page sends for just
400,000 bits.

The HTML used is so old that it should
look fine on any device anywhere in the
world with a Web browser up to date as of,
say, 10 years ago.

The key to all of this? The KISS
Principle.

YMMV!