6 ms·

God am I blessed to be building webapps and not be responsible for autopilot systems flying fellow humans 11Km above ground.

by avip 8y ago

ravenstine 8y ago
Does anyone know what the typical salary of this kind of software developer is? I hope they are paid several times more than I make as a web developer.
- vonmoltke 8y ago
  More like a couple times less. I left aerospace partially because the pay sucks.
  - jessaustin 8y ago
    Does this mean that the software developers aren't actually the people "responsible" for the behavior of the system?
    - magnamerc 8y ago
      Certain delegated systems engineers are 'responsible' for the system and they would work for Boeing or the FAA. In a field like Aerospace, you don't have 'software developers' per se. You have systems specialists who write software. You don't move fast and break things, you run simulations of the software over and over again while varying inputs and fixing edge cases, and then you do real world testing.
    - ams6110 8y ago
      I don't work in that area but could image it's much more layered. In consumer/webapp type software a lot of developers are more or less "full stack." In aerospace I could see it being much more rigorous and more like waterfall so by the time the specification gets to the programmer it's already been designed, reviewed, and signed off by several other engineers and the actual programming is a rather rote task. Or I could be totally wrong.
    - deleted 8y ago
      [deleted]
    - vonmoltke 8y ago
      Not sure how this relates to the issue of pay, but to answer your question: it's complicated, figuratively and literally. There is a significant amount of technical coordination required to produce a system as complex as a commercial airliner. Systems engineers, at multiple levels, are responsible for wrangling this complexity. The top-level "spec"[1] is codified and broken down by subsystem to create a set of subsystem specs. Systems and lead engineers for each subsystem take those requirements and evaluate the feasibility. If they see a problem with the requirements, they push back to the higher level with requested changes and justifications. The systems and lead engineers at that higher level then evaluate the request in the context of the other subsystems, because a spec change to Subsystem A may require changes to Subsystem B as well, so they need to communicate with the team on Subsystem B (who may have made their own change requests as well) to determine if they can deal with the necessary changes. Subsystems that are themselves composed of subsystems repeat this process for their own subsystems, creating the possibility that a request could ripple up multiple levels and down a different branch in the system architecture. At some point changes may flow back to the top level and require negotiation on the broad top-level requirements, pulling them away from "wish list" territory and towards concrete, deliverable requirements. This entire process is known as requirements gathering and flow-down. It is this process that defines the behavior of the system, through defining the behavior of each of its subsystems in turn down to the basic modules that are just collections of off-the-shelf or custom-built parts. Any of those basic modules that are entirely or primarily software should have a software engineer as the lead, helping to define what its requirements are and defining its interface with the rest of the system. Systems engineers tasked with managing those interfaces should also have significant familiarity with software development and architecture, perhaps even having started out as software engineers[2]. Ultimately, though, the lead and systems engineers[3] are responsible for making sure this process works effectively, and they have to do so as a team because a system like this is far too complicated for one or even a few engineers to fully understand. [1] I use this term loosely, because it's more like a wish list of parameters and features than a real spec. [2] "Systems engineer" is not a title you can drop in to straight out of school. It requires practical, cross-discipline knowledge of the design and architecture of the various subsystems that need to be combined to form the larger system. This is essential to be able to both understand how various subsystems affect each other and to effectively communicate with the engineers working on those subsystems. [3] At the higher levels, where you run into a "subsystem of subsystems", the lead may be a systems engineer.
- JustSomeNobody 8y ago
  Probably 1/4 what Google pays the people working on Gmail.
- bumby 8y ago
  They tend to be in the range of aerospace engineer salary. High end of engineer salary but not approaching silicon valley pay. Check out ONET for government data on salaries
  - ravenstine 8y ago
    If that's true, I'm not exactly sure how to feel about it. It seems messed up.
ams6110 8y ago
Me too. And this is why it sort of rubs me the wrong way when people building chat apps call themselves engineers.
- wafflesraccoon 8y ago
  Is gatekeeping like this necessary?
  - Dirlewanger 8y ago
    It's not so much that it's gatekeeping, but there's a big difference between writing bloated Electron applications with few, if any, constraints vs. writing Ada in an extremely constrained environment where there's memory constraints and other overhead that doesn't exist in the web development realm. If the former fails, a user gets slightly annoyed. If the latter fails, people die. One takes way more skill/training than the other. To treat the two on the same level is insincere at best.
    - salawat 8y ago
      It doesn't take substantially different training beyond recognizing that one is applying a different tool in a different environment. It's all programming. Different patterns, stacks, and pressure to test? Yes. Fundamentally the same work loop, however. I'd advise against raising one level of endeavor over another. It seldom produces substantive or useful conversation.
- cblades 8y ago
  Well this is the most casually elitist thing I've read in a long time. Anyone that's gotten through a 200 level programming course can probably throw together some kind of chat program that will let a few people talk. That's lightyears from a scalable, non-buggy, chat system with modern features deployed at scale.
  - ams6110 8y ago
    True, but there are still no lives on the line. And no personal liability (beyond maybe losing your job) for mistakes you make.
SilasX 8y ago
And blessed to get away with calling yourself an engineer without the rigor that these plane designers normally operate under.

