The Good Bad Bug: Fail Your Way to Better Code

by Jessica Rudder

The video 'The Good Bad Bug: Fail Your Way to Better Code' presented by Jessica Rudder at RubyConf AU 2018 discusses the importance of understanding and embracing failure in software development. Rudder begins by recounting personal experiences that illustrate how failure can lead to learning and improvement. Through a series of anecdotes, she emphasizes that failure is often necessary for innovation and growth, especially in programming. Key points include:

Understanding Failure: The speaker defines failure as a deviation from an expected or desired outcome rather than something purely negative. This shift in perspective allows developers to learn from their mistakes.
Learning from Aviation vs. Road Accidents: Rudder compares the data-gathering approaches to aviation incidents versus road accidents, highlighting that aviation treats failures as systemic events that provide learning opportunities, whereas road incidents often lead to individual blame without significant data collection.
The Good Bad Bug Concept: She introduces the term "good bad bug" in video game development, where an unexpected failure led to innovative mechanics, as seen in 'Space Invaders' and 'Grand Theft Auto.'
Documentation and Patterns: Rudder stresses the need for documenting failures and identifying patterns through the data collected from these experiences. This documentation aids in recognizing working habits and learning preferences, ultimately improving coding practices.
Creating a Supportive Environment: She encourages fostering a culture that celebrates vulnerability and open communication within teams. This approach helps individuals learn from their mistakes and feel safe to express their struggles without fear of judgment.

Rudder concludes by urging attendees to build communities that support sharing experiences around failure and learning. By modeling vulnerability at the leadership level, organizations can create an atmosphere of trust that encourages collective growth and success in coding and beyond.

00:00:06 Someone asked for a shout-out for Jordan, who injured his ankle but still showed up to the conference.

00:00:12 Thank you so much to the sponsors, and a special mention to Envato for designing the template that I'm planning to build eventually into my personal website.

00:00:22 I met someone from North Dakota, which is quite surprising because it's like the gold star among states in the US. I didn't expect to meet someone from North Dakota here in Australia.

00:00:35 But now, all of you have met someone from there too. So here I am, reaching out.

00:00:41 You can find me on Twitter, GitHub, and almost everywhere else online. When I was 26, I decided that I wanted to learn how to fly. My friends and family were very skeptical, reminding me that I was afraid of heights, lacked experience driving a car, and along with other criticisms, they thought it was a bad idea.

00:01:06 Despite all that, I refused to let anyone clip my wings.

00:01:14 Now, six months into training, I'm on final approach to runway 21 in Santa Monica after a routine flight. I eased back on the throttle, tilted the plane's nose to flair, and floated gracefully—or less so—to the ground. Suddenly, a sharp pull on the yoke made the plane jerk to the side.

00:01:39 My instructor took control immediately. I thought, 'Oh no, I've got the plane,' but he brought us safely to a stop on the runway. We radioed the tower to report the issue and exited the plane to inspect the damage—it turned out to be a flat tire.

00:01:59 As my heart rate returned to normal and realizing no one was injured, it became clear that it was no big deal. All we needed to do was get the plane towed back for a tire change. The runway would have been blocked for less than five minutes.

00:02:15 To my surprise, my instructor said he would drop me off at the classroom and then start filling out FAA paperwork. My heart rate jumped again. Nobody got hurt, and the plane was undamaged—so why the paperwork?

00:02:27 In addition to being not the greatest fan of paperwork, I was concerned my instructor would get in trouble for my flat tire. However, it turns out that the FAA collects data on every event, no matter how minor, such as a tiny flat tire on a four-seater airplane. They do this to work out patterns that help implement safer systems.

00:02:48 They understand that gathering more data allows for better conclusions. But they also know people dislike paperwork or getting in trouble. Thus, they ensure pilots aren't punished for mistakes as long as there are no injuries or illegal acts involved.

00:03:04 So, if you don't fill out the paperwork, you can be in trouble, but if you do, everything is fine. Consider the contrasting approach we have for road accidents.

00:03:22 When I was 12, I was driving home from a car dealership in a shiny new car—my parents' first new car. As we sat at a stoplight, we were suddenly rear-ended.

00:03:35 My dad got out to check on the other driver, a nervous 16-year-old boy. Everyone was okay, and the only damage to our car was a puncture on the bumper from the other kid's license plate. My dad looked it over and said, 'That's what bumpers are for.'

