There are plenty of different software engineering fields, it's just that it's usually just called "domain knowledge" and nobody outside the field makes the distinction.
One of my internships was at a company that did avionics software. Avionics is about as different from Web 2.0 startups as you can possibly get and stay in the same industry. There are very rigorous traceability metrics that pretty much dictate exactly what can go in the software. Every line of code has to be traced back to a particular paragraph in the design doc, which has to be traced back to a particular numbered requirement. Oftentimes garbage collection or even heap allocation is banned to avoid unbounded pauses in execution time. So the behavior of the code is fully specified under all conditions, and often formally verified. This was the one place I've ever worked where I'd hear "So we should write it in Ada then?"
I've also worked in the financial industry. Little known fact about the financial industry: it's not one industry but many. The code that you'd use to build a quant trading model is very different from the code you'd use to build a retail banking portal. The former actually tends to look a lot like academic research code (i.e. a software engineer would consider it shitty, but it has impressive math and gets the job done).
I work in consumer web now, but at Google. We actually do care about latency, and CPU load, and memory consumption, and developer productivity. And so it actually ends up being a lot like real engineering, where you perform experiments to measure the performance of the building blocks you're using, carefully consider goals and trade-offs, make estimates and back-of-the-envelope feasibility studies before implementing, and then rigorously test that solution.
This is in complete contrast to when I had my own casual gaming startup, where neither performance nor reliability mattered all that much, the only thing that did was the user interface.
One of my internships was at a company that did avionics software. Avionics is about as different from Web 2.0 startups as you can possibly get and stay in the same industry. There are very rigorous traceability metrics that pretty much dictate exactly what can go in the software. Every line of code has to be traced back to a particular paragraph in the design doc, which has to be traced back to a particular numbered requirement. Oftentimes garbage collection or even heap allocation is banned to avoid unbounded pauses in execution time. So the behavior of the code is fully specified under all conditions, and often formally verified. This was the one place I've ever worked where I'd hear "So we should write it in Ada then?"
I've also worked in the financial industry. Little known fact about the financial industry: it's not one industry but many. The code that you'd use to build a quant trading model is very different from the code you'd use to build a retail banking portal. The former actually tends to look a lot like academic research code (i.e. a software engineer would consider it shitty, but it has impressive math and gets the job done).
I work in consumer web now, but at Google. We actually do care about latency, and CPU load, and memory consumption, and developer productivity. And so it actually ends up being a lot like real engineering, where you perform experiments to measure the performance of the building blocks you're using, carefully consider goals and trade-offs, make estimates and back-of-the-envelope feasibility studies before implementing, and then rigorously test that solution.
This is in complete contrast to when I had my own casual gaming startup, where neither performance nor reliability mattered all that much, the only thing that did was the user interface.