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.

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.

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

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.

For anyone interested: https://www.amazon.co.uk/Checklist-Manifesto-Things-Right-Ga...

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.

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.

Quick edit: Most of the dollars I've ever made are thanks to Rails. But I know how a computer works.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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 !

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.

The money I will never get back and I'm still not sure it's worth it. But I sure have enjoyed the ride!

But thank you for the "chicken" insult, it made me laugh.

If I were a pilot, I would space out and die a horrible death.

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.

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.

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.

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

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

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.

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 read of German clerks during WWII who wouldn't surrender till they had finished typing a report. Even though the enemy was already there.

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.

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

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.

Coincidentally enough, such an article already exists:

http://www.thecaucus.net/#/content/caucus/tech_blog/373

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.