How becoming a pilot made me a better programmer

Personal opinion: If you have the tendency to involuntarily hyperfocus on things, re-consider your interest in flying.

I had that happen to me once while landing in high wind, and it's only thanks to my instructor that I'm still with us today. Another time I was so focused on my landing pattern that I blanked out the tower instructions and pulled in front of a landing passenger plane (at MSP). And those are only the dangerous incidents, not the dozens of other minor incidents.

For me, the traits which make me an exceptional developer made me a terrible pilot. I can't regret choosing development of flying, just the money I lost realizing that I was not a good fit.

Flew for the military for a decade. Disagree with the black box take away. Feel that is beginning vs expert. In the beginning you learn the systems as a sort of firehouse training. But later, so much is black boxes. Certainly you want to try to understand inside the box, but the important part is to know the interface. The talk about intuition in a spin gets you killed. The spin recovery for his plane may not be the right recovery for other planes. Understanding the fuel system rather than memorizing emergency procedures is bad. It helps to know both, but intuition when in flight quickly falls apart and memorizing procedures until they become second nature is important. Loss of power off a carrier cat shot, engine failure, fires, out of control flight, and so much more, you better know your procedures for your aircraft. Understanding details is good, but knowing the procedures cold and not just relying on intuition is so important when flying. Seems similar to programming, at a small scale you can afford to know all the details, but working in a large company you would never be able to. The interfaces are critical.

I’ve done the opposite of the author. I was a professional pilot and flight instructor, now I’m a software engineer.

As always with these “techie turned pilot” articles, I disagree with the author’s conclusions. It sounds nice. Don’t let the airplane be a black box, don’t let the computer be a black box. Makes sense. But the prescription is wrong.

As an operator of a system (let’s say a pilot of an airplane) all you need is a basic understanding of how it works. Past that, you create mental models from experience and instruction. If I do A, B happens. If I need more X, do Y.

There also has to be a willingness to deal with change. Pushing the throttle decreases power? Cool. Today is backwards throttle day. Let’s get back to the airport and figure out why.

Being overly obsessed with the “why” can get you in trouble. Small airplanes crash all the time while people are trying to figure out what is wrong, when they should have just gone back and landed. Or, things don’t work the way they expect them to and they just can’t accept that. They crash into the ground being perfectly right.

The author’s own example of spin training disproves his point. I’ve taken about a dozen people through spin training. I can tell you that no amount of understanding an airplane will prepare you for recovering from a spin. Rote memorization (and practice) is exactly what you need. The fact that this memorized procedure is different that the standard procedure doesn’t make it not count.

Take two pilots, one that spent 10 minutes dry drilling the recovery procedures in a parked airplane and one that has written a paper on spin aerodynamics and watch who does a better recovery. I can tell you which airplane I’d rather be in.

There’s another problem with being overly reliant on the “white box” approach. It’s really easy for your mental model to be wrong. All the time I’d have some know-it-all pilot tell me why such-and-such is true. He’d have all this lovely reasoning. I’d listen to it all and then say “Cool. But that’s not what really happens. Want to fly and see?” It’s really easy for some mental model of a system to be missing one little thing that totally flips it around. The airplane never lies.

Now, I deal with the same thing in software. Someone treats the real world operation of software engineering with the academic touch of computer science, and things get all jacked up.

I am NOT against understanding the machine, wether it’s a computer or an airplane. My point is keep your eyes open. Your understanding should serve your operation. Don’t let your own knowledge get in the way of doing what works.

I love the "understand how it works before you use it" angle; this is how I was taught in school and it's how I practice. I had to build (simulated) CPUs and RAM out of transistors, an assembler and eventually compiler to run programs on my simulated computer. I have great respect for the machine (and also a deep hatred) but mentioning Von Neumann to a junior engineer these days will get you written up by HR (hostile work environment).

Unfortunately, today's new developers are die-hard black boxers. They were taught that software is built by integrating Twilio with Mailchimp and deploying to Heroku. Furthermore today's new managers are black boxers as well; both towards the software their teams produce as well as the teams themselves.

Experiencing new things is the best way to get new ideas. I've heard it described as the "hunch" theory of creativity: experiences give you "hunches" and they form ideas when they meet with new hunches.

On the subject of instrumenting your system and preventing bugs one thing that I've been investigating has been high-level specifications. Using temporal logic one can design systems with varying degrees of constraints, invariants, and properties and test those designs before building the implementation. It then follows that if your instrumentation is reporting errors you'll know that your implementation is not following the spec closely enough and using refinement calculus you might actually be able to discover how and eliminate the case from the specification.

Where this becomes useful is for really large applications at huge volumes (think AWS big). There might be an execution path in your algorithm that is 53 steps deep before it encounters an error. You might think such a bug only has a 1 in 500000 chance of being triggered for any given request. Well obscurity doesn't work in the land of large numbers where you're servicing many millions of requests per minute.

For large, complicated systems being as specific as a formal specification pays off... along with good instrumentation!

Great article.

When I was a teenager in the early 80s I both learned to fly (eventually becoming a flight instructor and charter pilot) and learned to program. There was definitely a synergy between the two. My systems perspective was formed in an environment where decisions managing relatively complex interactions with the physical world have serious consequences in a matter of a few minutes or sooner.

