4 ms·

But so many bugs in software can be fixed by just turning the computer off and back on again. Is that great engineering or bad?

zo1 2y ago
To be honest, "engineers" in the physical sciences generally have a much easier and predictable time than programmers. Is that perhaps a fault of programmers, very possibly (nevermind, definitely our own doing). The reason I say they have an easier time is that a lot of their "problems" are solved, have general solutions and lookups, best practices that you can not deviate from, etc. E.g. look at the amount of times we all have to re-invent distributed work queues and notifying other systems of something. If we were in the context of physical engineering, there would be maybe 4 options, all with well-understood pros/cons and you just pick the one that fits your performance profile and requirements. Done. And then sure, we could get some "certified engineer" software title where a person can confidently say "yes I sign off that if you use this option, and your estimated load of messages per second never exceeds Y, and you have provisioned X-units of compute on your server, then you will lose less than 0.01% of messages." What an easy job that would be - Except we have countless hipster-devs all wanting to "do it their own way" and write their own library for it.
- jpc0 2y ago
  You used message queues which is a hard problem and compared it to what is probably a simple problem in engineering, picking a material or screw size or such. You have disciplines in software that can easily be equated to the engineering you described, many people get paid a lot of money to create CRUD apps. Which database do you select, how do you implement the webserver, do you seperate out the API and frontend? these are all pretty easy problems to solve and have solutions with obvious pros and cons, sure you can have someone try some novel technique every now and then but the industry as a whole know how to do that. When you start discussing distributed systems it's kind of in autonomous Mars rover territory, the best practices are kind of there but there isn't a ton of consensus that what is known is even the best solution.

zo1 2y ago

To be honest, "engineers" in the physical sciences generally have a much easier and predictable time than programmers. Is that perhaps a fault of programmers, very possibly (nevermind, definitely our own doing). The reason I say they have an easier time is that a lot of their "problems" are solved, have general solutions and lookups, best practices that you can not deviate from, etc. E.g. look at the amount of times we all have to re-invent distributed work queues and notifying other systems of something. If we were in the context of physical engineering, there would be maybe 4 options, all with well-understood pros/cons and you just pick the one that fits your performance profile and requirements. Done. And then sure, we could get some "certified engineer" software title where a person can confidently say "yes I sign off that if you use this option, and your estimated load of messages per second never exceeds Y, and you have provisioned X-units of compute on your server, then you will lose less than 0.01% of messages." What an easy job that would be - Except we have countless hipster-devs all wanting to "do it their own way" and write their own library for it.

jpc0 2y ago
You used message queues which is a hard problem and compared it to what is probably a simple problem in engineering, picking a material or screw size or such. You have disciplines in software that can easily be equated to the engineering you described, many people get paid a lot of money to create CRUD apps. Which database do you select, how do you implement the webserver, do you seperate out the API and frontend? these are all pretty easy problems to solve and have solutions with obvious pros and cons, sure you can have someone try some novel technique every now and then but the industry as a whole know how to do that. When you start discussing distributed systems it's kind of in autonomous Mars rover territory, the best practices are kind of there but there isn't a ton of consensus that what is known is even the best solution.