For awhile, I was working at NASA on an open source project. I had idealized NASA based on movies, and thought it was the kind of place where one could be bold with coming up with novel solutions to hard problems. I was naïve enough to think that if I had good solutions I could ignore the bureaucracy. I was extremely productive and often speaking up and contributing confidently in meetings. I ruffled feathers, and thought it was fine as long as my work was good. Around a year in, a middle manager started to micromanage who I was allowed to communicate with. I recall a point when I asked a superior, who had a cubicle next to mine, and who I had a positive relationship with up to that point, how his weekend was. He didn't respond and later that day the manager called me into the office and reprimanded me literally to the point of tears, for "going outside the chain of command". Eventually, despite being the most productive member of our open source team, in terms of open issues resolved, new features shipped, and tech debt paid off, I got fired for "low performance".
The lesson I took away is that I shouldn't work for bureaucratic organizations like NASA.
>The lesson I took away is that I shouldn't work for bureaucratic organizations like NASA.
PR or Reputation management can force a culture onto people which might be a bit toxic behind the scenes and some people just do not like their authority challenged, so stepping outside of the box even the mere suggestion can be a deadly experience.
I have had a similar experience with a different employer, on job interviews, when the interview asks if you have ever been terminated, what do you say and how do you explain it?
I've been terminated multiple times (not from NASA). Sometimes the company is folding, sometimes it's being acquired, which sometimes looks very similar to the engineering team being trimmed down to nothing. Sometimes it's because of bad management, sometimes it's because my expertise has been fully leveraged and they are going a different direction. I don't need to explain the reasoning of other people who's viewpoints are subjective and based on decision trees that reduce me to an abstract symbol. I collaborate, set goals, achieve goals, and ultimately focus on my own growth. A company is not a calculator or a family. A company is an organization that I'm involved with at a creative and financial level. I'm merely a part of the larger body, at the perimeter. I don't try to internalize what is out of my control or take it personally.
I'm sorry you experienced that. I've worked for a few big organizations and find that each of them have pockets of good and pockets of bad. I wouldn't exclude all large/bureaucratic places based on that one experience alone. I suggest that if you don't want to work for any kind of bureaucratic organization, do it for other reasons. Maybe reasons more along the lines of "you like owning a whole stack," "you enjoy wearing many hats," or "you like knowing everyone in a small, tightly-knit organization."
NASA's managerial culture is (in)famous for all the wrong reasons - see the Challenger and Columbia crashes [1][2]. It appears that every once in a while they crash a major vehicle, external pressure gives some control back to technical authorities, but over time they seem to fall back into the same bad habits. Depending on when you were there, it would be interesting to see if post-Columbia culture has "reverted to the mean".
Thinking back to Boeing's recent 737Max issues, I wonder how much managerial exchange is there between the two Aerospace organizations.
I agree that you are best placed to make that decision. I'm also fully aware though that I'd be a terrible corporate employee. I have enough interaction with corporate (large) customers to know I wouldn't be a good fit.
But I think your root mistake is in your measures of "performance". As a programmer you measure bugs fixed, features added, debt removed. Your manager though has different criteria (for himself, since he does none of those things) and some of his criteria bleed onto you.
Things like communication, documentation, co-worker relationships, priorities and focus, and so on. (for all I know you were excellent at all these.)
In my experience the most frustrated employees are where they want to play by one set of rules, but the organisation plays by a different set of rules. Funding the place where your ruleset match the organizational is critical.
I would wither in a place that was all process and little result. But I've also seen people wither at my office because there's a lack of formal process. Right person, right place, right time, is when the magic happens.
I love corporate work myself. I worked for small startups, but I feel better supported with a large organization.
I love middle-managers. It’s the one occupation everyone hates, but its sooooo important. They are able to keep focus, and make sure corporate pathologies don’t sink in. Plus, they’re very nice people.
I like chit chatting with the devs two floors up. They’re usually working on different projects, but facing all the same issues. Learning about the other teams around coffee or at lunch is fun.
I love the rumor mill. So and sos team is being split up. The manager that just resigned is starting his own company. We are about win a gigantic contract with the NSA. None of it’s true, of course. But it’s fun!
I like having an accounting department. We have these crazy accounting people who do all their work out loud, so we always know what they’re doing. I once heard then arguing over my paystub, so I walked over and asked if I could help. They were shocked I was real person and not some numbers on paper.
The politics are better when the company has a more formal way of doing things. Good companies have a cursus honorum.
At the end of the day I like big companies for the same reasons I like big cities: lots of people.
There's a reason the government and government contractors rarely attract good developers, and when they do, they don't keep them. It's a shame.
I know someone who knows quite a bit about the military-side of this space, and we were discussing a related problem: the US's capability of ramping up war-time production if we get into a hot conflict with Russia or China. The amount of waste, bureaucracy, and cost that goes into all of our military contracts would simply have to change, or we'd be screwed.
This friend of mine thinks we'd figure it out, but I'm not so sure.
One data point is the Urgent Operational Requirement (UOR) [0] experience in the UK military during Operation HERRICK [1], a.k.a. the Afghan campaign. The UK's military acquisition is notoriously glacial but when soldiers started dying because they didn't have the right kit a lot of things were suddenly acquired extremely quickly, for example electronic countermeasures against IEDs, new drones, body armour and a whole range of vehicles that massively reduced crew vulnerability to IEDs. The speed of delivery was partly achieved by cutting the red tape around acquisition, e.g. by not requiring competitive tendering if a 'good enough' already product existed in the market.
This strategy itself created problems for long-term through-life support of a suddenly incoherent vehicle fleet but in turn increased motivation to develop standardised vehicle architectures [2] to allow faster modular upgrades.
This approach isn't going to suddenly deliver a new type fighter aircraft in the timescales of a hot war with China, but it does demonstrate that at least one NATO acquisition system could be speeded up a bit. A current example that is being worked at the moment is how to ramp up supplies of artillery and missiles for supply to Ukraine.
[Edit] Things more generally have slowed down again, e.g. as evidenced by the UK's (failed and cancelled) Warrior Capability Sustainment Programme, a disastrous attempt to upgrade the British Army's primary armoured infantry fighting vehicle.
I think "NASA and open source" and I keep flashing back to the guy from JPL who used (unregistered!) xv to look at images from the Mars Pathfinder mission, live on television.
For those too young to remember, before ImageMagick came along, xv was pretty much the image viewer to have under Linux. It's still around, $35 and shareware: https://en.m.wikipedia.org/wiki/Xv_(software)
I'm the sole maintainer of a very small open source project at NASA. Despite the small codebase, I think I am still in the top ten most starred repos on github.com/nasa.
By far the biggest problem is that we don't get any time at all to devote to maintenance. The second the NASA project I wrote the software for stopped paying for my time, the project became a personal labor of love/hate. If I ever leave NASA, I'll lose my ability to merge PRs and presumably the project will be completely abandoned despite receiving fairly regular contributions from the community. I have no particular use for the software myself, so I sporadically review and merge PRs in my spare time entirely out of a dubiously founded sense of obligation to the people who bother to submit them.
This isn't specific to any organization. If you want this thing to keep going, you can maintain it anywhere; it's not tied to github.com/nasa in any way.
I'm the sole maintainer of another open source project at NASA. I'm super stoked about it, and because of that the project will live, not because of anything NASA does. It doesn't live at github.com/nasa, which is a good thing: if I leave, I get to take it with me. Every place I've ever worked (including NASA) doesn't care about open software one way or another: if you want to release stuff and maintain it publically, you can. They don't care.
Sadly that's categorically to allowed. I don't even have admin permissions on the repo, and I'm not allowed to give any permissions whatsoever to anyone outside of NASA.
I you think the NASA Open Source License is bad, look at the default license for non-commercial, ESA-funded software [1].
The territorial limitations effectively prevents any form of open distribution, yet the license is open enough to remove most commercial incentive for maintenance and further development: a perfect recipe to make software instant abandonware upon release.
For what it's worth, we developers (I'm a NASA contractor who maintains a small NASA open source project) feel the same way! Our lawyers not so much. It's a very slow process to change the default, but at least a couple of projects have managed to release under Apache instead of NOSA.
It's mentioned in the article, but I'm pointing out because I think it's really cool - FPrime, the JPL flight software framework used on (among other things) the Ingenuity Mars helicopter, is open source: https://github.com/nasa/fprime
There are third-party repos built around FPrime as well as documentation and training materials available here: https://github.com/fprime-community
Astronomy is good for our minds and souls but "near space" is vital for our survival. In this sense NASA (and related ESA) open source initiatives are among the most important there are.
I spent a year as a research assistant for a NASA project optimizing flight paths. Fantastic scientists - but their primary interests were not software.
Our research on GP models was based on Prof Rasmussen's GPML library[0].
At that time GPML was in fortran (or MATLAB?) but our simulator and training code was all Java.
So one of the senior researchers found a random java port on Github and just plugged it in.[1]
40 comments
[ 4.3 ms ] story [ 57.4 ms ] threadFor awhile, I was working at NASA on an open source project. I had idealized NASA based on movies, and thought it was the kind of place where one could be bold with coming up with novel solutions to hard problems. I was naïve enough to think that if I had good solutions I could ignore the bureaucracy. I was extremely productive and often speaking up and contributing confidently in meetings. I ruffled feathers, and thought it was fine as long as my work was good. Around a year in, a middle manager started to micromanage who I was allowed to communicate with. I recall a point when I asked a superior, who had a cubicle next to mine, and who I had a positive relationship with up to that point, how his weekend was. He didn't respond and later that day the manager called me into the office and reprimanded me literally to the point of tears, for "going outside the chain of command". Eventually, despite being the most productive member of our open source team, in terms of open issues resolved, new features shipped, and tech debt paid off, I got fired for "low performance".
The lesson I took away is that I shouldn't work for bureaucratic organizations like NASA.
PR or Reputation management can force a culture onto people which might be a bit toxic behind the scenes and some people just do not like their authority challenged, so stepping outside of the box even the mere suggestion can be a deadly experience.
Thinking back to Boeing's recent 737Max issues, I wonder how much managerial exchange is there between the two Aerospace organizations.
[1] https://en.wikipedia.org/wiki/Rogers_Commission_Report#Flawe... [2] https://en.wikipedia.org/wiki/Columbia_Accident_Investigatio...
But I think your root mistake is in your measures of "performance". As a programmer you measure bugs fixed, features added, debt removed. Your manager though has different criteria (for himself, since he does none of those things) and some of his criteria bleed onto you.
Things like communication, documentation, co-worker relationships, priorities and focus, and so on. (for all I know you were excellent at all these.)
In my experience the most frustrated employees are where they want to play by one set of rules, but the organisation plays by a different set of rules. Funding the place where your ruleset match the organizational is critical.
I would wither in a place that was all process and little result. But I've also seen people wither at my office because there's a lack of formal process. Right person, right place, right time, is when the magic happens.
I love middle-managers. It’s the one occupation everyone hates, but its sooooo important. They are able to keep focus, and make sure corporate pathologies don’t sink in. Plus, they’re very nice people.
I like chit chatting with the devs two floors up. They’re usually working on different projects, but facing all the same issues. Learning about the other teams around coffee or at lunch is fun.
I love the rumor mill. So and sos team is being split up. The manager that just resigned is starting his own company. We are about win a gigantic contract with the NSA. None of it’s true, of course. But it’s fun!
I like having an accounting department. We have these crazy accounting people who do all their work out loud, so we always know what they’re doing. I once heard then arguing over my paystub, so I walked over and asked if I could help. They were shocked I was real person and not some numbers on paper.
The politics are better when the company has a more formal way of doing things. Good companies have a cursus honorum.
At the end of the day I like big companies for the same reasons I like big cities: lots of people.
I know someone who knows quite a bit about the military-side of this space, and we were discussing a related problem: the US's capability of ramping up war-time production if we get into a hot conflict with Russia or China. The amount of waste, bureaucracy, and cost that goes into all of our military contracts would simply have to change, or we'd be screwed.
This friend of mine thinks we'd figure it out, but I'm not so sure.
This strategy itself created problems for long-term through-life support of a suddenly incoherent vehicle fleet but in turn increased motivation to develop standardised vehicle architectures [2] to allow faster modular upgrades.
This approach isn't going to suddenly deliver a new type fighter aircraft in the timescales of a hot war with China, but it does demonstrate that at least one NATO acquisition system could be speeded up a bit. A current example that is being worked at the moment is how to ramp up supplies of artillery and missiles for supply to Ukraine.
[Edit] Things more generally have slowed down again, e.g. as evidenced by the UK's (failed and cancelled) Warrior Capability Sustainment Programme, a disastrous attempt to upgrade the British Army's primary armoured infantry fighting vehicle.
[0] https://www.gov.uk/guidance/standing-commitments
[1] https://www.gov.uk/guidance/uk-forces-operations-in-afghanis...
[2] https://en.wikipedia.org/wiki/Generic_Vehicle_Architecture
[3] https://en.wikipedia.org/wiki/Warrior_tracked_armoured_vehic...
This by itself would have been enough for me to walk out. Toxic.
For those too young to remember, before ImageMagick came along, xv was pretty much the image viewer to have under Linux. It's still around, $35 and shareware: https://en.m.wikipedia.org/wiki/Xv_(software)
By far the biggest problem is that we don't get any time at all to devote to maintenance. The second the NASA project I wrote the software for stopped paying for my time, the project became a personal labor of love/hate. If I ever leave NASA, I'll lose my ability to merge PRs and presumably the project will be completely abandoned despite receiving fairly regular contributions from the community. I have no particular use for the software myself, so I sporadically review and merge PRs in my spare time entirely out of a dubiously founded sense of obligation to the people who bother to submit them.
I'm the sole maintainer of another open source project at NASA. I'm super stoked about it, and because of that the project will live, not because of anything NASA does. It doesn't live at github.com/nasa, which is a good thing: if I leave, I get to take it with me. Every place I've ever worked (including NASA) doesn't care about open software one way or another: if you want to release stuff and maintain it publically, you can. They don't care.
The territorial limitations effectively prevents any form of open distribution, yet the license is open enough to remove most commercial incentive for maintenance and further development: a perfect recipe to make software instant abandonware upon release.
[1] https://essr.esa.int/license/european-space-agency-community...
There are third-party repos built around FPrime as well as documentation and training materials available here: https://github.com/fprime-community
Our research on GP models was based on Prof Rasmussen's GPML library[0].
At that time GPML was in fortran (or MATLAB?) but our simulator and training code was all Java.
So one of the senior researchers found a random java port on Github and just plugged it in.[1]
[0] https://gaussianprocess.org/gpml
[1] https://github.com/renzodenardi/jpgml