NASA still maintains some of the Voyager spacecraft code from the 70s era
NASA’s continued maintenance of the 1970s-era software running on the Voyager probes raises questions about how to sustain mission‑critical systems long after their creators retire. Commenters weigh the career value and learning opportunities of working on such obscure, hardware‑constrained legacy code against the pull of “modern” tools and greenfield projects. They also highlight the risks posed by lost or fragmentary documentation, bespoke instruction sets, and overreliance on tools like LLMs, arguing that deep human understanding and careful stewardship remain essential as Voyager nears the end of its operational life.
Career value and motivation
- Many see Voyager work as uniquely prestigious: rare mission-critical, end-of-life spacecraft code; a standout CV item that would strongly attract interview interest.
- Others argue it’s a risky “career dead end”: highly specialized, non-transferable skills on an isolated legacy system, with limited innovation and unclear post-mission prospects.
- Some older engineers say they’d resent being assigned “historical laundry” versus designing new systems; younger engineers may want greenfield work where they can “push the needle.”
Nature of the work: legacy vs innovation
- Supporters emphasize deep, full-stack understanding (hardware + assembly + constraints) and resilience engineering as powerful learning.
- Critics counter that the “cool factor” fades once you’re maintaining obscure tools while peers work on modern tech; they question if it’s the “best learning opportunity.”
Skills, hiring signals, and CVs
- Several commenters say any Voyager experience would be a strong hiring signal, suggesting problem-solving ability and mindset; tooling can be taught.
- There’s debate on niche skills (assembly, FORTH, Lisp, APL): good for mental flexibility, but not obviously valued in mainstream hiring.
Project management and modern practices
- Some contrast earlier eras of “true ownership” and less process with today’s perceived “clown show” of Scrum, standups, CI/CD, and PM layers.
- Others defend modern methods as exposing dysfunction and democratizing work, while acknowledging many organizations practice “fake agile” that adds meetings without empowerment.
Documentation, simulators, and technical debt
- Thread notes heavy loss and fragmentation of original documentation; much was paper that vanished during office moves.
- For at least one onboard computer, the team lacks a trusted simulator, a reliable instruction set definition, and even certainty about bit ordering.
- They once had a full testbed but decommissioned it; now rely on partial simulators and ambiguous scanned docs, sometimes with handwritten, unexplained edits.
- Commenters are surprised such a significant mission wasn’t more thoroughly digitized, but others point to tight budgets and low expectations for probe longevity.
LLMs and AI tools
- Some suggest LLMs could help read, organize, and even generate legacy code.
- Strong pushback highlights hallucinations, lack of trustworthiness, and the unacceptable risk for billion‑dollar, irreplaceable spacecraft.
- A middle view sees AI as a supervised assistant at best, never an autonomous actor on such missions.