My degree is in mechanical engineering but I've been working in software for 4 years now but I worked on industrial control systems for a number of years before that.
My answer: to an extent. Broadly speaking, software engineers do _basically_ the same thing that "real" engineers do - learning patterns and applying the useful/applicable pieces to the problem at hand.
The fundamental difference that separates software engineers from the rest is the consequence of failure and the culture of caution that comes with it.
If you're working on (non-embedded) software and you ship broken code to prod, chances are your consequences range from embarrassment and some angry emails on one end to a major financial loss at worst. With most other engineering disciplines, the cost of a screw-up _starts_ with a major financial loss and worst case? Honestly the sky is the limit. Fatalities, environmental ruination, loss of critical infrastructure, you name it - there are enough case studies on industrial horror shows to keep you up for the rest of your life, and in engineering school we had to read a lot of them.
> With most other engineering disciplines, the cost of a screw-up _starts_ with a major financial loss
This isn't accurate. Engineering screw ups are extremely common, we just don't usually take notice of them because they are so much lesser than the horror stories we learn about in school. If I had a nickel for every time I had to beat on something with a hammer to get it to line up the way it did in the CAD model, I could probably afford to pay someone else to beat it with a hammer. Little mistakes are a daily occurrence in most places, to say nothing of situations where "that's not really a problem, you just need to re-tighten it every now and then." The tragedies you occasionally see on the news are just the mistakes too big to hide behind closed doors.
People think that knockoff products don't have engineering in them? Even in cars, a lot of things don't fit neatly as they should and its fine, we just do a little push.
Its not exactly the same (which two engineering practices are, anyway?) buts its pretty close.
Is that really a screw up? Companies pay for certain tolerances on their products. I think it's more likely someone acknowledged your anecdote was possible and decided the cost/benefit analysis worked out to that being most profitable. Most things don't have to fit like Lego (while some things have to fit even better than Lego).
Yes, it is a screw up. If something is in tolerance, it goes into the hole it was designed to go into, that's what a tolerance is. What I am describing is something that is out of tolerance for which corrective action needs to be taken to get it into tolerance. This is not an uncommon occurrence, it is the norm. There are times when you deliberately put in room for fine adjustment, but you don't do fine adjustment by bashing on things with a hammer (or if you do then you've made some other mistake).
In the case of the thing that needs to be retightened periodically, I'm referring to a case where a cost/benefit analysis would show that regular maintenance is more costly in the long run. Imagine a $1 Million dollar machine that is supposed to cost $50k per year to run over its lifetime of 10 years, but due to poor design winds up costing $100k per year to run. No one is going to pay an extra $1 Million to build a new machine to save $500k, but that's still $500k lost due to a screw up.
There isn't some secret army of engineers performing optimizations behind my back. Engineers design things to work, but we are fallible human beings who suffer confusion, exhaustion, distraction and at times just pure incompetence. Depending on the complexity of a system, we might have fellow engineers review our plans to look for issues we missed, but those reviewers too are fallible so things nevertheless get through.
Sorry for going off a tangent here, but when you say you got a CS degree after being a mechanical and energy engineer, do you mean you went back to university for a full undergrad in CS? Or was that a Master’s?
I’ve been thinking of going back to school to go the opposite route (CS -> engineering, probably aerospace), but I have no idea how to go about it or how to estimate how much cash I need.
I didn't actually go back to school for CS - I had a lot of CS classes in undergrad that gave me some of the OOP theory background, but after that has just been whatever I picked up on the job or to solve a problem on the side.
I also got a bit lucky when I was looking for my first fully-CS job in that my title was "automation engineer," so I was getting interest from recruiters thinking I was a _test_ automation engineer. That opened up the door, after that it was just sweet talking my way in and faking it till I made it, lol.
My answer: to an extent. Broadly speaking, software engineers do _basically_ the same thing that "real" engineers do - learning patterns and applying the useful/applicable pieces to the problem at hand.
The fundamental difference that separates software engineers from the rest is the consequence of failure and the culture of caution that comes with it.
If you're working on (non-embedded) software and you ship broken code to prod, chances are your consequences range from embarrassment and some angry emails on one end to a major financial loss at worst. With most other engineering disciplines, the cost of a screw-up _starts_ with a major financial loss and worst case? Honestly the sky is the limit. Fatalities, environmental ruination, loss of critical infrastructure, you name it - there are enough case studies on industrial horror shows to keep you up for the rest of your life, and in engineering school we had to read a lot of them.