00:03:52 He told the boy to be careful, and we all got back in our slightly less shiny car. No paperwork was filed; no data was gathered.

00:04:09 There is not a single organization that actually collects data on road accidents, at least in the United States, but I've found none in other countries either. It's typically handled by local agencies, like the police.

00:04:23 The police get irritated if you call about something as insignificant as a flat tire. They're likely to just ask if anyone was hurt; if not, they might tell you to stop wasting their time. Therefore, the accident is never recorded.

00:04:41 These two approaches lead to drastically different outcomes. According to recent stats from 2015, for every one million miles people in the U.S. travel by car, there are 3.1 deaths, whereas for the same distance traveled in a plane, only 0.5.

00:04:53 I know that dealing with fractions like these can be complicated, but to illustrate, for every 64 people who die traveling in a car, only one person dies while traveling by plane.

00:05:06 Now you might think, 'Well, everyone knows Americans drive terribly.' While this may be true—it does mean we're about 32% worse than Australia regarding road deaths. This means that you are looking at approximately 42 deaths per billion miles traveled versus one per air mile traveled.

00:05:30 There is indeed something interesting hiding in these numbers. We have different approaches leading to incredibly different outcomes, and the key difference lies in how each approach handles failure.

00:05:47 It turns out that failure is a crucial part of learning. However, I don't want to keep throwing around the term 'failure' without ensuring we're all on the same page about its definition.

00:06:01 What is failure? For many of us, it might be that sinking feeling in your stomach when you don't know the answer in a tense situation, and someone is angry, perhaps even spitting their frustration at you. In those moments, we feel like we shouldn't have even gotten out of bed that morning.

00:06:19 I certainly relate to that definition of failure. However, while preparing for this talk, I wanted to move beyond my own perspective.

00:06:31 I began looking into what other people defined as failure. Some mentioned it's merely the absence of success, which I thought was a decent definition. But then I realized it leads to another question: what is success?

00:06:51 That same group suggested success is the absence of failure—less than ideal! On the other hand, people who study failure's impact define it as a deviation from an expected or desired result.

00:07:10 This definition resonates with me, primarily because it's a measurable outcome. So, for the remainder of this talk, let's adopt this definition of failure.

00:07:30 It's essential to note that software engineers encounter failure repeatedly. You are constantly facing failures until you hit that one moment when everything aligns, and you succeed.

00:07:50 You might think programming would be the perfect place to learn from failure, yet this concept has been often fully realized only in video game development.

00:08:01 Take Space Invaders for instance. It's that old arcade game where you control a cannon firing at descending aliens. Initially, the game was designed for a constant alien speed that only increased when reaching the next level.

00:08:24 But it turned out the original design didn't work as planned. Due to technical limitations back in 1978, the originally intended behavior couldn't be achieved.

00:08:39 The developer Tomohiro Nishikado was supposed to design the aliens to remain at a constant speed throughout the entire level, only speeding up once the player reached the next screen. Instead, when the game was initially launched, it resulted in confusing slow movement.

00:08:58 However, workers noticed that as players eliminated aliens, the speed picked up, resulting in a thrilling gaming experience.

00:09:06 Despite initially intending for a static level difficulty, the unexpected failure led to a new game mechanic. This ignited a revolution in game design, proving that failure can inspire innovative ideas.

00:09:23 The difficulty curve became a standard in gaming, and many game developers learned valuable lessons from this failure. It illustrates that failure isn't something to hide from; instead, it's an opportunity to gain insights.

00:09:42 Research shows that there's far more information embedded in failure than in success. Think about it: success usually presents itself as a simple checkmark or a thumbs-up, leading you to the next task.

00:10:03 However, failure can be indicated through an error message which provides a wealth of details, helping you pinpoint the exact line of code that has issues.

00:10:19 With just a little effort, you can find the information provided from various sources discussing similar errors. You learn not only what doesn't work but also how to fix it.

00:10:35 Video game development has a long history of learning from mistakes, and it has a name: the good bad bug. This concept came into play for a group of developers in the 90s working on a racing game.

00:10:55 The game was initially designed so players would race through city streets, chased by police cars. If the police caught them, they would lose the race, but one significant issue arose.

00:11:15 The algorithm for police behavior was incorrectly coded, resulting in overly aggressive cops that would crash into the racers instead of stopping them.

