4 ms·

The aerospace industry OTOH, I don't miss. At least three people ITT have said something similar to this. Can you elaborate about what is so bad about working

The aerospace industry OTOH, I don't miss. At least three people ITT have said something similar to this. Can you elaborate about what is so bad about working as a software developer in the aerospace industry? Or would that require breaking all sorts of NDAs?

acomjean 8y ago
I worked in defense for 10 years then left. I'm assuming its similar to the defense industry I guess (Radar and we were a Boeing sub contractor). There a few things I don't miss: 1) It can be a little stressful, knowing that your software is controlling things that if wrong could go bad (people's lives are at stake). The strong process we had makes you abstract that away, but still its serious work. 2) Yesterdays technology tomorrow. We were using stable releases from years ago on hardware I couldn't buy in a a language hardly anyone uses (we were an Ada/C shop). I do like Ada, but it made it harder for employees let go to find new work. it was somewhat satisfying when the end result got built and it was operational. My software probably running today, somewhere. Even though I left a while ago.
- Jtsummers 8y ago
  I have a few more points but yours are a good start. It's software work run by hardware companies. They don't schedule or budget or staff correctly. They often put engineers (of any sort) into decision making positions that should belong to computer scientists (or at least those trained in programming). Writing software is often treated as "just typing" when it's really an engineering and design activity. Waterfall is also pervasive as a project management methodology. Even "modified Waterfall" (Vee model and others) are still subpar. What's frustrating is that, on the physical engineering side, they actually get the idea and value of prototypes and iterative development/design. But back to my first point, they still view software writing as a manufacturing activity, and not a design activity. So software shops get compared to the production line and not the engineering offices. Regarding 2: Oh man, yeah. We've got people straight of school stuck on projects written in JOVIAL. Literally put them into a dead-end job straight out of school, we can't retain them. And we don't have the money (from customers) to hire the old timers, they're enjoying retirement too much.
  - jcadam 8y ago
    > Oh man, yeah. We've got people straight of school stuck on projects written in JOVIAL. Literally put them into a dead-end job straight out of school, we can't retain them. Exactly this. I got stuck doing Ada near the beginning of my career. Took forever to extricate myself from that trap.
jcadam 8y ago
It's mind-numbing "code-to-spec" work. You aren't involved in the design or architecture (that is done several levels above you by "System Engineers"), you are given a highly detailed spec (sometimes so detailed it amounts to pseudo-code) that really doesn't allow any room for creative problem solving. The last aerospace job I had basically consisted of translating matlab script written by the scientists into Ada code (and God forbid you find a problem with one of the formulas a self-important PhD came up with). You are treated as an interchangeable cog. Most people who work outside the industry hear "I wrote a simulation model for a spacecraft attitude determination & control system" and think I was doing some really cool, challenging stuff. But as a software engineer, you really don't get to use your brain.
- 52-6F-62 8y ago
  That reminds me of my dad's recollections of working with Engineers (of what branch, I'm not sure) in the oil refinery he worked at for ~30 years. He was a pipefitter and he almost said what you just said word-for-word on a regular basis. If he had any corrections—well—he's just a lowly pipefitter, he can't be correct. Then he'd go out, work to their spec, the system would fail and he'd have to be called back in for overtime to fix it when they adjusted the spec to suit the problems he originally pointed out. Nothing new under the sun, huh.
  - ovi256 8y ago
    That's just bad process that many best practices make a point of correcting. Lean Manufacturing, famously, pushes for people to give feedback.
    - 52-6F-62 8y ago
      Ah. Well while a refinery is technically in the category of manufacturing, my father wasn't part of the oil refining process itself. He was initially construction, and later maintenance on—well—all of the pipes. So the situation wasn't as iterative. It was more, for ex: * We need a new line for X process. * Draft plans for new line. * Receive [unwanted] feedback from fitters familiar with existing lines (having been in and out of them for n years) * Disparage feedback and double-down on drafted plans * Fitters implement plans * Line fails (a number of times this step has nearly cost people their lives) * Feedback of failure reverts to engineers * Redraft plans with practical considerations applied * Fitters implement fixed plans AFAIU that even somewhat aligns with lean manufacturing—in that they adhered to the designed process according to the authority, and when defects were found they iterated. I think the main complaint is that the fitters at this point act as almost an extension of the machine itself explaining why something will not work, and the given authority rejected any input at the outset—acting as the old priest caste, if you will. I worked briefly for Toyota (subman. Toyoda Iron Works) and the process wasn't much different. The stakes were just lower as the parts were smaller, cheaper, and faster to adjust. If I, as an operator, attempted to raise issue with the engineering team I would have been laughed out of the room in the same way. † † the engineering team had us set every M part aside for inspection 2-3 times a day so they could come check calibration. There was no other direct feedback loop that way from ops.

