5 ms·

I studied Engineering in university (Electrical was my primary discipline, but in the first year we also spent some time on Civil, Chemical and Materials Eng) b

I studied Engineering in university (Electrical was my primary discipline, but in the first year we also spent some time on Civil, Chemical and Materials Eng) before later moving onto Software Engineering as a career. To me, the biggest difference between SWE and the other "real" Engineering disciplines is about respect for the laws of physics. Engineers from the classical disciplines have a deep understanding of the immutability of physical laws, and build mental models that accurately represent this as best they can. SWEs, on the other hand, have a tendency to build mental models that are more conceptual or metaphysical, and try and force these onto real-world silicon. (This is somewhat idealised, of course. There are hack engineers that don't understand first principles in the slightest, just as there are software engineers who have no high-level understanding of the code they just copy-pasted from Stack Overflow).

razzio 5y ago
That is an interesting distinction. Laws of physics are clearly a constraint to whatever is being engineered. In software development this sometimes plays a role too, more so on embedded and real-time systems. Real-time systems have a time constraints which is a law of physics and embedded software development has to incorporate memory, cpu and sometimes thermal constraints. I do consider software for these systems closer to engineering, so you might be on to something. That doesn't mean I'd exclude other software development but the notions of (law of physics) constraints and predictable outcome are important factors.
goodpoint 5y ago
> SWEs, on the other hand, have a tendency to build mental models that are more conceptual or metaphysical, and try and force these onto real-world silicon. Aka if you are a good software engineer you understand well how hardware works and how to push the boundaries. If you a Stack Overflow copypaste technician you are nowhere near an engineer.
- AussieWog93 5y ago
  >Aka if you are a good software engineer you understand well how hardware works and how to push the boundaries. It's not even necessarily about pushing the boundaries and milking every last drop out of the hardware; there's a culture amongst even productive senior software engineers of handwaving over hardware altogether. From my experience, bringing up optimisations or performance around non-embedded, non-gaming software engineers will invariably steer the discussion towards big-O notation and algorithmic abstractions.

razzio 5y ago

That is an interesting distinction. Laws of physics are clearly a constraint to whatever is being engineered. In software development this sometimes plays a role too, more so on embedded and real-time systems. Real-time systems have a time constraints which is a law of physics and embedded software development has to incorporate memory, cpu and sometimes thermal constraints. I do consider software for these systems closer to engineering, so you might be on to something. That doesn't mean I'd exclude other software development but the notions of (law of physics) constraints and predictable outcome are important factors.

goodpoint 5y ago

> SWEs, on the other hand, have a tendency to build mental models that are more conceptual or metaphysical, and try and force these onto real-world silicon. Aka if you are a good software engineer you understand well how hardware works and how to push the boundaries. If you a Stack Overflow copypaste technician you are nowhere near an engineer.

AussieWog93 5y ago
>Aka if you are a good software engineer you understand well how hardware works and how to push the boundaries. It's not even necessarily about pushing the boundaries and milking every last drop out of the hardware; there's a culture amongst even productive senior software engineers of handwaving over hardware altogether. From my experience, bringing up optimisations or performance around non-embedded, non-gaming software engineers will invariably steer the discussion towards big-O notation and algorithmic abstractions.