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”

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.