Why do planes crash?
Lessons for Junior & Senior Developers
Michael Toppa
@mtoppa
April 26, 2017
RailsConf, Phoeniz AZ
I’ve been a web developer for over 20 years, since the days of HTML 1.0, when web pages were first painted on cave walls.

I work for ActBlue Technical Services. ActBlue is a nonprofit tech organization, and we build fundraising software for Democratic campaigns and committees, and also
nonprofits.

I’m here today to talk to you about some interesting lessons I learned from reading this book…
Gladwell looks at successful people in many different kinds of careers. A key theme of his book is that outcomes we often attribute to the abilities or mistakes of
individual people are often better explained by looking at systematic or environmental factors.

He devotes one chapter to plane crashes, and I think there are lessons here for developers as well.
Why do planes crash?
There are many reasons…
One of the key reasons is poor communication
among the cockpit crew
There is typically a Captain and a First Officer (the co-pilot). During a flight, sometimes the First Officer is flying the plane, and sometimes the Captain. Typically the
Captain has more experience. A common communication problem when there are different levels of seniority between the two pilots is the junior pilot using what’s called
“mitigated speech” in addressing the senior pilot.
Mitigated speech
When we try to downplay or sugarcoat the
meaning of what we say, because we’re:
Being polite
Feeling embarrassed
Being deferential to authority
What happens is the junior pilot is being deferential to the authority of the senior pilot. This happens with developers too. The junior person will typically communicate
using hints if they think the senior person is doing something wrong or overlooking something. They worry using a more direct approach might be seen as
confrontational, or insubordinate, or that they’ll embarrass themselves if they’re wrong.
“A hint is the hardest kind of
request to decode and the
easiest to refuse”
The problem is…

Let’s look at a couple examples
1982 Air Florida Crash
The plane had a problem with wing ice before takeoff. This is a serious problem. It can affect the lift force of the wings and lead to loss of control of the plane. The First
Officer is very aware of this…
1982 Air Florida Crash
First officer: “Look how the ice is just hanging
on his, ah, back, back there, see that?”
First officer, again: “Boy, this is a, this is a
losing battle here on trying to de-ice those
things, it gives you a false sense of security,
that's all it does.”
This is from the black box recordings recovered after the crash, and this is the first officer talking before take-off.

He doesn’t speak directly. Instead he drops hints. He doesn’t come out and say “I strongly advise against taking off. I’m very concerned the wing ice will make us lose
control and crash.”
1982 Air Florida Crash
The captain doesn't get the hints, and the plane plunges into the Potomac river a few minutes after take off. 78 people died.
1990 Avianca Crash
Another example…

Planes are normally low on fuel when landing, but this flight is literally running on empty

And the captain is exhausted
1990 Avianca Crash
First officer to ATC: “Climb and maintain three
thousand and, ah, we're running out of fuel, sir”
ATC responds with a command to continue
circling, and asks for confirmation it's ok.
First officer to ATC: “I guess so. Thank you very
much”
The first officer’s speech is so mitigated that the pilot and air traffic controller may think he’s just sharing ordinary information, not that they are literally minutes away from
running out of fuel.

A flight attendant (the only survivor among the crew) enters the cockpit, and the engineer makes a throat-cutting gesture to her
1990 Avianca Crash
Two engines flame out and the plane crashes. 73 people died.
Crashes are more common with
the Captain in the flying seat
Plane crashes are always thoroughly investigated, and what’s been found, and this is counter-intuitive, is that…
“Planes are safer when the least
experienced pilot is flying, because
it means the second [more
experienced] pilot isn't going to be
afraid to speak up”
There are lessons here for both junior and senior developers
Lessons for Junior Developers
When you see something, say something
You have an asset no one else has:
“The beginner’s mind”
When you see something that looks like a problem, in the code, in your workflow, or something else, communicate your concerns clearly but of course politely. 

I know it can be intimidating. If you’re not comfortable doing it in person, use email, use Slack, etc

You haven’t yet become acculturated into “this is how we’ve always done things,” which can cause senior people in your organization to develop blind spots. You may
see problems no one else will see, or have insights that will not occur to anyone else.
Lessons for Junior Developers
One of two things should happen…
You’ll be right, and appreciated*
You’ll be wrong, and appreciated*
You saw a problem no one else saw and stopped it from becoming a bigger issue, and you’ll be recognized for that.

Or…

You’re showing you are thoughtfully engaged, and if you have a good mentor, they’ll use it as a learning opportunity for you.

But I’ve put asterisks on these. I’ve met junior developers who’ve become discouraged in their careers due to poor mentorship. What usually happens is, the senior
people don’t have time to help them, and they’re just given menial, repetitive tasks that don’t lead to learning.
Lessons for Senior Developers
Be good mentors
Be kind

Be solicitous

Be an active listener

Be patient

Be humble

Be encouraging

A great way to start is pair programming, but let the junior developer drive, and you can get the same benefits as pilots: the junior person learns, and the senior person
provides guidance and safety

