From KC-10 Aircraft to Codebases: How I Learned System Design Before Computer Science
Before I ever wrote software professionally, I was an electrician and pneumatics specialist on KC-10 aircraft. I didn’t call it “system design,” but that’s exactly what it was — understanding how large, interconnected systems behave, fail, and recover. When I later moved into software engineering, so many principles felt familiar that it almost seemed like I had been training for it without realizing it.
System Design: Schematics → Architecture
Working on the KC-10 meant thinking in terms of systems, not isolated parts. Electrical, pneumatics, hydraulics, avionics all felt like everything relied on something else.
That mindset maps directly to software:
- Inputs/outputs in aircraf…
From KC-10 Aircraft to Codebases: How I Learned System Design Before Computer Science
Before I ever wrote software professionally, I was an electrician and pneumatics specialist on KC-10 aircraft. I didn’t call it “system design,” but that’s exactly what it was — understanding how large, interconnected systems behave, fail, and recover. When I later moved into software engineering, so many principles felt familiar that it almost seemed like I had been training for it without realizing it.
System Design: Schematics → Architecture
Working on the KC-10 meant thinking in terms of systems, not isolated parts. Electrical, pneumatics, hydraulics, avionics all felt like everything relied on something else.
That mindset maps directly to software:
- Inputs/outputs in aircraft systems behave like APIs.
- Dependencies and redundancy mirror service architecture and failover strategies.
- Failure modes taught me to ask not just “Does this work?” but “What happens when it doesn’t?”
The wiring diagrams I used to study feel a lot like the architecture diagrams I use today. Both describe how a complex system communicates and reacts under stress.
Troubleshooting & Debugging: Multimeters → Logs
Aircraft discrepancies rarely came with clear symptoms. To fix a problem, you had to reproduce it, trace the system end-to-end, and validate the fix with zero guesswork.
That is exactly how debugging works in software:
- Reproduce the issue under the right conditions
- Trace the flow through each subsystem or function
- Form hypotheses and test them
- Confirm the solution with checks and monitoring
Whether I’m holding a multimeter or scanning logs, the approach is identical: systematic, thorough, and evidence-driven.
Oversight & Quality: 100% or It Doesn’t Fly
On an aircraft, “good enough” is unacceptable. Everything is inspected, documented, and verified. Some tasks required multiple sign-offs because real lives depended on the result.
That experience shaped how I approach engineering quality today:
- Code reviews = peer inspections
- Testing and CI = functional and system checks
- Documentation = our modern technical orders
- Monitoring = continuous post-flight inspection
If code is going to “fly” in production, it should be something I’d confidently sign my name to.
Continuous Improvement & Mentorship
On the flight line, improvement was part of the culture. We refined procedures, looked for better ways to troubleshoot, and coached junior airmen so the whole team grew stronger.
In software, that became:
- Refactoring and reducing tech debt
- Sharing context with junior devs
- Running retros to identify process improvements
- Building a culture where quality and learning compound over time
It wasn’t just about fixing today’s issues, it was about making tomorrow’s work safer, faster, and smarter.
How This Shapes Me as an Engineer
My aviation experience trained me to:
- Think in systems
- Debug with discipline
- Treat quality as non-negotiable
- Improve the team, not just the task
I learned programming later, but the foundations of engineering — systems thinking, troubleshooting, ownership, and mentorship — were already there. The aircraft just taught them to me first.