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.

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.

Or I could be totally wrong.

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.