00:00:14.480
I'm too short to have the laptop on the podium, so if I keep working today, that's why. Awesome! Usually, when I give a talk, I've been one of the people who speaks in the afternoon. I've never had an audience that hasn't been fully warmed up before.
00:00:20.580
So I thought, okay, I can't just jump right into the talk; I have to warm people up first. I'll start with an introduction. My name is Jess Rudder, and I work at GitHub. You can find me as Jess Rudder pretty much everywhere, including Twitter. I love Twitter! I wanted to ease into the talk, and I thought about GitHub's big news with the Microsoft acquisition in the last couple of weeks—maybe there's some material there I could work with.
00:00:44.280
One of the advantages of working at GitHub, which they don’t make clear during the hiring process, is that you get to chat on Slack with Tender Love and Aaron. During the announcement, he was just a gold mine of puns. I thought that maybe I could take some of his rejected puns and work them into my talk. But then I remembered my very first Rails conference where DHH couldn't make it due to a scheduling conflict with a car race. Jeremy Daer gave the opening keynote and made a joke about DHH not being there because of a race. Everyone laughed after he pointed out, ‘Oh dear Lord, there's a race condition!’
00:01:14.900
Everyone laughed at Jeremy's pun. Then a day or so later, Aaron got up to give his talk and said, ‘I’m very mad at Jeremy,’ and proceeded to present evidence that Jeremy had stolen his joke. I thought, oh man, I really don't want Aaron to be mad at me, so I better not steal any of his puns! I hope this story has given you insights into our souls. I’m relieved that you guys laughed because puns are not something I usually do. I thought it would suck if no one laughed, but then I remembered my talk is about failures, so I can just pretend that was all part of the plan.
00:01:33.690
Since you laughed, I’ll segue with a story instead. This story starts like many tales of failure, with trying to learn something new. When I was 26, I decided to learn how to fly a plane. When I told my family, they all said I was crazy. Apparently, the fact that I was scared of heights, got motion sickness, and didn’t know how to drive a car proved I shouldn’t learn to fly. I felt determined though; no one was going to clip my wings! Now, six months later, I’m on final approach for runway two one in Santa Monica. I pull the throttle back gently and lift the nose of the plane, gliding gracefully onto the runway when suddenly the plane jerks to the right. My instructor yells, ‘I’ve got the plane!’ and takes over.
00:02:25.920
My heart starts settling down as we stop, and we step out to see what happened—it was just a flat tire. No big deal, it happens. I thought to myself, okay, awesome, everything's fine! But I was surprised when my instructor said, 'I’m going to drop you back at the classroom and then I’ll handle the paperwork.' All of a sudden, I was stressed out again because I didn't want to get him in trouble. It turns out that the FAA likes to collect data on events, big or small, and because they know people dislike paperwork and getting in trouble, they encourage it. As long as you didn't do anything illegal, no one got hurt, and you filed the paperwork timely, there would be no consequences.
00:02:45.870
Now, think about how different that is with automobile accidents. When I was 12, we were driving home from the Saturn dealership, which was the first brand-new car my parents had ever purchased—a shiny 1993 Saturn. As we sat at a stoplight, we were suddenly rear-ended. My dad checked to see that we were all okay and went to check on the other driver, a very nervous 16-year-old who was terrified of damaging the new car. Both cars were fine except for a tiny puncture wound on our bumper from the other car’s license plate. My dad just shrugged and said, ‘That’s what bumpers are for!’ No authorities were called, no paperwork was filed other than our memories. There’s no proof that accident ever happened.
00:05:34.260
These two approaches have led to very different outcomes. According to the most recent stats from 2015, for every billion miles traveled by car, 3.1 people in the United States died, but for every billion miles traveled by plane, only 0.05 people died. If you hold the miles traveled steady, that means there are 64 vehicle deaths for every one airplane death! This discrepancy reveals the key difference in how each approaches failure, as failure is an incredibly important part of learning.
00:06:21.150
Now, before delving deeper, it’s good to clarify what failure actually is. For some of us, failure might evoke that feeling when someone is harshly yelling at you, making you feel like nothing is going right and you shouldn’t even bother getting out of bed. I can relate to that feeling, but it’s challenging to measure. When preparing for this talk, I asked a lot of people what they think failure is. Many responded, ‘failure is the absence of success.’ When I asked about success, the answer was often, ‘success is the absence of failure.’ I realized that leaves us in a circular definition, which isn’t useful! However, researchers define failure as a deviation from expected and desired results.
00:07:18.440
As a programmer, I’ve noticed that programming often leads to deviations from expected results. I thought there would be a wealth of examples of learning from failure in programming, but what I found is that we don’t have a lot of documented examples except in video game development. One of my favorite examples is the game Space Invaders. Most of you are likely familiar with it—the old arcade game where you control a small cannon firing at descending row of aliens. Originally, the aliens were supposed to move at a consistent pace for the entire level and only speed up on the next level. However, due to technical limitations back in 1978, too many alien sprites on the screen slowed everything down.
00:08:07.350
The unintended outcome was that aliens sped up as more were destroyed, which the players loved! Players started creating stories about the aliens, saying, ‘Oh man, he knows he’s next!’ This engagement actually created an entirely new game mechanic—the difficulty curve! Before this, games were always consistent, getting harder only on the next screen. The developer, Tomohiro Nishikado, might not have read research on failure, but his experience capitalized on a lesson seen time and again: failure isn't something to run away from; it's an opportunity to learn.
00:09:01.650
In fact, it turns out that failure presents a greater learning opportunity than success because there’s more information encoded in failure. Think about it: what does success look like? A checkmark, a thumbs up, and perhaps a smile from your manager. But that doesn’t provide insight on what you should change. On the other hand, failure presents a wealth of information. When you analyze it, you know what went wrong and where it happened. If you have some experience with that type of failure, you might even know how to fix it.
00:09:59.070
Video game development has a long tradition of embracing mistakes. It's so essential that they even have a term for it: the ‘good bad bug.’ In the 1990s, developers working on a street racing game faced a problem where the cops were programmed too aggressively; they slammed into the racers instead of just pulling them over. Players found it more fun to evade police than to race, leading the developers to rework the entire game around that concept, which eventually became Grand Theft Auto. This programming error ended up creating one of the best-selling video game series of all time! Developers who recognized this flaw and adjusted their approach benefited tremendously.
00:12:43.540
Another example is from the Silent Hill developers, who discovered that the PlayStation’s graphics card couldn’t render all the buildings and textures they designed, causing them to pop in and out of existence. Instead of pointing fingers, the Konami team creatively added dense fog to mask the pop-in effect. The fog became a staple in the series and is integral to its ambiance. Just like in aviation, embracing failure and creativity helps in transforming problematic situations into successes.
00:14:20.290
The aviation industry exemplifies how to learn from failure. Every accident is treated as an opportunity to gather data and identify patterns. They ask deeper questions, such as, if a pilot was tired, what led to that? Were there enough rest periods? In contrast, in vehicle accidents, there’s frequently a focus on blaming the driver, resulting in individuals often concealing their mistakes to avoid repercussions. As developers, we can learn from aviation by creating systems to track and learn from our failures in programming.
00:15:17.060
To establish a system to learn from our failures, we should follow three steps: avoid placing blame, document everything, and abstract patterns from the data. First, it’s essential to avoid placing blame. In aviation, after a pilot made a critical error, they investigated to determine not just what happened, but why. The goal is to analyze the systemic causes of failure rather than blame individuals. In programming, if the takeaway from a failure is that you are not cut out for coding, that's the wrong lesson. Try to ignore that inner critic as you work through failures. The second step is documenting everything, including small issues. Small problems can snowball into bigger ones, just like the FAA catches small errors to fix patterns before they escalate.
00:26:29.520
The final step is to analyze the data you've gathered and search for patterns. By tracking when you work best and worst, you can make more informed adjustments to your workflow, like when to start coding or what environment helps you succeed. This process isn't solely for individuals; teams can also learn from failure. Studies have shown that hospitals focused on a learning culture, rather than a blame culture, often have better patient outcomes, even if they document more mistakes. When people feel free to make mistakes, they fix systemic issues instead of hiding their errors. Fostering a culture that promotes learning from failure will ultimately strengthen our teams.
00:30:27.850
Traditionally, I would end my talk here, but I've noticed something important. Many attendees, particularly women of color, approach me afterward, expressing that while they love my talk, they're unsure if it's safe for them to fail openly. Research indicates the further someone is from an idealized version of an engineer, the more dangerous it is to be seen failing. This bias means certain individuals cannot benefit from failures as others can. For them, I would advise presenting competence until they find a safer environment. For everyone else, let’s work on creating an industry atmosphere where failure is safe and learning is encouraged. Only then can we become better at our jobs and nurture the next generation of developers.
00:31:26.700
Thank you! I am Jess Rudder, and I love talking about code. I have a YouTube channel where I share code-related stories. Feel free to come up later; I have plenty of stickers!
