Notes from Seven Years of Flight Simulators
I spent seven years building flight simulators. VR aerobatic trainers, military rotary-wing systems, a few one-offs for testing autonomous flight controllers. I left that world eighteen months ago, and I’ve been meaning to write these notes ever since.
These aren’t lessons I learned consciously. Most of them only became legible in retrospect, once I was doing something different and kept bumping into the same ideas in new clothes.
Real-Time Systems Teach You to Respect Time
A flight simulator runs at 60Hz. Not “roughly 60Hz” — exactly 60Hz. If your frame takes 17.2 milliseconds instead of 16.6, the pilot feels it. Vestibular mismatch. Their inner ear says one thing, their eyes say another. They get sick.
This constraint shapes everything. You don’t “optimize later.” You don’t allocate memory in the hot path. You measure, you profile, you cut. The discipline of working against a hard real-time deadline is one of the most useful things I learned, and it’s completely absent from most web development.
The equivalent lesson in web work is probably: don’t wait for users to complain about performance. Measure it upfront and treat slowness as a bug, not a roadmap item.
The Boring Parts Are Load-Bearing
Early on I was assigned to the hydraulics model. Not the flight dynamics — hydraulics. The pressure curves for gear retraction, the feel of the brakes under anti-skid. I was annoyed. I wanted to work on the interesting parts.
The hydraulics model was the interesting part. It was what made the sim feel like an airplane rather than a game. Pilots noticed when it was wrong immediately, even if they couldn’t articulate why. Get it right and they’d say nothing. Get it wrong and they’d climb out after fifteen minutes and refuse to continue.
The boring infrastructure in software systems works the same way. The logging, the error handling, the retry logic — nobody notices it when it works. Everyone notices when it doesn’t.
Simulator Sickness Is an Honest Signal
Simulator sickness — nausea, disorientation from sensory mismatch — is useful. It’s the body reporting that something in the model is wrong. Latency is too high, frame rate is dropping, the motion cue timing is off. You can’t paper over it.
I think about this when I encounter friction in software I’m building. User confusion is usually an honest signal too. It’s rarely that users are wrong. It’s usually that something in the model is off — a workflow that doesn’t match how people actually think, an abstraction that made sense to the engineer and confuses everyone else.
Certification Changed How I Think About Documentation
Aviation software has to be certified. Every requirement traced, every test case documented, every design decision justified. I found it suffocating at first. Later I found it clarifying.
The discipline of writing things down so that a skeptical third party can understand them — without asking you — is genuinely hard. It forces precision. You can’t hide behind “we’ll figure it out later” when “later” requires a documented rationale.
I don’t write that level of documentation for everything now. But I do ask: “if I weren’t here, could someone understand why this decision was made?” More often than I’d like, the answer is no.
The Career Change
I left because I wanted to work closer to data. Flight simulation gave me systems thinking, real-time constraints, and a respect for precision. It didn’t give me much exposure to analytics, models, or the tools that data people use.
So I moved sideways into APEX development, which put me closer to databases and reporting. And I’m now working toward something more explicitly data-focused — analytics, maybe some modelling.
The flight sim years were good. The lessons are portable. And it turns out “seven years on flight simulators” is a more interesting thing to have on a CV than I expected.