How becoming a pilot made me a better programmer(nathanmarz.com)
nathanmarz.com
How becoming a pilot made me a better programmer
http://nathanmarz.com/blog/how-becoming-a-pilot-made-me-a-better-programmer.html
14 comments
Situational awareness is one of the primary tenets of aviation. It is a skill, and like any skill it can be developed and refined.
Young pilots will start out flying in their own reality, one that is completely non-representative of what is actually occurring outside. Over time the gap between what you perceive is happening and what is actually happening will narrow to the point that you can operate safely on your own.
I write this not to contradict you but to prevent your post from discouraging any would-be pilots from pursuing what can be a very personally rewarding and enriching hobby--or career.
And apologies in advance if there is some sort of diagnosed mental condition or quality at play here but ideally that is something that is picked up by FAA medical examiners before students go out and solo.
Young pilots will start out flying in their own reality, one that is completely non-representative of what is actually occurring outside. Over time the gap between what you perceive is happening and what is actually happening will narrow to the point that you can operate safely on your own.
I write this not to contradict you but to prevent your post from discouraging any would-be pilots from pursuing what can be a very personally rewarding and enriching hobby--or career.
And apologies in advance if there is some sort of diagnosed mental condition or quality at play here but ideally that is something that is picked up by FAA medical examiners before students go out and solo.
Do FAA medical examiners have a suite of tests for tendency to zone out or hyperfocus? Do they measure how fast those skills are developing to measure the total cumulative risk experienced during the learning period where the situational awareness skill hasn't been learned? I'd be kind of interested in those; I'm pretty sure I'm a lot worse on both of those metrics than most people I know, but don't have a diagnosed attention-related mental condition or any evidence harder than "I nearly killed myself a few times just in the two months I had a learner's permit before deciding that cars weren't a good idea".
No, at least not that are administered in the regular course of getting aviation medical exams. General health (with particular focus on cardiovascular and neurological/consciousness concerns), eyesight, and hearing are the big ones.
I wouldn’t totally beat yourself up. Multi-tasking is one of the toughest and most important aspects of flying. You get better over time, but it is different than the intense focus in programming. The key is to just keep moving your focus: your scan. This takes practice and comfort. You have to learn to force yourself to keep scanning and never stopping. Practice makes it easier. And fear does a great job of making this tough in the beginning. Your brain doesn’t function at full capacity when flying and only experience makes this better. And missing radio calls is always a problem. A slow scan and task saturation makes it almost inevitable. Again, more comfort and a faster scan makes it easier to catch radio call.
You may not have been flying regularly enough. To get qualified, you should really dedicate a few months and try to fly multiple times a week. Currency is critical. Spacing things out makes it tougher and more expensive in the long run. If you really want to learn to fly, don’t give up because of a slow scan. Just work on it and fly as much as you can.
You may not have been flying regularly enough. To get qualified, you should really dedicate a few months and try to fly multiple times a week. Currency is critical. Spacing things out makes it tougher and more expensive in the long run. If you really want to learn to fly, don’t give up because of a slow scan. Just work on it and fly as much as you can.
I nearly ran into a big purple hot air balloon when landing a Cessna 152.
It was down and to the right and it was exactly in line with a row of evergreen trees so I think I could be forgiven. And it wasn't like the balloon was speeding along.
My instructor saw it immediately then again he did tell me to land as a passenger plane was approaching the other end of the runway.
I've dabbled with programming for at least 33 years but I don't seem to have the patience or focus. I love it but i just can't concentrate enough to follow complex sequences.
I suck at guitar too a lot of things, I'm good at sucking at many things.
It was down and to the right and it was exactly in line with a row of evergreen trees so I think I could be forgiven. And it wasn't like the balloon was speeding along.
My instructor saw it immediately then again he did tell me to land as a passenger plane was approaching the other end of the runway.
I've dabbled with programming for at least 33 years but I don't seem to have the patience or focus. I love it but i just can't concentrate enough to follow complex sequences.
I suck at guitar too a lot of things, I'm good at sucking at many things.
Coffee works wonders my friend.
I once hyperfocused/spaced-out-got-lost-in-thought while riding my bike down a hill. Coming into a turn, I snapped out of it, quickly realizing my two options were to fly over a cliff or crash. I chose crashing. I hit the brakes, flipped over the handle bars, and broke two arms. To this day I'm afraid to build up any significant momentum while riding my bike, and I didn't even get back on a bike for 8 years.
If I were a pilot, I would space out and die a horrible death.
If I were a pilot, I would space out and die a horrible death.
It's generally referred to as Target Fixation, it's a common issue amongst cyclists and motorcyclists: https://en.wikipedia.org/wiki/Target_fixation
The first advice I ever give to anyone new to mountain biking: "Look at where you want to go, never lock up (focus or elbows), and always look further ahead than what feels natural."
You don't always need to be focusing on an object for this phenomenon to occur. Your bike generally follows where you're focusing, so if you're looking towards the exit of a turn you're more likely to reach that exit. If you focus too close to the trail you also end up increasing your center of gravity, making you more unstable.
You don't always need to be focusing on an object for this phenomenon to occur. Your bike generally follows where you're focusing, so if you're looking towards the exit of a turn you're more likely to reach that exit. If you focus too close to the trail you also end up increasing your center of gravity, making you more unstable.
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.
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.
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.
Can you elaborate on these stories? What were you hyperfocused on during your high wind landing, and what should you have been noticing that you did not?
"If you have the tendency to involuntarily hyperfocus on things, re-consider your interest in flying."
I understand OP talk about a personal opinion but that is really bad advice from falcolas and dghughes, which with a grand total of a few hours of actual flying should have no business at all misleading potential wanabees pilots.
You don't know how to fly with a PPL, yet alone without it during your lessons. You learn flying every day, every minute, every seconds of practice. From zero hours to 30,000.
The truth is "hyperfocus" is a common trait of EVERY baby pilot out there. That is just the way it is, you were not born with flying skills. So you take a few lessons, you fly the plane but you make so much mistake and tend to be overwhelmed, "behind the plane" every time, some can't even manage the radio by themselves before 10 hours. That is expected, that is why there is this guy on your right to teach you how to fly, it's actually a job you know. So, fast forward 100 hours you won't believe what you can achieve with your airplane, but you still does not know anything about flying, just continue to learn. Then there will be this IFR thing when you will be IMC in the soup shouting your first ILS solo to minimum, yes on a Cessna 172 if you want to. This day you will feel overwhelmed once again. This game never end, but this is absolutely the best game around.
"For me, the traits which make me an exceptional developer made me a terrible pilot." Pretty BS statement. Let's forget the "exceptional developer" selfie part, I have the complete opposite experience regarding IT pilots. I would say this very traits is just a great asset for pilots, had falcolas not chickened early on he may have pushed to the IFR part and challenges, he would have discovered a better world than IT.
You may read this guy on this very topic : http://philip.greenspun.com/flying/
Direct to the point, for the HN crowd : http://philip.greenspun.com/materialism/early-retirement/avi...
Just leave your computer and live the life. Please wanabee pilots, don't listen to chicken talks, anybody can do it, go ahead, take this flight lesson, it will be one of the best time of your life !
I understand OP talk about a personal opinion but that is really bad advice from falcolas and dghughes, which with a grand total of a few hours of actual flying should have no business at all misleading potential wanabees pilots.
You don't know how to fly with a PPL, yet alone without it during your lessons. You learn flying every day, every minute, every seconds of practice. From zero hours to 30,000.
The truth is "hyperfocus" is a common trait of EVERY baby pilot out there. That is just the way it is, you were not born with flying skills. So you take a few lessons, you fly the plane but you make so much mistake and tend to be overwhelmed, "behind the plane" every time, some can't even manage the radio by themselves before 10 hours. That is expected, that is why there is this guy on your right to teach you how to fly, it's actually a job you know. So, fast forward 100 hours you won't believe what you can achieve with your airplane, but you still does not know anything about flying, just continue to learn. Then there will be this IFR thing when you will be IMC in the soup shouting your first ILS solo to minimum, yes on a Cessna 172 if you want to. This day you will feel overwhelmed once again. This game never end, but this is absolutely the best game around.
"For me, the traits which make me an exceptional developer made me a terrible pilot." Pretty BS statement. Let's forget the "exceptional developer" selfie part, I have the complete opposite experience regarding IT pilots. I would say this very traits is just a great asset for pilots, had falcolas not chickened early on he may have pushed to the IFR part and challenges, he would have discovered a better world than IT.
You may read this guy on this very topic : http://philip.greenspun.com/flying/
Direct to the point, for the HN crowd : http://philip.greenspun.com/materialism/early-retirement/avi...
Just leave your computer and live the life. Please wanabee pilots, don't listen to chicken talks, anybody can do it, go ahead, take this flight lesson, it will be one of the best time of your life !
I think it's helpful to hear about people who dropped out. If you only talk to successful pilots that's an obvious case of survivorship bias (in some cases literally).
For me I gave up on my lessons due to a combination of being a bit worried about my absent-mindedness and finding it not as much fun as I'd hoped, given the expense. (Not to mention meeting my girlfriend.)
I agree that like most things, it can be done if you put your mind to it. But everyone has to decide for themselves what their priorities are. I found that I'd rather be in the passenger's seat. Being the one with all the responsibility (particularly in a complicated airspace like the bay area) feels too much like work to me, and I think it would still feel like work with more experience.
I recommend taking a beginning lesson to anyone, though. You can do more than you'd expect.
For me I gave up on my lessons due to a combination of being a bit worried about my absent-mindedness and finding it not as much fun as I'd hoped, given the expense. (Not to mention meeting my girlfriend.)
I agree that like most things, it can be done if you put your mind to it. But everyone has to decide for themselves what their priorities are. I found that I'd rather be in the passenger's seat. Being the one with all the responsibility (particularly in a complicated airspace like the bay area) feels too much like work to me, and I think it would still feel like work with more experience.
I recommend taking a beginning lesson to anyone, though. You can do more than you'd expect.
I've got 500 hours and fly in the Bay all the time. It stopped being "work" a long time ago, and now it doesn't concern me at all to fly wherever I want to go. I wouldn't think twice about flipping on the mic and telling ATC what I want or need.
The money I will never get back and I'm still not sure it's worth it. But I sure have enjoyed the ride!
The money I will never get back and I'm still not sure it's worth it. But I sure have enjoyed the ride!
I have enough stick hours to have obtained my instrument and commercial ratings. It was enough for me to realize that this wasn't a passing problem that would go away with experience, it would (and did) get worse as things became routine.
But thank you for the "chicken" insult, it made me laugh.
But thank you for the "chicken" insult, it made me laugh.
I also tend to involuntarily hyperfocus. I don't dare read my phone in the car, because I forget I'm in the car. I am also employed as a programmer, and I tend to enjoy debugging at times.
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.
Programmers should be able to trust procedures (interfaces) to do what they want them to do.
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.
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 sort-of agree re: spin training.
The reason you don't recover with the ailerons is that it actually increases the angle of attack and makes the stall worse. It makes sense if you understand the aerodynamics. But my experience has been that a great deal of pilots actually have only a fairly rudimentary understanding of it.
>Programmers want to store and retrieve data using the database interface and then leave it to the ops guys to get it running robustly.
Surely the author isn't arguing that Encapsulation is a bad thing? The whole point of an API is that you shouldn't have to sweat the details.
The reason you don't recover with the ailerons is that it actually increases the angle of attack and makes the stall worse. It makes sense if you understand the aerodynamics. But my experience has been that a great deal of pilots actually have only a fairly rudimentary understanding of it.
>Programmers want to store and retrieve data using the database interface and then leave it to the ops guys to get it running robustly.
Surely the author isn't arguing that Encapsulation is a bad thing? The whole point of an API is that you shouldn't have to sweat the details.
You seem to be implying that I'm saying understanding how the plane works is more important than practice and memorization of procedures. I don't say that anywhere. What I do say is "You use your tools much more effectively and safely when you understand their implementation." I would not say that someone who blindly operates the airplane based on theory is someone who really understands implementation.
Understanding how the plane works goes a long way towards developing the right instincts. For example, understanding the aerodynamics of stalls helped me greatly in developing an instinct for keeping the ailerons neutral and being active on the rudder during recovery. Likewise, understanding the mechanics of carb icing helped me internalize that I should not be surprised if the engine runs even rougher immediately after applying carb heat. Finally, I got skilled at crosswind landings through an iterative process of thinking about the aerodynamics and then adjusting my technique through repeated practice.
I address the topic of "theory vs practice" directly when I said in the post "My answer is I advocate for a computer science education for programmers to the same extent I advocate for an aeronautical engineering degree for pilots. The degrees are relevant, useful, and helpful, but on their own do little to make you a good programmer or a good pilot." My previous post about computer science educations addresses this topic as well. [1]
[1] http://nathanmarz.com/blog/the-limited-value-of-a-computer-s...
Understanding how the plane works goes a long way towards developing the right instincts. For example, understanding the aerodynamics of stalls helped me greatly in developing an instinct for keeping the ailerons neutral and being active on the rudder during recovery. Likewise, understanding the mechanics of carb icing helped me internalize that I should not be surprised if the engine runs even rougher immediately after applying carb heat. Finally, I got skilled at crosswind landings through an iterative process of thinking about the aerodynamics and then adjusting my technique through repeated practice.
I address the topic of "theory vs practice" directly when I said in the post "My answer is I advocate for a computer science education for programmers to the same extent I advocate for an aeronautical engineering degree for pilots. The degrees are relevant, useful, and helpful, but on their own do little to make you a good programmer or a good pilot." My previous post about computer science educations addresses this topic as well. [1]
[1] http://nathanmarz.com/blog/the-limited-value-of-a-computer-s...
> Understanding how the plane works goes a long way towards developing the right instincts.
Well, I won't imply anything and I'll disagree with this directly. Understanding does not go a long way towards developing the right instincts. There is only one thing that develops instincts and that's repeated practice. Understanding doesn't even come close.
At best, understanding alleviates a mental block that some people have where they can't do something (in extreme cases literally physically can't do it at all) if they don't understand how it works. Not everyone has this.
In my experience as an instructor, this is more common among those who are from an engineering type background. I also find it to be strongly correlated with age. Younger people are more accepting of instruction (and tend to learn much faster).
I could write the same article about flying or programming: How I Learned to Stop Worrying and Love the Black Box.
Well, I won't imply anything and I'll disagree with this directly. Understanding does not go a long way towards developing the right instincts. There is only one thing that develops instincts and that's repeated practice. Understanding doesn't even come close.
At best, understanding alleviates a mental block that some people have where they can't do something (in extreme cases literally physically can't do it at all) if they don't understand how it works. Not everyone has this.
In my experience as an instructor, this is more common among those who are from an engineering type background. I also find it to be strongly correlated with age. Younger people are more accepting of instruction (and tend to learn much faster).
I could write the same article about flying or programming: How I Learned to Stop Worrying and Love the Black Box.
> I could write the same article about flying or programming: How I Learned to Stop Worrying and Love the Black Box.
Coincidentally enough, such an article already exists:
http://www.thecaucus.net/#/content/caucus/tech_blog/373
Coincidentally enough, such an article already exists:
http://www.thecaucus.net/#/content/caucus/tech_blog/373
[deleted]
> 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.
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.
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.
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.
> 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.
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.
Well it's really a balance. Looking at the CPU, these days the x86 instruction set is a total illusion--the CPU decodes those instructions so a totally different underlying architecture can take action on them. The block diagram for a modern processor is astounding.
Back when I was working on Motorola 68K processors and creating hardware drivers, learning to work with assembly helped me tremendously with basic principles like pointers/registers, stack/heap, memory-mapped IO, and so-forth. How the processor worked inside wasn't really the point; working with assembly made me a better C programmer.
The point isn't so much that you have to keep peeling back the layers of the onion so far that you can understand how the silicon is laid out, you just need to peel back a couple more layers than you're used to. If you're a Ruby programmer, for example, write a C extension. It'll be enlightening.
Back when I was working on Motorola 68K processors and creating hardware drivers, learning to work with assembly helped me tremendously with basic principles like pointers/registers, stack/heap, memory-mapped IO, and so-forth. How the processor worked inside wasn't really the point; working with assembly made me a better C programmer.
The point isn't so much that you have to keep peeling back the layers of the onion so far that you can understand how the silicon is laid out, you just need to peel back a couple more layers than you're used to. If you're a Ruby programmer, for example, write a C extension. It'll be enlightening.
> The point isn't so much that you have to keep peeling back the layers of the onion so far that you can understand how the silicon is laid out, you just need to peel back a couple more layers than you're used to. If you're a Ruby programmer, for example, write a C extension. It'll be enlightening.
Thanks, this is just right. You don't have to meet the turtle on the bottom, but you should be acquainted with a few turtles down.
Thanks, this is just right. You don't have to meet the turtle on the bottom, but you should be acquainted with a few turtles down.
I'm not sure running on AWS instead of on your own server is actually going down a turtle. I run pretty much everything myself, but that is mostly dealing with complexity which isn't very enlightening. Might very well be that someone who uses a provider gets a better understanding of infrastructure design.
Running on AWS is going up at least one turtle, possibly several if you're throwing configuration management and deployment tools into the mix.
AWS abstracts out bare-metal through Xen, deployment images, the AWS control panel, its monitoring, and the fact that you can't physically grab and yank the server should you want to.
On bare metal, you've removed most of those layers, though you have the option of putting most of them back in. I find the head for AWS vs. bare-metal admin to be quite different. Being old school, I prefer metal.
AWS abstracts out bare-metal through Xen, deployment images, the AWS control panel, its monitoring, and the fact that you can't physically grab and yank the server should you want to.
On bare metal, you've removed most of those layers, though you have the option of putting most of them back in. I find the head for AWS vs. bare-metal admin to be quite different. Being old school, I prefer metal.
I'm just not sure that those layers are actually functional. I see little reason why things couldn't be more like AWS if there were standardized ways to e.g. configure things. A lot that one deals with is glue between the turtles and not necessarily the other turtle.
Everything is glue between turtles.
It's glue between turtles all the way down.
(A problem now is that the glue is nonstandardised, and you've got vendor-specific glue, much of it with craptacular Web interfaces, at various levels. We used to have this in other parts of the stack, but they eventually got commoditised, and those particular layers went away. If you haven't done it before, crack open a Sendmail.cf file. If you have done it before, I'm truly sorry for the flashbacks.)
It's glue between turtles all the way down.
(A problem now is that the glue is nonstandardised, and you've got vendor-specific glue, much of it with craptacular Web interfaces, at various levels. We used to have this in other parts of the stack, but they eventually got commoditised, and those particular layers went away. If you haven't done it before, crack open a Sendmail.cf file. If you have done it before, I'm truly sorry for the flashbacks.)
Yup, even a basic understanding of CPU caches will go a long way to help you work out performance. It's very realistic to see 10-50x with just simple data layout patterns.
There's a danger too in having too simple a model of how a CPU works in your head. It doesn't scale well to how a real modern CPU really works. I see this a lot with developers who have a very oversimplified mental model of how memory management works, and more so with networking. Even if you do have an accurate appreciation for how a particular system functions, it can be dangerous to overly rely on that functioning - it means your software becomes tied to a particular CPU architecture, or network topology - and you don't get to take advantage of advances in the field.
Sometimes it is better to build your software on the assumption that underlying technology is a provider of black boxed services, and that over time the way in which those services are provided might change.
Sometimes it is better to build your software on the assumption that underlying technology is a provider of black boxed services, and that over time the way in which those services are provided might change.
It's even worse, I'm regularly meeting developers in my field (Android) which not only use only black boxes, they will refuse to build their own libraries if they're not provided by Google or other 1st party provider. Example: People didn't want to implement a FAB (which is essentially a shadowed colored circle with an icon in it) and demanded that Google provides the code to them O.o
Maybe I'm spent too much time hammering things together with C/C++, but this kind of mind set is really foreign to me O.o
Maybe I'm spent too much time hammering things together with C/C++, but this kind of mind set is really foreign to me O.o
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.
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.
Quick edit: Most of the dollars I've ever made are thanks to Rails. But I know how a computer works.
Yes. The analogy works all around, even the debates that pilots have about the Cirrus versus a simple aircraft resembles those debates of developers.
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.
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....
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.
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.
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.
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.
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.
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
[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.
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.
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.
Oh, I love them: atomatoflames, FMS Race, and Imsafe. Or the whole how to remember the 7500, 7600, 7700 emergency order: "Hi Jack, can't talk now, got an emergency."
I remember the emergency squawk codes as a rhyme:
75, Taken alive (7500 for a Hijack)
76, Radio nix (7600 for Lost comm/radio failure)
77, Going to heaven (7700 for Emergency)
I was taught largely the same but 76 was "in a fix".
Professional software development uses IDEs, linters, static typing, tests, and build scripts, which are all some variant of checklists. (either as "verify that this documented list of conditions is true before you run for real", or "do things in this documented order")
There's also some (much more experimental) work on provably-correct programs, i.e. that can detect whether certain posited conditions will hold for all cases when the program is run: see Coq, Liquid Haskell, Idris, Dafny, and Why3.
There's also some (much more experimental) work on provably-correct programs, i.e. that can detect whether certain posited conditions will hold for all cases when the program is run: see Coq, Liquid Haskell, Idris, Dafny, and Why3.
[deleted]
I always recommend the checklist manifesto - it also explores checklists in the medical industry and the quality/quantity usage tradeoffs.
Great recommendation - going to buy it thanks.
For anyone interested: https://www.amazon.co.uk/Checklist-Manifesto-Things-Right-Ga...
For anyone interested: https://www.amazon.co.uk/Checklist-Manifesto-Things-Right-Ga...
I remember trying to write down the weather listen to weather radio. It was a long list a jumble of letters and numbers it was one of the things I actually could do well.
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.
Again, my experience. They had to let them go, although they are very bright and likely I'd hire a pilot again.
It sounds like they were a bad fit for the job, but that's not true for all programming jobs.
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.