The vast majority of the people responsible for the servers on the billion-dollar company I work for have never physically touched a server, a rack, or an Ethernet cable.
There's a whole generation of "point and click" admins quickly gaining prominence. I suspect cloud services have contributed to this lack of knowledge, because if all you know is cloud, you don't need to know things like this.
All of these little companies starting with brand new hardware as well. Far from all but a few of those 'garage startups' I knew of did limp along on used hardware for some time. It happened again a bit after the dotcom bubble burst (especially for office equipment) and again around 2008.
But for drives in particular, people are pretty superstitious about giving them up.
This feels honestly like my whole career. Just get to a point of competence and then get an offer you can't refuse.
It can help seeing people struggle with tech debt or bad decisions you had nothing to do with, if you can put yourself into the shoes of the person who did it. The wise man learns from the mistakes of others. But it does mean you have to do a little more sleuthing than the typical postmortem that just blames everything on an engineer who quit six months ago. That's facile, and neglects the contributions of people who still work here and/or think the same way.
> if all you know is cloud, you don't need to know things like this.
That's part of the cloud value proposition, isn't it? Leave the physical (and other low-level) stuff to people who do know that stuff, and can also reap economies of scale, while you focus on your own parts of the problem. Do you not approve of such specialization?
When AWS fails, it fails spectacularly. It also experiences outages fairly often, and you as the developer often have nothing you can do about it, but twiddle your thumbs and hope that your application was amenable to "high-availability architecture" (which is more expensive...). Finally, this particular failure mode brought down HN's servers, rented from a reputable hosting provider, and arguably this is something that a hosting provider should know.
It's also really hard to fix things when they're surrounded by a black box operated by someone who doesn't care. I kind of enjoy doing it, but it would be a lot more productive if I was able to diagnose network link problems by checking the error counters on all the routers/switches rather than by sending pings that hash over the numerous lacp alternate routes between two servers to figure out how to get a traceroute that shows the issue so the network owner can look at counters and fix the underlying issue.
This is a specific bug, like an overflow that is consistently triggered after about 4 years of use.