4 ms·

Lots of weird opinion in this statement, maybe insecurity from never getting your degree? Software has proven to automate things just as important as “real engi

Lots of weird opinion in this statement, maybe insecurity from never getting your degree? Software has proven to automate things just as important as “real engineering” in many fields. Hospitals, power grids, entire financial systems.

shrimp_emoji 3y ago
As hard as CS is, I think any type of "engineering" is harder and that actual engineers are a way different breed than software engineers. Software, as a practice, is also the wild west compared to actual engineering disciplines which require licensing and have a much closer relationship to the phrase "regulations are written in blood".
- hnfong 3y ago
  "Actual" engineering might have greater stakes in terms of "blood", but I have a hard time believing they are harder. There are equations well known for hundreds of years on how to design a bridge that doesn't collapse. And the fact that most bridges don't actually collapse is not mainly due to the ingenuity of the engineer that built it, but rather, allowing liberal margins of errors for safety. If you use materials twice as strong as the minimum requirement, things don't break if you made a 50% error in your calculations. In fact, I'd be very concerned if "actual engineering" is hard. Given that most people are mediocre in ability ("licensing" is just about formal requirements, whether one can jump through the hoops, as opposed to actually being super smart), it's really scary if building a bridge or a building is "hard". On the other hand, building robust yet complex software is actually hard. There's no software equivalent of "just spend more money on materials to allow for a 10000% margin of error to ensure it doesn't break". Spending more money stops working at a certain point, for example, hiring more people doesn't work, per Mythical Man Month; spending more effort on handling edge cases don't always work, because writing more code with minimal utility means an even less maintainable project in the long run. Correct code almost has to be "mathematically perfect" in order to be small, simple-as-need-be, and robust. And then even if your own code is 100% error free, you have potential bugs all the way down from frameworks, compilers, to even the CPU (eg. Spectre). Software development definitely has one of the highest skill ceiling among the trades that I know of. Sure this doesn't apply to whoever wrote your CRUD app, but think about it -- let's say you're thinking of building a skyscraper that requires extremely difficult engineering (whatever that means) to properly build, nothing short of the most brilliant engineer would be capable of planning and executing the project, any mistakes would lead to a complete collapse of the building... would you want to proceed with this project? Yet people start software projects like these for fun. Precisely because it doesn't necessarily have to involve "blood".
- ambrose2 3y ago
  I was a "real engineer" for several years before learning to code and switching to software and found that software was harder and required a greater attention to detail, skill, depth of knowledge, and so on. I've found that your sentiment that software engineering is less rigorous is common among those that haven't done "real engineering" though. There is some truth that in software you have the option to push out risky code and have it fail and then course correct quickly, while in "real engineering" you can't take risks like that because there is a higher potential negative severity/outcome but that depends on the cost of software downtime and bugs. In "real engineering" you can also develop models and test things in a safer environment before the equivalent of "pushing out to prod" but often the feedback loop is longer, and so you have more time to consider your test, but that doesn't mean that reasoning about that system is any harder, or easier necessarily.
  - pcthrowaway 3y ago
    > There is some truth that in software you have the option to push out risky code and have it fail and then course correct quickly, while in "real engineering" you can't take risks like that because there is a higher potential negative severity/outcome but that depends on the cost of software downtime and bugs. I'm sure you could be like Albert Hofmann for Chemical Engineering, or Electroboom for EE
  - dranudin 3y ago
    I, too, was a "real" engineer before transitioning into software. I think you are right with your analysis. "Real" engineering, as practised by people in the industry, is neither harder nor more rigorous than real world software engineering. I wonder where this idea comes from. I read that very often here on HN.
    - mikewarot 3y ago
      For me, the reason I give so much respect to Engineers is that they have a profession, a set of rules they are willing to stand up for, and not violate. The law supports them in this manner. Perhaps my respect is misplaced, I'll never know for sure. The application of the rules and procedures reliably, every time, every day, for every little change, just seems so damned boring and yet terrifying. Knowing that if you're wrong, one or perhaps many people will die, is a strong incentive to do things right. Take the walkway collapse caused by a seemingly small change to make construction easier[1]. Or, the institutional failure when Engineers are over-ridden by management with spread-sheets who don't actually understand the problem at hand.[2] But... The day in, day out grind, it's so tempting to be clever and creative, and do the thing that programmers do all to often when they write code so cleaver they can't debug it. Give in to the temptation once, and someone else could die. What a grind... It's like being an accountant with a sword dangling over your head. Engineering is about being methodical and prudent, not about being the sharpest tool in the shed. [1] https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse [2] https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disaster https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disas...

