4 ms·

Engineers work with high level abstractions and heuristics nobody really understands all the time. There are people working on R&D, and building design tools, b

Engineers work with high level abstractions and heuristics nobody really understands all the time. There are people working on R&D, and building design tools, but then again there are also people working on algorithm theory and writing kernel drivers. I don't think there is a fundamental difference, just a difference in degree. Software enables far more layers of abstraction and far quicker development cycles than other engineering disciplines.

unishark 6y ago
You mean using experimental data rather than theory? It's still connected to the underlying science, which is the key component. It's like saying the difference between a peninsula and an island is one of degree. Yes in a sense, but one is tethered to the land. Certainly engineers can veer off into solely doing software, and there are vast numbers of people that straddle fields. But if they aren't using their fundamentals learned in engineering school (to oversimplify somewhat) you didn't need to hire an engineer. As for people building design tools, you mean engineers? When I say "top level predominantly" I mean things like this. The top level is the highest level for the software at hand. Practically everyone uses software. As for research, when it comes to engineering they are generally doing either applied science (of one of the hard sciences) or applied math. Certainly if you go to research conferences in CS or the right niches of engineering, you meet lots of people who are basically just applied mathematicians.
- IQunder130 6y ago
  I am a mechanical engineer by trade. By "heuristics nobody really understands" I do mean just that. Some of it may be grounded in experimentation, some of it might be grounded in data sets collected by god knows whom go knows when, some of it might just be "do it this way because the graybeards/application manuals say so". So on and so forth. I find that a lot of software people have a highly idealized notion of how the "traditional" engineering disciplines work. Generalizing strict safety procedures found in some niche industries like aerospace to other fields where they don't exist. The truth is that working under time or budget pressures and without fully understanding what you're doing is extremely prevalent outside of software too.

unishark 6y ago

You mean using experimental data rather than theory? It's still connected to the underlying science, which is the key component. It's like saying the difference between a peninsula and an island is one of degree. Yes in a sense, but one is tethered to the land. Certainly engineers can veer off into solely doing software, and there are vast numbers of people that straddle fields. But if they aren't using their fundamentals learned in engineering school (to oversimplify somewhat) you didn't need to hire an engineer. As for people building design tools, you mean engineers? When I say "top level predominantly" I mean things like this. The top level is the highest level for the software at hand. Practically everyone uses software. As for research, when it comes to engineering they are generally doing either applied science (of one of the hard sciences) or applied math. Certainly if you go to research conferences in CS or the right niches of engineering, you meet lots of people who are basically just applied mathematicians.

IQunder130 6y ago
I am a mechanical engineer by trade. By "heuristics nobody really understands" I do mean just that. Some of it may be grounded in experimentation, some of it might be grounded in data sets collected by god knows whom go knows when, some of it might just be "do it this way because the graybeards/application manuals say so". So on and so forth. I find that a lot of software people have a highly idealized notion of how the "traditional" engineering disciplines work. Generalizing strict safety procedures found in some niche industries like aerospace to other fields where they don't exist. The truth is that working under time or budget pressures and without fully understanding what you're doing is extremely prevalent outside of software too.