8 ms·

How becoming a pilot made me a better programmer

111 points by janvdberg 10y ago

benmarks 10y ago
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.
- vvanders 10y ago
  I also think there's a lot to be learned from the no-blame process involved with accidents. I've always been amazed at how honest and self-reporting the industry seems to be. It seems there's a real interest in improving root causes and processes that somehow doesn't involve people's egos.
  - facetube 10y ago
    Yes! Cockpit/Crew Resource Management (CRM), too. As a developer who manages other developers, I'm completely fascinated with CRM; I found a whole lot of the material and concepts useful at work despite being nowhere near a airplane.
agentultra 10y ago
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.
serf 10y ago
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 https://www.youtube.com/watch?v=we4G_X91e5w
simonswords82 10y ago
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_plane_crash/ 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.
hashkb 10y ago
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.
- hoodwink 10y ago
  I liken this to a student pilot learning to fly in brand new Cirrus. Very quickly he'll be flying advanced missions, but at the expense of fundamental stick and rudder skills.
  - hashkb 10y ago
    So... Cirrus is the Ruby on Rails of aircraft? Quick edit: Most of the dollars I've ever made are thanks to Rails. But I know how a computer works.
    - hoodwink 10y ago
      Yes. The analogy works all around, even the debates that pilots have about the Cirrus versus a simple aircraft resembles those debates of developers.
- luu 10y ago
  > today's new developers are die-hard black boxers How is anything else even possible? I spent eight years doing CPU development and even at the time I wouldn't say that I understood how CPUs worked. No one understands how an entire desktop or server CPU works today. They're too complicated. Back in grad school, I had a fairly good solid state & device physics background, stronger than most EEs. Ten years later, if I now want to understand how a modern transistor works, I expect it would take me 1-2 months to get a good high-level picture. And that's just the digital stuff -- I never had a good picture of how analog circuits work, and understanding that would take years. In terms of complexity, the CPU is much less complex than the compiler or OS I use. For that matter, it's less complex than the browser I'm using to type this comment. If you don't believe that, look at the number of person years that goes into developing a CPU vs. the amount that's gone into any of those pieces of software. Relatively speaking, CPUs are simple. And they're still so complex that no human can understand them. There's no way to understand the entire stack below you unless, maybe, you're doing materials science work and don't have anything else below you in the stack. And even then, "understand" is sort of an iffy term to use. When I was up to date in the area, there were a lot of open questions on phenomenon that worked but had no proven "why". While I haven't looked into it, it's a pretty safe bet that the total number of such mysteries has increased. This isn't to say that people shouldn't develop some understanding of the building blocks they're using. Rather, understanding is a difference in degree, not a difference in kind. There's no such thing as understanding everything you use. There's just, at the margin, spending a bit more time on understanding components vs. spending a bit more time understanding how to use components.
falcolas 10y ago
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.
- vkjv 10y ago
  Thanks for this. I've always been interested in flying and have only taken one lesson. However, I also have tendency towards hyperfocus and this comment has sufficiently frightened me.
  - gaastonsr 10y ago
    Don't let it discourage you. If it didn't work for him doesn't mean is not going to work for you.
    - falcolas 10y ago
      I'll agree with this, but definitely recommend working with a good CFI, not just a prior student building up hours.
  - bdamm 10y ago
    It is the job of the flight instructor to keep you safe as you learn to fly. Multi tasking on the right things, and making those things as natural as driving a car, is the goal of flight instruction. Once you achieve this, your instructor might allow you to take the final exams. Learning to fly is like riding a motorcycle while controlling a sailboat. At first everyone is overwhelmed. But with practice it becomes second nature. Instrument flying is a significant step up in difficulty with respect to multi-tasking and attention division.
- 10y ago
innertracks 10y ago
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....
igorgue 10y ago
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.
- zerohp 10y ago
  It sounds like they were a bad fit for the job, but that's not true for all programming jobs.
WalterBright 10y ago
Working at Boeing on designing flight critical systems on airliners has had a lot of positive influence over my work in programming.
kruhft 10y ago
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.
jungrothmorton 10y ago
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.
- 0xdeadbeefbabe 10y ago
  > They crash into the ground being perfectly right. I read of German clerks during WWII who wouldn't surrender till they had finished typing a report. Even though the enemy was already there.
throwaway26960 10y ago
Doing anything in life makes you a better programmer.
verelo 10y ago
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.
poof131 10y ago
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.
- someguydave 10y ago
  Programmers should be able to trust procedures (interfaces) to do what they want them to do.