Why do planes crash? Lessons for junior and senior developers

  • 1.
    Why do planescrash? Lessons for Junior & Senior Developers Michael Toppa @mtoppa April 26, 2017 RailsConf, Phoeniz AZ I’ve been a web developer for over 20 years, since the days of HTML 1.0, when web pages were first painted on cave walls. I work for ActBlue Technical Services. ActBlue is a nonprofit tech organization, and we build fundraising software for Democratic campaigns and committees, and also nonprofits. I’m here today to talk to you about some interesting lessons I learned from reading this book…
  • 2.
    Gladwell looks atsuccessful people in many different kinds of careers. A key theme of his book is that outcomes we often attribute to the abilities or mistakes of individual people are often better explained by looking at systematic or environmental factors. He devotes one chapter to plane crashes, and I think there are lessons here for developers as well.
  • 3.
    Why do planescrash? There are many reasons… One of the key reasons is poor communication among the cockpit crew There is typically a Captain and a First Officer (the co-pilot). During a flight, sometimes the First Officer is flying the plane, and sometimes the Captain. Typically the Captain has more experience. A common communication problem when there are different levels of seniority between the two pilots is the junior pilot using what’s called “mitigated speech” in addressing the senior pilot.
  • 4.
    Mitigated speech When wetry to downplay or sugarcoat the meaning of what we say, because we’re: Being polite Feeling embarrassed Being deferential to authority What happens is the junior pilot is being deferential to the authority of the senior pilot. This happens with developers too. The junior person will typically communicate using hints if they think the senior person is doing something wrong or overlooking something. They worry using a more direct approach might be seen as confrontational, or insubordinate, or that they’ll embarrass themselves if they’re wrong.
  • 5.
    “A hint isthe hardest kind of request to decode and the easiest to refuse” The problem is… Let’s look at a couple examples
  • 6.
    1982 Air FloridaCrash The plane had a problem with wing ice before takeoff. This is a serious problem. It can affect the lift force of the wings and lead to loss of control of the plane. The First Officer is very aware of this…
  • 7.
    1982 Air FloridaCrash First officer: “Look how the ice is just hanging on his, ah, back, back there, see that?” First officer, again: “Boy, this is a, this is a losing battle here on trying to de-ice those things, it gives you a false sense of security, that's all it does.” This is from the black box recordings recovered after the crash, and this is the first officer talking before take-off. He doesn’t speak directly. Instead he drops hints. He doesn’t come out and say “I strongly advise against taking off. I’m very concerned the wing ice will make us lose control and crash.”
  • 8.
    1982 Air FloridaCrash The captain doesn't get the hints, and the plane plunges into the Potomac river a few minutes after take off. 78 people died.
  • 9.
    1990 Avianca Crash Anotherexample… Planes are normally low on fuel when landing, but this flight is literally running on empty And the captain is exhausted
  • 10.
    1990 Avianca Crash Firstofficer to ATC: “Climb and maintain three thousand and, ah, we're running out of fuel, sir” ATC responds with a command to continue circling, and asks for confirmation it's ok. First officer to ATC: “I guess so. Thank you very much” The first officer’s speech is so mitigated that the pilot and air traffic controller may think he’s just sharing ordinary information, not that they are literally minutes away from running out of fuel. A flight attendant (the only survivor among the crew) enters the cockpit, and the engineer makes a throat-cutting gesture to her
  • 11.
    1990 Avianca Crash Twoengines flame out and the plane crashes. 73 people died.
  • 12.
    Crashes are morecommon with the Captain in the flying seat Plane crashes are always thoroughly investigated, and what’s been found, and this is counter-intuitive, is that…
  • 13.
    “Planes are saferwhen the least experienced pilot is flying, because it means the second [more experienced] pilot isn't going to be afraid to speak up” There are lessons here for both junior and senior developers
  • 14.
    Lessons for JuniorDevelopers When you see something, say something You have an asset no one else has: “The beginner’s mind” When you see something that looks like a problem, in the code, in your workflow, or something else, communicate your concerns clearly but of course politely. I know it can be intimidating. If you’re not comfortable doing it in person, use email, use Slack, etc You haven’t yet become acculturated into “this is how we’ve always done things,” which can cause senior people in your organization to develop blind spots. You may see problems no one else will see, or have insights that will not occur to anyone else.
  • 15.
    Lessons for JuniorDevelopers One of two things should happen… You’ll be right, and appreciated* You’ll be wrong, and appreciated* You saw a problem no one else saw and stopped it from becoming a bigger issue, and you’ll be recognized for that. Or… You’re showing you are thoughtfully engaged, and if you have a good mentor, they’ll use it as a learning opportunity for you. But I’ve put asterisks on these. I’ve met junior developers who’ve become discouraged in their careers due to poor mentorship. What usually happens is, the senior people don’t have time to help them, and they’re just given menial, repetitive tasks that don’t lead to learning.
  • 16.
    Lessons for SeniorDevelopers Be good mentors Be kind Be solicitous Be an active listener Be patient Be humble Be encouraging A great way to start is pair programming, but let the junior developer drive, and you can get the same benefits as pilots: the junior person learns, and the senior person provides guidance and safety