Trying to become a better developer by learning more about aviation

Similarly, Accidents in North American Mountaineering[1] covers failures and their factors and is good reading.

[1] https://publications.americanalpineclub.org/about_the_accide...

Don't forget their cousins "tree" and "fife" — or the overpronunciation of Papa as /papà/.

It takes two major failures or errors today to cause the crash of a commercial transport aircraft. All the single points of failure have been fixed. You'll see this repeatedly in NTSB reports. Failure or event A happened, and then failure or event B happened. Single-event crashes of airliners are very, very rare.

Former airline pilot checking in!

Remember the importance of checklists in the "grand scheme of things". It helps maintain proper "authority" during operation and makes sure you don't forget things. If you don't write it down and check it, someone, at a certain moment will forget something.

Also, the "Aviate, navigate, communicate" axiom (as mentioned by author) is really helpful if you're trying to setup incident/crisis response structures. You basically get your guiding principles for free from an industry that has 100+ years of experience in dealing with crisises. It's something I teach during every incident/crisis response workshop.

edit: Although it's not aviation specific, and a little light on the science, "The Checklist Manifesto" by A. Gawande is a nice introduction into using (and making) checklists.

Minor lessons from time at an aerospace company:

- When your device is in use in the field, the user will be too hot, too cold, too windy, too dark, too tired, too wet, too rushed, or under fire. Mistakes will be made. Design for that environment. Simplify controls. Make layouts very clear. Military equipment uses connectors which cannot be plugged in wrong, even if you try to force them. That's why. (Former USMC officer.)

- Make it easy to determine what's broken. Self-test features are essential. (USAF officer.)

- If A and B won't interoperate, check the interface specification. Whoever isn't compliant with the spec is wrong. They have to fix their side. If you can't decide who's wrong, the spec is wrong. This reduces interoperability from an O(N^2) problem to an O(N) problem. (DARPA program manager.)

- If the thing doesn't meet spec, have Q/A put a red REJECTED tag on it. The thing goes back, it doesn't get paid for, the supplier gets pounded on by Purchasing and Quality Control, and they get less future business. It's not your job to fix their problem. (This was from an era when DoD customers had more clout with suppliers.)

- There are not "bugs". There are "defects". (HP exec.)

- Let the fighter pilot drive. Just sit back and enjoy the world zooming by. (Navy aviator.)

Aerospace is a world with many hard-ass types, many of whom have been shot at and shot back, have landed a plane in bad weather, or both.