
How becoming a pilot made me a better programmer - janvdberg
http://nathanmarz.com/blog/how-becoming-a-pilot-made-me-a-better-programmer.html
======
falcolas
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
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
Don't let it discourage you. If it didn't work for him doesn't mean is not
going to work for you.

~~~
falcolas
I'll agree with this, but definitely recommend working with a good CFI, not
just a prior student building up hours.

------
poof131
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
Programmers should be able to trust procedures (interfaces) to do what they
want them to do.

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

~~~
nathanmarz
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...](http://nathanmarz.com/blog/the-limited-value-of-a-computer-
science-education.html)

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

~~~
whack
> 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](http://www.thecaucus.net/#/content/caucus/tech_blog/373)

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

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

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

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

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

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

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

~~~
dredmorbius
_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.)

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

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

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

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

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

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

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

------
throwaway26960
Doing anything in life makes you a better programmer.

------
simonswords82
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...](http://www.echo-
news.co.uk/news/842963.pilot_16_killed_in_plane_crash/)

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.

~~~
wheaties
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."

~~~
blendo
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)

~~~
simonswords82
I was taught largely the same but 76 was "in a fix".

------
igorgue
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
It sounds like they were a bad fit for the job, but that's not true for all
programming jobs.