00:11:34 During beta testing, players found this newfound chase mechanic incredibly fun and began to forget about the race entirely.

00:11:52 This shift led to an entire rebranding of the game, which eventually birthed the Grand Theft Auto series.

00:12:02 Had the developers panicked and attempted to cover up their mistake, they would have lost an opportunity to innovate in the gaming industry.

00:12:19 In larger projects like video games, hundreds or even thousands of hours have usually been invested before developers ever write a single line of code.

00:12:37 This phase is usually captured in a living document known as the Game Design Document (GDD). Changes are allowed, but altering it can be significant later in the process.

00:12:55 Silent Hill developers faced such reality when they started building their game strictly to the specifications provided.

00:13:11 However, they encountered a major issue: the PlayStation's graphics card could not render all the buildings and textures properly.

00:13:27 This caused buildings to pop into existence as the player walked closer, breaking the atmosphere that horror games rely on.

00:13:44 Normal and eerie gameplay was disrupted by these visual flaws.

00:13:51 Instead of blaming one another, the team at Konami sidestepped the issue by introducing a dense, eerie fog into the game.

00:14:07 This fog was simple for the graphics card to render and effectively masked the popping textures, creating an atmosphere that was even creepier and more engaging.

00:14:27 In a fascinating turn of events, this fog concept became a hallmark of the Silent Hill franchise, demonstrating how failure can lead to iconic features.

00:14:39 These programming examples illustrate approaches to failure seen in high-stakes situations like aviation and automobile accidents.

00:14:58 Systems approach in aviation has saved countless lives because accidents are treated as learning opportunities, gathering data for trends.

00:15:16 When accidents occur, investigators delve deeper. For example, if a pilot was exhausted, they analyze schedules, staffing, and more to uncover contributing factors.

00:15:30 In contrast, with road accidents, almost always the blame falls on the driver. 'She was reckless,' or 'He doesn't know how to drive,' becomes the typical narrative.

00:15:46 Airplane accidents are treated as systematic failures, while road accidents are viewed as individual failures. With judgment being a constant threat, people tend to hide errors rather than acknowledge them.

00:16:08 How many times have you seen someone roll through a stop sign? If caught, they quickly deny it with excuses instead of admitting the mistake.

00:16:25 We're not all pilots, but there's a lot we can learn from their approach. If we establish systems to track our code failures, we can achieve better outcomes.

00:16:41 So what should these systems look like? I think, broadly speaking, there are three main principles. First, avoid placing blame.

00:16:57 Second, collect substantial data; and third, identify patterns from what you gather.

00:17:09 Step one is understanding that you are not the problem. For many of us, that can be a tough mindset to adopt.

00:17:21 When struggling with learning, it's all too easy to beat ourselves up, especially when others seem to grasp concepts faster.

00:17:40 Aviation failures aren't merely blamed on individuals; there's a deep desire to understand what went wrong within the entire system without condemning a person.

00:18:00 In one case, an error occurred when a pilot entered the wrong destination in the flight computer. Investigators heard him yawn on the recording, recognizing he was tired.

00:18:16 Instead of simply blaming him for being tired, they investigated further to understand why he was fatigued, looking deeper into his circumstances.

00:18:30 They examined not just the sleep he had had but the impact of the cockpit equipment—essentially trying to understand the context around the issue.

00:18:46 Through this comprehensive evaluation process, aviation failures aim to derive systemic insights rather than merely condemning individuals.

00:19:00 If you take away from failure the notion that you are not good enough, you miss the valuable lessons failure can teach you.

00:19:16 For now, if you can't quiet that inner critic, try to focus on the broader system instead of beating yourself up. With enough time, that inner voice might transform.

00:19:30 Step two: document everything. This includes both the key failures and the trivial ones, as even small issues might contribute to bigger problems.

00:19:46 Given my flat tire story, the FAA wanted to record that information, too—what wear and tear led to it and if there were risks involved because of lax oversight.

00:20:03 Documenting even tiny errors could prevent major meltdowns. To gather this information effectively, choose a format that works for you.

00:20:20 Be specific in noting inputs and outcomes. For instance, rather than writing 'reactive stupid' to describe a problem with component dispatch, clarify the components involved and the exact error.

00:20:36 The final step is to use all the data you've accumulated to extract meaningful patterns about your working habits and preferences.

00:20:50 For example, knowing you perform better when well-rested enhances your ability to gauge when to tackle specific challenges.