God am I blessed to be building webapps and not be responsible for autopilot systems flying fellow humans 11Km above ground.

by avip 8y ago

God am I blessed to be building webapps and not be responsible for autopilot systems flying fellow humans 11Km above ground.

ravenstine 8y ago

Does anyone know what the typical salary of this kind of software developer is? I hope they are paid several times more than I make as a web developer.

vonmoltke 8y ago
More like a couple times less. I left aerospace partially because the pay sucks.
- jessaustin 8y ago
  Does this mean that the software developers aren't actually the people "responsible" for the behavior of the system?
  - magnamerc 8y ago
    Certain delegated systems engineers are 'responsible' for the system and they would work for Boeing or the FAA. In a field like Aerospace, you don't have 'software developers' per se. You have systems specialists who write software. You don't move fast and break things, you run simulations of the software over and over again while varying inputs and fixing edge cases, and then you do real world testing.
  - ams6110 8y ago
    I don't work in that area but could image it's much more layered. In consumer/webapp type software a lot of developers are more or less "full stack." In aerospace I could see it being much more rigorous and more like waterfall so by the time the specification gets to the programmer it's already been designed, reviewed, and signed off by several other engineers and the actual programming is a rather rote task. Or I could be totally wrong.
  - deleted 8y ago
    [deleted]
  - vonmoltke 8y ago
    Not sure how this relates to the issue of pay, but to answer your question: it's complicated, figuratively and literally. There is a significant amount of technical coordination required to produce a system as complex as a commercial airliner. Systems engineers, at multiple levels, are responsible for wrangling this complexity. The top-level "spec"[1] is codified and broken down by subsystem to create a set of subsystem specs. Systems and lead engineers for each subsystem take those requirements and evaluate the feasibility. If they see a problem with the requirements, they push back to the higher level with requested changes and justifications. The systems and lead engineers at that higher level then evaluate the request in the context of the other subsystems, because a spec change to Subsystem A may require changes to Subsystem B as well, so they need to communicate with the team on Subsystem B (who may have made their own change requests as well) to determine if they can deal with the necessary changes. Subsystems that are themselves composed of subsystems repeat this process for their own subsystems, creating the possibility that a request could ripple up multiple levels and down a different branch in the system architecture. At some point changes may flow back to the top level and require negotiation on the broad top-level requirements, pulling them away from "wish list" territory and towards concrete, deliverable requirements. This entire process is known as requirements gathering and flow-down. It is this process that defines the behavior of the system, through defining the behavior of each of its subsystems in turn down to the basic modules that are just collections of off-the-shelf or custom-built parts. Any of those basic modules that are entirely or primarily software should have a software engineer as the lead, helping to define what its requirements are and defining its interface with the rest of the system. Systems engineers tasked with managing those interfaces should also have significant familiarity with software development and architecture, perhaps even having started out as software engineers[2]. Ultimately, though, the lead and systems engineers[3] are responsible for making sure this process works effectively, and they have to do so as a team because a system like this is far too complicated for one or even a few engineers to fully understand. [1] I use this term loosely, because it's more like a wish list of parameters and features than a real spec. [2] "Systems engineer" is not a title you can drop in to straight out of school. It requires practical, cross-discipline knowledge of the design and architecture of the various subsystems that need to be combined to form the larger system. This is essential to be able to both understand how various subsystems affect each other and to effectively communicate with the engineers working on those subsystems. [3] At the higher levels, where you run into a "subsystem of subsystems", the lead may be a systems engineer.
JustSomeNobody 8y ago
Probably 1/4 what Google pays the people working on Gmail.
bumby 8y ago
They tend to be in the range of aerospace engineer salary. High end of engineer salary but not approaching silicon valley pay. Check out ONET for government data on salaries
- ravenstine 8y ago
  If that's true, I'm not exactly sure how to feel about it. It seems messed up.

ams6110 8y ago

Me too. And this is why it sort of rubs me the wrong way when people building chat apps call themselves engineers.

wafflesraccoon 8y ago
Is gatekeeping like this necessary?
- Dirlewanger 8y ago
  It's not so much that it's gatekeeping, but there's a big difference between writing bloated Electron applications with few, if any, constraints vs. writing Ada in an extremely constrained environment where there's memory constraints and other overhead that doesn't exist in the web development realm. If the former fails, a user gets slightly annoyed. If the latter fails, people die. One takes way more skill/training than the other. To treat the two on the same level is insincere at best.
  - salawat 8y ago
    It doesn't take substantially different training beyond recognizing that one is applying a different tool in a different environment. It's all programming. Different patterns, stacks, and pressure to test? Yes. Fundamentally the same work loop, however. I'd advise against raising one level of endeavor over another. It seldom produces substantive or useful conversation.
cblades 8y ago
Well this is the most casually elitist thing I've read in a long time. Anyone that's gotten through a 200 level programming course can probably throw together some kind of chat program that will let a few people talk. That's lightyears from a scalable, non-buggy, chat system with modern features deployed at scale.
- ams6110 8y ago
  True, but there are still no lives on the line. And no personal liability (beyond maybe losing your job) for mistakes you make.

SilasX 8y ago

And blessed to get away with calling yourself an engineer without the rigor that these plane designers normally operate under.