shrimp_emoji 3y ago

As hard as CS is, I think any type of "engineering" is harder and that actual engineers are a way different breed than software engineers. Software, as a practice, is also the wild west compared to actual engineering disciplines which require licensing and have a much closer relationship to the phrase "regulations are written in blood".

hnfong 3y ago
"Actual" engineering might have greater stakes in terms of "blood", but I have a hard time believing they are harder. There are equations well known for hundreds of years on how to design a bridge that doesn't collapse. And the fact that most bridges don't actually collapse is not mainly due to the ingenuity of the engineer that built it, but rather, allowing liberal margins of errors for safety. If you use materials twice as strong as the minimum requirement, things don't break if you made a 50% error in your calculations. In fact, I'd be very concerned if "actual engineering" is hard. Given that most people are mediocre in ability ("licensing" is just about formal requirements, whether one can jump through the hoops, as opposed to actually being super smart), it's really scary if building a bridge or a building is "hard". On the other hand, building robust yet complex software is actually hard. There's no software equivalent of "just spend more money on materials to allow for a 10000% margin of error to ensure it doesn't break". Spending more money stops working at a certain point, for example, hiring more people doesn't work, per Mythical Man Month; spending more effort on handling edge cases don't always work, because writing more code with minimal utility means an even less maintainable project in the long run. Correct code almost has to be "mathematically perfect" in order to be small, simple-as-need-be, and robust. And then even if your own code is 100% error free, you have potential bugs all the way down from frameworks, compilers, to even the CPU (eg. Spectre). Software development definitely has one of the highest skill ceiling among the trades that I know of. Sure this doesn't apply to whoever wrote your CRUD app, but think about it -- let's say you're thinking of building a skyscraper that requires extremely difficult engineering (whatever that means) to properly build, nothing short of the most brilliant engineer would be capable of planning and executing the project, any mistakes would lead to a complete collapse of the building... would you want to proceed with this project? Yet people start software projects like these for fun. Precisely because it doesn't necessarily have to involve "blood".
ambrose2 3y ago
I was a "real engineer" for several years before learning to code and switching to software and found that software was harder and required a greater attention to detail, skill, depth of knowledge, and so on. I've found that your sentiment that software engineering is less rigorous is common among those that haven't done "real engineering" though. There is some truth that in software you have the option to push out risky code and have it fail and then course correct quickly, while in "real engineering" you can't take risks like that because there is a higher potential negative severity/outcome but that depends on the cost of software downtime and bugs. In "real engineering" you can also develop models and test things in a safer environment before the equivalent of "pushing out to prod" but often the feedback loop is longer, and so you have more time to consider your test, but that doesn't mean that reasoning about that system is any harder, or easier necessarily.
- pcthrowaway 3y ago
  > There is some truth that in software you have the option to push out risky code and have it fail and then course correct quickly, while in "real engineering" you can't take risks like that because there is a higher potential negative severity/outcome but that depends on the cost of software downtime and bugs. I'm sure you could be like Albert Hofmann for Chemical Engineering, or Electroboom for EE
- dranudin 3y ago
  I, too, was a "real" engineer before transitioning into software. I think you are right with your analysis. "Real" engineering, as practised by people in the industry, is neither harder nor more rigorous than real world software engineering. I wonder where this idea comes from. I read that very often here on HN.
  - mikewarot 3y ago
    For me, the reason I give so much respect to Engineers is that they have a profession, a set of rules they are willing to stand up for, and not violate. The law supports them in this manner. Perhaps my respect is misplaced, I'll never know for sure. The application of the rules and procedures reliably, every time, every day, for every little change, just seems so damned boring and yet terrifying. Knowing that if you're wrong, one or perhaps many people will die, is a strong incentive to do things right. Take the walkway collapse caused by a seemingly small change to make construction easier[1]. Or, the institutional failure when Engineers are over-ridden by management with spread-sheets who don't actually understand the problem at hand.[2] But... The day in, day out grind, it's so tempting to be clever and creative, and do the thing that programmers do all to often when they write code so cleaver they can't debug it. Give in to the temptation once, and someone else could die. What a grind... It's like being an accountant with a sword dangling over your head. Engineering is about being methodical and prudent, not about being the sharpest tool in the shed. [1] https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse [2] https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disaster https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disas...