00:21:05 You might also discover that certain environments or rituals help maximize your learning potential.

00:21:18 Keeping a track record allows you to identify what works best for your growth, which ultimately influences your programming success.

00:21:35 Documentation becomes key, linking your learning experiences to real outcomes, like attempting to wire up a form for your latest app.

00:21:54 With those records in hand, you can diagnose issues, refine how you gather information, and gain valuable insights into what goes wrong.

00:22:10 It's critical for both individuals and teams to learn from failures as it fosters collaboration and knowledge sharing.

00:22:27 For instance, studies show that hospitals with learning-oriented cultures often deliver better patient outcomes without shying away from addressing errors.

00:22:47 When nurse managers focus on creating an atmosphere where mistakes are openly discussed, their facilities tend to thrive.

00:23:07 However, those in blame-oriented environments suffer lower results, as individuals are often more concerned about hiding their mistakes than addressing and learning from them.

00:23:32 Thus, allowing a workplace culture focused on learning rather than blame leads to much better development teams.

00:23:32 Every individual in the team should strive for that atmosphere. The process might not work flawlessly at first; it's common to make adjustments along the way.

00:23:50 Hope will emerge as you get comfortable using these strategies, eventually leading to more successful coding experiences.

00:24:06 While this is usually when I conclude my talk, I found myself often faced with questions from attendees, notably from women in minority roles.

00:24:23 They would express concerns about their environments, asking, 'Do you think it's safe for me to fail publicly?' If I'm honest, I'd say no.

00:24:42 This is my experience; some might find the place where they can fluently talk about things they're struggling with and share their journey.

00:25:04 For context, in my early years learning to code, I wasn't often labeled as a gifted child because I was encouraged to grow beyond that label.

00:25:27 As I grew older, I realized the importance of asking questions and seeking clarity.

00:25:38 Over time, my career developed further, leading to a one-on-one conversation where my manager remarked about my struggles while learning to code.

00:25:55 To my surprise, my participation when learning was noticed, but later on when my workplace made layoffs, those misunderstandings made me rethink.

00:26:10 A misconception that had built around my engagements turned doubt into my own fears. Feelings of inadequacy rushed in while contemplating my future.

00:26:30 Ultimately, after refreshing my motives and inputs, I kicked off hiring at GitHub due to my exploratory mind during these challenging experiences.

00:26:49 What I request of all of you is to determine what risks are acceptable within your personal framework and adjust your expectations accordingly.

00:27:09 Keep sight of your goals and the journey ahead; the risks that should be feared may not involve your financial stability but should focus on your emotional resilience.

00:27:27 Don't forget to seek out communities and individuals willing to learn and collectively grow; consider how environments impact learning based on various backgrounds.

00:27:50 It can significantly lower the stakes for those less represented, allowing them to flourish. A supportive atmosphere assures confidence during trials and errors in education.

00:28:07 So, I encourage everyone to share their experiences to build a brave new community where all voices matter.

00:28:27 If I stumbled along the way, I've learned that sharing my challenges often carries more impact than the fears I feared speaking into existence.

00:28:44 Meanwhile, feel free to explore my YouTube channel, compchomp, where I upload tutorials and coding sessions. I'm also available on Twitter.

00:29:02 If there’s time, I'd be happy to address questions; if not, please reach out through my social media.

00:29:19 [Audience member asks about cultivating a space that promotes vulnerability among teams] One of our values at Culture Amp is to have the courage to be vulnerable.

00:29:37 If you want your team members to feel safe, the key lies in leadership modeling vulnerability and open communication regarding failure.

00:29:53 For example, when I worked in digital marketing, I once made a mistake that cost the company around thirty thousand dollars.

00:30:09 That moment, I panicked, but my co-founder reassured me by normalizing failure and sharing his own stories.

00:30:23 He guided me on how to learn from this experience. This approach eventually transformed into a culture where individuals felt they could express their concerns, allowing us to brainstorm solutions.

00:30:42 Seek from higher-ups to set the tone that allows everyone to own their mistakes and learn from them. Lastly, I believe in not silencing those who struggle in this field.

00:30:58 Your input or allowances foster strong bonds helping others overcome obstacles while amplifying their potential.

00:31:12 Ultimately, every effort to create this space contributes positively toward individual growth and collective progress.

RubyConf AU 2018