Emotionally IT/programming haven't been nearly as satisfying as successfully managing a flight in adverse or challenging circumstances. Bush runways, unexpected weather changes, etc....

From 2014 to current I too have been learning to fly (PPL and most recently night rating, single engine IFR is about to start next. If you're ever at CNC3 hit me up!). Being a part time student means you're "one of those guys" that everyone knows at the flying club/school. You're clearly learning just for personal enjoyment and betterment (because those who are not are trying to do it as quickly as possible, you just cant pull that off while working) and you stand out because you're not 18 years old like everyone else (i'm only 29, but still you're one of the old guys if you're anything above 25)

For me, learning to fly made me a smarter person in general, becoming a better programmer has been a benefit for sure, but I don't think that's where it ends.

I find that now I understand and estimate risk way better, know how to build processes and follow instruction better than ever before, and most importantly I have managed to step up my expectations of myself and those around me through the experience being involved in something that can be very dangerous, but doesn't need to be if you handle yourself appropriately, understand the systems around you and operate within logical/known limits...and then there is the added benefit of being able to fly.

It's not cheap, but if you have $20-25k available (and around 5-6 hours / week that you can sustain over a 6-12 month period; flying + study time), this might be a good thing for you to give a shot. Given the choice between doing my MBA and this, it's not only cheaper and was way more enjoyable, but the short term impact of doing this study and practical work has really helped me tackle a lot of issues I feel that I would have previously struggled with.

As the (programmer) spouse of a commercial-rated pilot I can endorse this premise. I've learned a lot about focus, analysis, and how parts AND process work together from my flights with her. The stakes are high, and that's why process is (should be) always followed. Cause, effect, and clarity are key.

Sort of related video from PyCon2015 about what programmers can take away from the habits and behaviors of licensed pilots.[0]

[0]: https://www.youtube.com/watch?v=we4G_X91e5w

Being a Sous Chef for a number of years taught me a lot about resource contention in real time systems, far more than I ever learned in the classroom although having the knowledge base definitely helps.

When you've allocating shared resources in a limited space frantically working with multiple other people during the rush, you really can see the algorithms at work and can learn to optimize and even come up with alternate algorithms solving these types of problems.

Working at Boeing on designing flight critical systems on airliners has had a lot of positive influence over my work in programming.

Doing anything in life makes you a better programmer.

I obtained my private pilots license in February this year and while I'm not a commercial programmer (anymore) I apply many of the wider lessons I was taught as part of my PPL to the running of my businesses.

Flying is said to be incredibly safe, and indeed it is. However it's equally unforgiving and mistakes are usually punished by a gruesome death - so they're to be avoided.

One key element of flying is checklists. Before you get in the plane, you use a checklist to verify that everything on the plane is as you want it to be for a safe and uneventful flight.

Suffer an engine failure? There's a checklist for that.

About to perform a manoeuvre that isn't simple straight and level flying? There's a checklist for that too.

If you thought there was lots of acronyms in IT, flying is equally as acronym heavy. There are catchy (and less catchy) acronyms for everything. For example, when you're thinking about coming in to land you perform a CBUMFICH. I know, doesn't sound catchy but it'll stick and before you know it you've memorised all the important things you need to do ahead of attempting to land a plane:

Carb heat hot

Test the brakes

Undercarriage down

Mixture - is it as you want it

Fuel - got enough for a go around?

Instruments - as you want them?

Carb heat cold again

Hatches and harnesses - is everybody strapped in?

That's just one of the many acronyms, or shortcuts, that are ingrained in to you to remember shit when you're already under a heavy mental load.

Then there's other things like gross error checking. Mental tools you're equipped with that allow you to take note of a scenario and make sure you're flying on the heading, speed, height and so on that you should be on without doing the intricate maths that gives you a 100% accurate answer. Contrary to the checklist sometimes when you're already under a mental load in the cockpit you need to use gross error checking to get yourself 99% confident that you're flying how and where you want to fly.

Then there's the communication element. So many smart mechanisms built in to how you communicate with other pilots and air traffic control to reduce the risk of error (mishearing vital information can be fatal). Also, the way that elements of flight evolve after accidents. For example...

http://www.echo-news.co.uk/news/842963.pilot_16_killed_in_pl...

This poor kid was a member of my club well before I started to learn to fly. He was overwhelmed by an instruction given to him by air traffic, lost situational awareness and stalled - re: my previous point about mistakes being unforgiving - he died. NTSB investigated and rather than try to apportion blame, they worked to ensure that this problem never occurred again. Their solution? When you're a student you always address yourself to air traffic control as STUDENT <CALL SIGN> <COMMUNICATION>. Simultaneously air traffic control were instructed to give students priority over all other air traffic. Such a beautifully simple solution and hopefully one that has prevented similar incidents occurring.

In summary - earning a PPL teaches a wide range of lessons, approaches, mental thought patterns, sensible communication strategies that can be applied to business and perhaps all areas of life.

In my experience, the programmers I've worked with that are also pilots have been just too meticulous for the work, there's too much attention to detail and focus that doesn't let them work on teams. And, sadly those traits are pretty bad to get stuff done.

Again, my experience. They had to let them go, although they are very bright and likely I'd hire a pilot again.