acomjean 8y ago

I worked in defense for 10 years then left. I'm assuming its similar to the defense industry I guess (Radar and we were a Boeing sub contractor). There a few things I don't miss: 1) It can be a little stressful, knowing that your software is controlling things that if wrong could go bad (people's lives are at stake). The strong process we had makes you abstract that away, but still its serious work. 2) Yesterdays technology tomorrow. We were using stable releases from years ago on hardware I couldn't buy in a a language hardly anyone uses (we were an Ada/C shop). I do like Ada, but it made it harder for employees let go to find new work. it was somewhat satisfying when the end result got built and it was operational. My software probably running today, somewhere. Even though I left a while ago.

Jtsummers 8y ago
I have a few more points but yours are a good start. It's software work run by hardware companies. They don't schedule or budget or staff correctly. They often put engineers (of any sort) into decision making positions that should belong to computer scientists (or at least those trained in programming). Writing software is often treated as "just typing" when it's really an engineering and design activity. Waterfall is also pervasive as a project management methodology. Even "modified Waterfall" (Vee model and others) are still subpar. What's frustrating is that, on the physical engineering side, they actually get the idea and value of prototypes and iterative development/design. But back to my first point, they still view software writing as a manufacturing activity, and not a design activity. So software shops get compared to the production line and not the engineering offices. Regarding 2: Oh man, yeah. We've got people straight of school stuck on projects written in JOVIAL. Literally put them into a dead-end job straight out of school, we can't retain them. And we don't have the money (from customers) to hire the old timers, they're enjoying retirement too much.
- jcadam 8y ago
  > Oh man, yeah. We've got people straight of school stuck on projects written in JOVIAL. Literally put them into a dead-end job straight out of school, we can't retain them. Exactly this. I got stuck doing Ada near the beginning of my career. Took forever to extricate myself from that trap.

jcadam 8y ago

It's mind-numbing "code-to-spec" work. You aren't involved in the design or architecture (that is done several levels above you by "System Engineers"), you are given a highly detailed spec (sometimes so detailed it amounts to pseudo-code) that really doesn't allow any room for creative problem solving. The last aerospace job I had basically consisted of translating matlab script written by the scientists into Ada code (and God forbid you find a problem with one of the formulas a self-important PhD came up with). You are treated as an interchangeable cog. Most people who work outside the industry hear "I wrote a simulation model for a spacecraft attitude determination & control system" and think I was doing some really cool, challenging stuff. But as a software engineer, you really don't get to use your brain.

52-6F-62 8y ago
That reminds me of my dad's recollections of working with Engineers (of what branch, I'm not sure) in the oil refinery he worked at for ~30 years. He was a pipefitter and he almost said what you just said word-for-word on a regular basis. If he had any corrections—well—he's just a lowly pipefitter, he can't be correct. Then he'd go out, work to their spec, the system would fail and he'd have to be called back in for overtime to fix it when they adjusted the spec to suit the problems he originally pointed out. Nothing new under the sun, huh.
- ovi256 8y ago
  That's just bad process that many best practices make a point of correcting. Lean Manufacturing, famously, pushes for people to give feedback.
  - 52-6F-62 8y ago
    Ah. Well while a refinery is technically in the category of manufacturing, my father wasn't part of the oil refining process itself. He was initially construction, and later maintenance on—well—all of the pipes. So the situation wasn't as iterative. It was more, for ex: * We need a new line for X process. * Draft plans for new line. * Receive [unwanted] feedback from fitters familiar with existing lines (having been in and out of them for n years) * Disparage feedback and double-down on drafted plans * Fitters implement plans * Line fails (a number of times this step has nearly cost people their lives) * Feedback of failure reverts to engineers * Redraft plans with practical considerations applied * Fitters implement fixed plans AFAIU that even somewhat aligns with lean manufacturing—in that they adhered to the designed process according to the authority, and when defects were found they iterated. I think the main complaint is that the fitters at this point act as almost an extension of the machine itself explaining why something will not work, and the given authority rejected any input at the outset—acting as the old priest caste, if you will. I worked briefly for Toyota (subman. Toyoda Iron Works) and the process wasn't much different. The stakes were just lower as the parts were smaller, cheaper, and faster to adjust. If I, as an operator, attempted to raise issue with the engineering team I would have been laughed out of the room in the same way. † † the engineering team had us set every M part aside for inspection 2-3 times a day so they could come check calibration. There was no other direct feedback loop that way from ops.