Lessons from "Outliers: The Story of Success" for software developers

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

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

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

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

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

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

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

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

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

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

11. 1990 Avianca Crash
Two engines flame out and the plane crashes. 73 people died.

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

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

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

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

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