Unless you call yourself a rocket scientist, you probably don’t think your daily routine has much in common with flight software engineering. But you would be wrong.

Flight software engineers write computer code for NASA spacecraft, which is complicated because—hello—flying spacecraft into space is complicated.

Flight software runs the instruments and sensors that operate thermal control, spin stabilization on all three axes, uplink and downlink to communicate with spacecraft, data collection and handling, a cruise phase, a descent phase and sometimes a “landing on the surface of a planet” phase. And some of this happens simultaneously. (And I thought feeding the cat and dog at the same time was rough.)

If the spacecraft is far away, like, dude, on Mars or beyond, there’s no controlling it from the ground with a joystick, so the software has to be written to allow the spacecraft to run autonomously.

But the experiences of a flight-software-engineering person* are actually the same as the experiences of a regular-person person, from planning a family reunion, to cleaning the garage, to simply shopping for tonight’s dinner. If you skip the bits about the flying, disregard the software and pay no attention to the engineering, then what you’re left with is some amazingly useful life lessons:

• Feasibility and performance requirements (or, Can I really do this?). Before you decide to take on any project, it’s best to figure out if it’s even feasible — then be very clear about your objectives so you’ll know when you’ve reached them. The more specific you are about your goal, the more likely you’ll know when you’ve arrived.
• Manage layers of complexity (or, Bigger stuff is waaay harder to do). Complicated projects take more effort. I know that sounds totally obvious, but it’s true. The size of your endeavor, its newness and the number of people involved all add complexity. And that means adding time, money and energy. The more you can understand and predict complexity, the less effort you’ll have to expend correcting mistakes. So to minimize your difficulties, accurately predict complexity before you embark on a project.
• Fault protection (or, Planning for trouble). Always expect the unexpected to creep into your plans. In fact, the more complicated something is, the more uncertainty you should anticipate. Most people are overly optimistic, oblivious to what may go askew. But requirements change and evolve throughout an undertaking’s life cycle. You can’t anticipate everything, but you can predict that something unusual or uncertain is going to occur, even if you don’t know exactly what that madness might entail. So at least factor contingency into your plans. And be malleable and adapt to new developments along the way—then, when that strange or remarkable event erupts, you’ll end up wasting less effort recovering.
• System maturity (or, How to work in teams without killing each other). It’s more complicated trying to organize a new team than a familiar team. And a new task is more complicated than a task similar to what you’ve done before. If you’re working with the same people and you’re doing a similar project, you can just repeat yourself. But anything new is going to cost you. Although repeating yourself might seem advantageous, there’s also a disadvantage to being stuck in a rut. And because there are many interfaces, when working with complicated teams there has to be excellent communication between all the systems.

Thanks for reading, sharing and commenting, and happy flying!

Laura

*Thanks to JPL Flight Software Engineer Glenn Reeves for all of this valuable information.