111 points by janvdberg 10y ago

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.

vvanders 10y ago
I also think there's a lot to be learned from the no-blame process involved with accidents. I've always been amazed at how honest and self-reporting the industry seems to be. It seems there's a real interest in improving root causes and processes that somehow doesn't involve people's egos.
- facetube 10y ago
  Yes! Cockpit/Crew Resource Management (CRM), too. As a developer who manages other developers, I'm completely fascinated with CRM; I found a whole lot of the material and concepts useful at work despite being nowhere near a airplane.

agentultra 10y ago

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.

serf 10y ago

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 https://www.youtube.com/watch?v=we4G_X91e5w

simonswords82 10y ago

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_plane_crash/ 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.

hashkb 10y ago

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.

hoodwink 10y ago
I liken this to a student pilot learning to fly in brand new Cirrus. Very quickly he'll be flying advanced missions, but at the expense of fundamental stick and rudder skills.
- hashkb 10y ago
  So... Cirrus is the Ruby on Rails of aircraft? Quick edit: Most of the dollars I've ever made are thanks to Rails. But I know how a computer works.
  - hoodwink 10y ago
    Yes. The analogy works all around, even the debates that pilots have about the Cirrus versus a simple aircraft resembles those debates of developers.
luu 10y ago
> today's new developers are die-hard black boxers How is anything else even possible? I spent eight years doing CPU development and even at the time I wouldn't say that I understood how CPUs worked. No one understands how an entire desktop or server CPU works today. They're too complicated. Back in grad school, I had a fairly good solid state & device physics background, stronger than most EEs. Ten years later, if I now want to understand how a modern transistor works, I expect it would take me 1-2 months to get a good high-level picture. And that's just the digital stuff -- I never had a good picture of how analog circuits work, and understanding that would take years. In terms of complexity, the CPU is much less complex than the compiler or OS I use. For that matter, it's less complex than the browser I'm using to type this comment. If you don't believe that, look at the number of person years that goes into developing a CPU vs. the amount that's gone into any of those pieces of software. Relatively speaking, CPUs are simple. And they're still so complex that no human can understand them. There's no way to understand the entire stack below you unless, maybe, you're doing materials science work and don't have anything else below you in the stack. And even then, "understand" is sort of an iffy term to use. When I was up to date in the area, there were a lot of open questions on phenomenon that worked but had no proven "why". While I haven't looked into it, it's a pretty safe bet that the total number of such mysteries has increased. This isn't to say that people shouldn't develop some understanding of the building blocks they're using. Rather, understanding is a difference in degree, not a difference in kind. There's no such thing as understanding everything you use. There's just, at the margin, spending a bit more time on understanding components vs. spending a bit more time understanding how to use components.

falcolas 10y ago

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.

vkjv 10y ago
Thanks for this. I've always been interested in flying and have only taken one lesson. However, I also have tendency towards hyperfocus and this comment has sufficiently frightened me.
- gaastonsr 10y ago
  Don't let it discourage you. If it didn't work for him doesn't mean is not going to work for you.
  - falcolas 10y ago
    I'll agree with this, but definitely recommend working with a good CFI, not just a prior student building up hours.
- bdamm 10y ago
  It is the job of the flight instructor to keep you safe as you learn to fly. Multi tasking on the right things, and making those things as natural as driving a car, is the goal of flight instruction. Once you achieve this, your instructor might allow you to take the final exams. Learning to fly is like riding a motorcycle while controlling a sailboat. At first everyone is overwhelmed. But with practice it becomes second nature. Instrument flying is a significant step up in difficulty with respect to multi-tasking and attention division.
10y ago

innertracks 10y ago

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....

igorgue 10y ago

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.

zerohp 10y ago
It sounds like they were a bad fit for the job, but that's not true for all programming jobs.

WalterBright 10y ago

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

kruhft 10y ago

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.

jungrothmorton 10y ago

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.

0xdeadbeefbabe 10y ago
> They crash into the ground being perfectly right. I read of German clerks during WWII who wouldn't surrender till they had finished typing a report. Even though the enemy was already there.

throwaway26960 10y ago

Doing anything in life makes you a better programmer.

verelo 10y ago

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.

poof131 10y ago

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.

someguydave 10y ago
Programmers should be able to trust procedures (interfaces) to do what they want them to do.