This is a huge point that many HNers probably don't get(but they think that they get). Releasing patches/bugfixes doesn't work so well on physical stuff. If Amazon AWS goes down, a group of people can figure out what went wrong, fix the issue and "reboot" the system and all that is lost is a bit of revenue and a portion of their reputation. When pieces break on heavy iron you don't have the time to figure out what went wrong and then fix it because someone is about to crash. Hence the difference between the traditional engineers and the software folks is the traditional engineers have to fix stuff before it breaks, software engineers can afford to fix stuff after it breaks.
> Hence the difference between the traditional engineers and the software folks is the traditional engineers have to fix stuff before it breaks, software engineers can afford to fix stuff after it breaks.
Absolutely. The mindset is just very different. I remember once running some software in debugger during a major tech demo, and fixing a display bug I saw was going to become a problem in the next few minutes using Edit & Continue in Visual Studio. That's the "software guy," "start up," way of doing it. That shit would never fly with "hardware guys."
This is a huge point that many HNers probably don't get(but they think that they get). Releasing patches/bugfixes doesn't work so well on physical stuff. If Amazon AWS goes down, a group of people can figure out what went wrong, fix the issue and "reboot" the system and all that is lost is a bit of revenue and a portion of their reputation. When pieces break on heavy iron you don't have the time to figure out what went wrong and then fix it because someone is about to crash. Hence the difference between the traditional engineers and the software folks is the traditional engineers have to fix stuff before it breaks, software engineers can afford to fix stuff after it breaks.