4 ms·

As a software engineer, software "engineering" is a joke, at least in the sense we apply that term to other disciplines of engineering. It's not like all that c

As a software engineer, software "engineering" is a joke, at least in the sense we apply that term to other disciplines of engineering. It's not like all that complexity you mentioned is understood. It's worked around, and then the workaround is taken for granted and exists in perpetuity because nobody can discern why it was done in the first place. Watching a mechanical or electrical engineer be able to predict the performance of a design in a hypothetical scenario and then have that prediction largely reflect reality in later testing is pretty enlightening. These types of things generally don't happen in non-trivial software systems largely because software "engineers" don't really care. Formal methods for verifying correctness is something we've decided isn't worth it. Formally verified operating systems like seL4, and languages that lend themselves to formal verification like Ada/SPARK, are nothing more than oddities for most software engineers; the only places that bother with this are hard engineering firms that are trying to live up to do-or-die performance guarantees. Additionally, the minimum knowledge required to be a "good" software engineer is significantly lower than the amount required to be a "good" electrical engineer. You are not pushing any limits without an expansive understanding of mathematics, multiple opportunities to work on some very expensive shit, and an employer that's actually pushing something forward. Getting a VLSI/radio electronics/DSP/etc. engineer online is a process that takes years before that engineer doesn't need constant input to keep them from shitting the bed. Unless you're so passionate about it that you can't possibly bring yourself to do anything else, you would have to be insane to go through the amount of learning required so you can pull a salary that will only slightly top an entry-level software development job. None of this is to say that software development isn't valuable, or that the people that are doing aren't skilled, but as an industry, we don't hold ourselves to anywhere near the standard that other disciplines do, and there's not much to gain other than saving face by not admitting it.

eastbound 4y ago
You comment a lot about calculating performance, but this is not engineering. Engineering is about suiting the needs to the means. In the realm of widely-used webapps, the need is 1. speed to market, 2. features and 3. maybe stability against errors 4. if successful, scalability. And our engineering is perfectly successful for that. We are able to output features after features, we’ve factorized the boilerplate, and we publish our apps before they’re even ready.
- Workaccount2 4y ago
  They are discussing the difference between engineers that have to toil with the rules of the universe, and engineers who have to toil with rules that they make themselves. Software does exactly what you tell it. Hardware does what you tell it, but it always listens to mother nature first.
- seabird 4y ago
  Scalability predictions from a software developer need to be taken with a grain of salt. There is no universal law determining it. The prediction is sound up until it runs into somebody else's fuckup, at which point it becomes worthless. The idea that most software engineers can make any real guarantees about the correctness of their programs is laughable. At least once a month we hear about a massive new vulnerability that proves that that just isn't true. To not accept it is hubris. It's not about calculating performance. It's about proving that something fundamentally fits in with everything we know about the world. Software developers that approach their work with this mindset are exceedingly rare, and their work is largely academic.
ZephyrBlu 4y ago
Disagree. The impression I've got when talking to friends in traditional engineering is that the scope of a software role is larger (More vertically integrated, more expectations) and we have better processes (E.g. code review, deployment pipeline, monitoring, etc). Cannot speak for EE, but I'm friends with people who do ChemE, MechE, Civil and mechatronics.

eastbound 4y ago

You comment a lot about calculating performance, but this is not engineering. Engineering is about suiting the needs to the means. In the realm of widely-used webapps, the need is 1. speed to market, 2. features and 3. maybe stability against errors 4. if successful, scalability. And our engineering is perfectly successful for that. We are able to output features after features, we’ve factorized the boilerplate, and we publish our apps before they’re even ready.

Workaccount2 4y ago
They are discussing the difference between engineers that have to toil with the rules of the universe, and engineers who have to toil with rules that they make themselves. Software does exactly what you tell it. Hardware does what you tell it, but it always listens to mother nature first.
seabird 4y ago
Scalability predictions from a software developer need to be taken with a grain of salt. There is no universal law determining it. The prediction is sound up until it runs into somebody else's fuckup, at which point it becomes worthless. The idea that most software engineers can make any real guarantees about the correctness of their programs is laughable. At least once a month we hear about a massive new vulnerability that proves that that just isn't true. To not accept it is hubris. It's not about calculating performance. It's about proving that something fundamentally fits in with everything we know about the world. Software developers that approach their work with this mindset are exceedingly rare, and their work is largely academic.

ZephyrBlu 4y ago

Disagree. The impression I've got when talking to friends in traditional engineering is that the scope of a software role is larger (More vertically integrated, more expectations) and we have better processes (E.g. code review, deployment pipeline, monitoring, etc). Cannot speak for EE, but I'm friends with people who do ChemE, MechE, Civil and mechatronics.