00:00:12.740
Cool! First of all, thank you all for coming out here today to spend your morning talking about failure. It’s a light topic, so I think DHH sort of set you up, and I’m just going to knock you down. As was mentioned, I'm Jess Rudder, and if you're the tweeting kind, that's my Twitter handle.
00:00:24.029
On to the show! All right, when I was 26 years old, I decided that I wanted to learn how to fly a plane. My friends and family were very skeptical. They had such words of wisdom as: 'You don’t even know how to drive a car, you get motion sick, you’re afraid of heights.' And all of this was 100% true, but I actually didn't see the relevance. You see, no one was going to clip my wings.
00:01:01.440
So, we’re now six months in, and I was on final approach for runway 21 in Santa Monica after a routine training flight. I eased back on the throttle, tilted the nose of the plane up a tiny bit, entered a flare, and floated gracefully, more or less, down to the ground. And suddenly, the plane jerked to the side. My instructor was like, 'I’ve got the plane!' I was like, 'Oh, you’ve got the plane!' He brought the plane to a stop on the runway.
00:01:35.810
As our hearts calmed down, we got out and looked at the damage: it was a flat tire. My heart rate finally calmed, and with the plane safely stopped, a flat tire really isn’t a big deal. You just have to tow it back to a maintenance garage and change the tire. The runway was going to be blocked for less than five minutes. So, I was actually really surprised when my instructor said, 'Hey, I’m going to drop you back off at the classroom and then I’ll come back to fill out the FAA paperwork.' My heart rate jumped right back up.
00:02:06.060
Whoa! Whoa! It’s just a flat tire! No one got hurt! Why does there have to be any paperwork? You see, in addition to not being the biggest fan of paperwork, I was also really worried that I had just gotten myself into a lot of trouble. But it turns out that the FAA collects details on all of it, big or small. Even a tiny tire blowout during the landing in my little four-seater plane—they want to gather as much data as possible to work out patterns that can help them implement safer systems.
00:02:30.890
They know that more data means they'll be able to draw better conclusions. But they also know that people really don’t like paperwork or getting yelled at. So, to make sure that pilots are willing to fill out these reports, they have a policy that if there were no injuries, nothing you did was illegal, and you fill out a report, there's not going to be any punishment. Now, think about the very different approach that we have to automobile accidents.
00:03:02.980
When I was 12 years old, I was riding home in a Saturn dealership in a shiny brand new car. It was the first brand-new car that my parents had ever purchased. We were sitting at a stoplight when, suddenly, we lurched forward. We had been rear-ended! My dad got out to check on the other driver, an incredibly nervous 16-year-old boy. Now, the other driver was fine, everyone in our car was fine, and the only damage was a small puncture on the bumper from the other car’s license plate.
00:03:29.680
My dad looked it over and said, 'Well, look, I guess that’s what bumpers are for.' He told the kid to be careful, and then we all piled back into our slightly less shiny car and drove home. No paperwork was filed, no data was gathered. In fact, there's not a single agency out there collecting data on car issues—it’s usually handled by local agencies like the police.
00:03:42.669
They do not like it if you call them up to let them know about something as trivial as a flat tire. Heck, you can have an accident where two cars actually bump into each other, and as long as no one is injured and no one wants to make an insurance claim, this will never end up in any records anywhere. So, these two different approaches have actually led to very different outcomes.
00:04:13.460
I looked at the most recent stats available, which were for 2015, and for every 1 billion miles people in the U.S. travel by car, 3.1 people die. For every 1 billion miles people in the U.S. travel by plane, there are only 0.05 fatalities. Now, if you're like me, decimals, especially when you're talking about a fraction of a person, can be a bit hard to wrap your mind around, so this is a bit easier if you hold the miles traveled steady: 64 people die traveling in cars for every one person that dies traveling in a plane.
00:04:44.060
Now, there is something very interesting going on here. We have two different approaches that lead to two very different outcomes, and the key difference is actually how each approach deals with failure. You see, it turns out that failure isn't something that you should avoid; it's a way to learn. Now, before we go much further, it's probably a good time to make sure we're all on the same page when we talk about failure.
00:05:06.070
So, what is failure? I think for some of us, it might be that sinking feeling in the pit of your stomach when something didn’t go right, and the person is yelling at you with an angry face, and you're thinking, 'Why did I even bother getting up this morning?' I can absolutely relate to that. As I was prepping for this talk and looking at what different people said, I found a lot of people who were like, 'Oh, failure? That one's simple. It's the absence of success.' I was like, 'Sweet! What's success?' And they were like, 'So easy! It's the absence of failure.' Oh, not really helpful!
00:05:37.420
But researchers actually have a very specific definition of failure: failure, to them, is the deviation from expected and desired results. And that’s not bad! I honestly think there’s some truth in all three of these definitions, but that last one, deviation from expected and desired results, is something that you can actually test and measure. So, we’re going to stick with that one for now.
00:06:07.090
Now, I couldn’t actually find any definitive data on this, but I think as developers we have more results that deviate from our expectations than just about any other group of people. You would think that programming would be the perfect place to learn from failure, but one of the few places where I could actually find people routinely capitalizing on failure was in video game development.
00:06:44.300
One of my favorite examples of this is with the game Space Invaders. You guys sort of know the game Space Invaders, right? It’s the old arcade game where you control a small cannon at the bottom that’s firing at a descending row of aliens. As you defeat more aliens, they speed up, making them harder to shoot, right? Well, that actually was not how the game was supposed to work.
00:07:10.810
The developer, Tomohiro Nishikado, had planned for the aliens to remain at a constant speed the entire time, no matter how many aliens you destroyed. There would not be a speed increase until the next level, and he wrote the code to do exactly that. There was just one problem: he had designed the game for an ideal world, and I don’t know how much you know about 1978, but 1978 was far from ideal.
00:07:30.880
He’d actually placed more characters on the screen than the processor could handle, and as a result, the aliens chugged along at first and only reached their intended speed once enough of them had been destroyed. Now, Nishikado had a few ways of dealing with this. He could have shelved the project until processor speeds were fast enough, and that might seem silly, but maybe he had a vision that he was not going to compromise.
00:08:07.510
He could also have modified the game design, putting fewer aliens on the screen so that it could run at the constant speed that he wanted. But instead of being rigid and insisting on his original vision, he decided to have people test it out, and they absolutely loved it. They got so excited as things sped up; it projected emotions on the aliens. They were like, 'Oh, these guys are getting scared! I'm taking them out!' They were trying to speed up because they knew I was about to kick their butt.
00:08:32.790
It was so popular that he kept that in the game, and the failure was actually responsible for creating an entirely new game mechanic: the difficulty curve. So before this, games would always have the exact same difficulty for an entire level, and it wasn't until you got to the next level that things would actually become more difficult. After this, all bets were off—things could get difficult at any point, whenever the developer pleased.
00:09:02.570
Now, I don’t know if the developer here had read the studies, but he was actually capitalizing on a lesson that I see time and again in the research about failure. Failure is not something to hide from; it's something to learn from. In fact, it turns out that failure presents a greater learning opportunity because there’s more information encoded in failure than in success.
00:09:37.460
Think about it. What does success usually look like? A check mark, a thumbs up, a smile from a manager. What did you actually learn? Well, there's research on this. Research shows that people and organizations that don’t experience failure become rigid because the only feedback they get tells them just to keep doing the exact same thing you're doing. Make any changes because you're already winning, buddy—don't change anything!
00:10:07.500
Failure, on the other hand, looks a lot more like this: okay, look at this! Look how much information is available in this error message! If we read it closely, we can figure out exactly what went wrong. We know which line in the code has an issue, and if you have some experience with this particular error message, we probably know what that issue most likely is.
00:10:44.670
Even if we've never seen it before, we’re just a quick search away from pages and pages' worth of information about this particular failure. Now that we've had an experience with an approach that didn’t work, with a bit of effort, we could actually figure out how to write something that does work.
00:11:17.610
Now, video game development has a long and honored history of grabbing hold of mistakes and wrestling them into successes. In fact, the concept of exploiting your failures to make your program better is so important it actually has a name: they call it the good bad bug. Now, having space to learn from their failures actually came in very handy for a group of developers that were working on a street racing game in the ‘90s.
00:11:50.350
So the concept for the game had players racing through city streets while being chased by cop cars. If the police caught up with you and pulled you over before you got to the finish line, you lost. There was just one problem: the developers got the code for the algorithm just a tiny bit wrong. Instead of law-abiding police officers trying to pull you over, you had these super aggressive cops trying to slam into your car, and they would do it at full speed, no matter what you did.
00:12:30.610
The beta testers actually had way more fun avoiding the cops than they ever had with the racing game. As a result, the entire direction of the game switched up, and the Grand Theft Auto series was born. So just think about that for a moment: the core concept of the best-selling video game franchise of all time in history ever would have been lost if the developers had panicked and tried to cover up the fact that they screwed up the algorithm.
00:12:56.430
They made a mistake, but instead of freaking out, they thought, 'All right, let's see what happens.' And the cash came in! Now, there are actually some larger programs where hundreds, if not thousands, of hours of work have already been done by product leads, designers, and businesspeople before developers ever get to write their first line of code. In game development, the work is encapsulated in a document called the Game Design Document (GDD).
00:13:31.610
Now, the GDD is considered a living document; however, it's a pretty big deal for changes to be made late in the game. It means that tech requirement pages need to be redone, art pages need to be redone, release dates have to be pushed back, budgets might be off—you get the picture. It’s a big deal to change this.
00:14:03.440
But that was actually the unhappy reality that the Silent Hill developers were facing. They'd started out building the game to the GDD specs, but there was one tiny problem: Pop-In. You see, the PlayStation’s graphics card couldn’t render all of the buildings and the textures in a scene. So, as you walked forward, buildings would suddenly pop into existence, and blank walls would magically have a texture.
00:14:39.700
As you can imagine, that distracts people from the game. A horror game is very dependent on atmosphere that pulls the player into the game's universe, so this was kind of a game-breaking issue. Now, it would have been easy for every single person involved to start pointing fingers at everyone else. After all, everyone had sort of played their part: from the designers who put just one or two more buildings in the background to the tech team that decided to make it for the PlayStation instead of the more powerful 3DO, to the business team that determined the release date.
00:15:18.700
There was not a single individual anywhere along the line that had made an obviously bad call. There were just a bunch of tiny issues that sort of snowballed into a big problem. You see, the entire system had failed, but instead of running from the failure, the Konami team sidestepped it. They found a workaround: they filled the world with a very dense, eerie fog. It turns out that fog is actually pretty lightweight for a graphics card to render.
00:15:59.520
So now it obscures distant objects, meaning you couldn’t really see buildings and textures on the horizon popping in anymore. As an amazing added bonus, it’s really, really creepy! In fact, it was so creepy that this fog became a staple of the Silent Hill series long after graphics cards had caught up and become powerful enough that popping wasn’t an issue anymore.
00:16:38.850
So that’s another example of success being ripped from the jaws of defeat simply by embracing your failures. Now, these examples from the programming world illustrate what’s happening at our more high-stakes examples in aviation and automobile accidents. You see, the aviation system saved so many lives because accidents are treated like lessons we can learn from.
00:17:11.510
Data is gathered, aggregated, and patterns are identified. If an accident was caused by a pilot being tired, they never just stop right there. They look at pilot schedules, staffing levels, and flight readiness checklists to determine what contributed to that exhaustion. In contrast, who do we usually blame for road accidents? Yeah, the driver! 'Oh, she was reckless! That dude does not know how to drive!'
00:17:44.090
In other words, airplane accidents are always treated as failures of the system while car accidents are treated like failures of individuals. And with all that judgment going around, it’s no wonder that people spend so much time trying to cover up their errors. They think, 'I definitely stopped at that stop sign; that’s the guy who went through it!'
00:18:17.030
So, they spend time covering it up rather than just acknowledging the failures and learning from them. Now, not everyone in this room is a pilot, but I actually think we have a lot to learn from how aviation handles failure. If we're willing to use a system to track and learn from our failures as we write code, we’re actually going to be much better off.
00:18:51.900
That sort of begs the question: what should that system look like? Now, in broad strokes, I think there are three very important pieces that the system would need. The first one is to avoid placing blame. We’re going to need to collect a lot of data, and then we're going to have to abstract patterns. So, step one: make sure that you understand that you are not the problem.
00:19:34.860
Cool—that is much easier said than done, right? I mean, learning not to beat yourself up over a failure and mistakes—that’s probably like a whole talk in and of itself or like a whole lifetime of self-discovery and work. But with aviation failures, one thing to note is that they never just stop at the top level of blame.
00:20:09.020
There was actually a case where the pilot made a critical error by dialing in the wrong destination in the flight computer, causing a wreck. On the cockpit recording, they could clearly hear the pilot yawn and say, 'I’m super excited to finally get a good night’s sleep!' Now, it would have been very easy for the researchers to stop there and blame the pilot for being tired.
00:20:49.390
But for them it wasn’t enough to know that he was tired—they actually wanted to know why. So they verified that he had a hotel during his layover, but that wasn’t enough. They verified that he had checked in and then looked at the records of every single time that door had opened and closed so they could establish the maximum amount of time that the pilot could possibly have slept.
00:21:21.150
And even then, they didn’t just say, 'Okay, we’ve shown that the pilot could not have possibly had more than four hours of sleep total!' They looked at the three-letter flight computer readout and they were like, 'Wow! You know, now that we’re thinking about it, that’s an incredibly confusing interface if you’re tired or distracted.' A cockpit is a pretty distracting place.
00:21:59.780
Now, they’re always willing to point out where individuals have contributed to a failure, but they also want to focus on what went wrong with the entire system. So if your takeaway from failure in code or anywhere else in life is anything like, 'I’m dumb. I just can’t learn this. This probably just isn’t my thing,' you are absolutely missing out on all the best parts of failure.
00:22:35.800
Now, I understand not everyone is going to be at the point where you can quiet that inner critic yet, but if you just spend some time trying to ignore it and work the rest of the system, give enough time, and you're probably going to see that the voice in your head starts to contribute helpful insights rather than just criticism.
00:23:07.040
Now, step two: document everything, even things that seem small. Heck, I mean, you should document especially the things that seem small! So my flat tire on the runway in Santa Monica was a very small error, but just as we saw with the Silent Hill example, a lot of those small errors and missteps can start to roll up into a major problem.
00:23:42.970
Catching those problems early on and course correcting is going to help you avoid major meltdowns. So how should we document things? I’m a big fan of actually paper documentation, but as long as you have some sort of record that you can refer back to, the form of documentation is really going to be up to you.
00:24:07.670
You should definitely include details about what you were trying to do, the resources you were using, whether you were working alone or with other people, how tired or hungry you were, and obviously, what the outcome was. Get specific when you're recording the outcomes! If you're trying to get data from your Rails backend out of your alt store into your React components and it keeps telling you that you cannot dispatch in the middle of a dispatch, don’t just write down, 'React is so stupid, and I can do all of this with jQuery! Why is my boss torturing me?' Because that does not help, trust me—I tried!
00:24:45.540
Now look, the final step is to make use of all that data you’ve been diligently gathering. Imagine how powerful that data is as you go through it and start extracting patterns for when you do your best work and when you do your worst work! Instead of vaguely remembering that you struggled the last few times you tried to learn how to manipulate hashes in Ruby, you can actually see that you were only frustrated two out of those three sessions.
00:25:17.620
The difference between the one where you felt good and the other two is that you were well-rested for that one. Or maybe you noticed that you learn more when you pair with someone, or when you have music playing, or when you’ve just eaten some amazing pineapple straight from Kona, Hawaii. On the flip side, you might discover that you don’t learn well past 9:00 PM or that you’re more likely to be frustrated when you’re learning something new if you have not snuggled with a puppy for at least 20 minutes prior to opening your computer.
00:26:00.370
And that is a very good thing to know, because it’s a lot easier to identify the parts of the system that do and don’t work for you when you actually have a paper trail and you’re not guessing. You’re also going to have a really nice log of all the concepts you’re struggling with. If anyone in here has ever said, 'Oh, I’d love to write a blog post, but I just don’t have any idea what to write about!' this log of all the things you're struggling with—that's your blog post fodder right there!
00:26:34.820
Now, let’s say that you go back and you read this data and you see that you had, in your last epic coding session, been trying to wire up my form for my rate distraction map. It worked, sort of; the data got where I was sending it, but it kind of ended up in the URL, which is a bit weird. Cool! You actually have a very well-defined problem to research, and it won’t be too long at all after reading some form documentation that you realize you were using GET action on that form and POST requests are the ones that keep it hidden in the request body.
00:27:07.500
So now, you’re just going to need 20 minutes of puppy cuddle time, and you’re ready to go fix that form! Now, I’ve been focusing on how individuals can learn from failure today, but the thing is, this is also incredibly important for teams. In the research on failure, there’s actually a pretty famous study that looks at patient outcomes at demographically similar hospitals.
00:27:41.550
They found a very strange thing: at the hospitals that had nurse managers focused on creating a learning-oriented culture instead of a blame-oriented culture, there were actually higher rates of error. But they also had better patient outcomes! And they were like, 'That’s weird! Here we have hospitals where people are encouraged to be open about mistakes and they make more mistakes, but patients are better for it.' So they dug in, because that wasn’t what they were expecting to find.
00:28:21.610
What they found was that people were more willing to report their mistakes, which meant that the hospitals could find what was causing those mistakes and correct them—resulting in better outcomes for patients. At the blame-oriented hospitals, people were afraid of losing their jobs over even tiny mistakes. They would spend a lot of time covering them up.
00:29:10.900
Maybe some of you have been on programming teams where that’s the situation: like, if you break production, everyone’s going to yell at you and you have the stupid hat, and people are going to make fun of you. So you spend a lot of time thinking, 'Oh, crap! I just pushed a debug error up!' All right, maybe I can do a hotfix before anyone finds out.' The underlying issues actually never get dealt with.
00:29:56.950
And if you show me a dev team that has a zero-tolerance policy for mistakes, I'll show you a dev team where engineers spend a good portion of their time covering up mistakes rather than writing good code. If you focus on blameless post-mortems, rewarding experimentation, and just, you know, not being a jerk to people because humans make mistakes, you are actually going to have very different outcomes.
00:30:38.610
And probably more longevity and less turnover on your teams. Now look, like everything else you try, the process that I’m proposing may not actually work perfectly for you the first time around. Thank you! Others may find it a tiny bit too meta—just figure out what about the process isn’t working for you and see how you can adjust it. That’s right: you can learn from the failures that you’re learning from while you’re trying to learn from your failures.
00:31:13.420
And as you get more comfortable gleaning information from failures, you’re actually going to find that every single bug is actually a feature as long as you can learn from it—even if you end up deleting every single line of code and starting over again. Thank you!
00:32:02.190
Sure, that’s a great question! It’s about how to communicate that failure is something to learn from, from the engineering side to the business side, which might have a different perspective. And that’s absolutely going to be tough, because if you’re at a corporation that sees a bug in production as the end of the world and you might lose your job because of it, then that’s going to be a problem.
00:32:33.020
And it’s going to be very hard for the engineers to be willing to fail publicly if they're going to get punished—even if it’s not from their managers. So part of that is, you know, it’s up to everyone to try to educate the other people on the team about how this is part of the engineering process. But obviously, you know, your work is building things and fixing bugs, and maybe not fixing PRs.
00:32:57.650
So it’s unfortunate. I would say, if you’re in management, working hard to help business people understand that is great. If not, then buffering your team as much as you can from being punished for mistakes while allowing them to face them and maybe, like, fail internally would be ideal. Being open about it, having blameless post-mortems, while putting a nice veneer on top for the C-Level people that need to think everything is perfect, is the best way to do things.
00:33:39.690
Sure! So the question is about the difference between an early career developer making a mistake and being visible, and a late career developer making a mistake and being visible. I actually had a similar question where someone was like, as a woman, part of my career growth has been looking like I know ten times more than the next person applying for the job.
00:34:12.240
And being open about failures could tank my career. What do you recommend? I’m not an expert, but I recommend you protect your career. However, I would say it’s great when late career developers are open about failures because that gives room for early career developers to be open about their failures.
00:34:41.350
If you feel secure in where you are in your career, take that one for the team. Because all of us are going to be much better engineers by being willing to fail and learn from that, rather than covering it up. If you think it might cost you your job, your livelihood, or your ability to pursue the career path you want, don’t lose out on the value that comes from acknowledging mistakes.
00:35:12.080
You could keep a private diary of what's gone wrong and how you've learned from it. You don’t have to publish it publicly, but I would say don’t let other people keep you from being the engineer you want to be. The way to get there is by trying stuff out, writing code, breaking code, and then going back to fix it.
00:35:43.330
Don’t be afraid to do that! Like, absolutely don't let other people's weird ideas about everything needing to be perfect from the first key press on the keyboard keep you from learning. Because ultimately, I mean, you—you do you! You’ll become good engineers. Don’t be afraid!
00:36:12.200
So the question is about being so comfortable with failure that people no longer worry about making mistakes. They’re just like 'whatever.' I mean, one thing is, I think most programmers want to build stuff that works. So it’s going to be very rare that you find someone who doesn’t care that it’s not working for people and just thinks, 'Whatever, it’s lunchtime!'
00:36:36.120
Most of us put all that pressure on ourselves. In the research, at least in Western cultures, I can’t speak for other cultures, but the stigma on failure makes it very rare to find someone who’s gone too far the other way. It’s more likely that you're going to end up in a place where people are covering up mistakes and making things worse because of that.
00:37:05.890
I think if you do find yourself in a situation where someone is getting a little too comfortable with mistakes, it’s if they keep making the same one over and over again. And that’s not what this is about. This isn't about being like, 'Oh! Stuff breaks, whatever!' It’s about saying, 'When stuff breaks, what can I learn to do better next time?'
00:37:42.590
So if you’ve gone too far on the laissez-faire side of things where you’re like, 'No, nothing's a problem,' you know, just reel it back in and say, 'Hey, I noticed that you’ve pushed a debug error up to production three times in the last week. Do you want to come up with a way that we can make sure that doesn’t happen anymore?'
00:38:12.990
Yes! So the question is about balancing the extra time cost of documenting things versus the value you get when it works out well and you find some usefulness in it. At the risk of this being a cop-out, I’d say you’re going to kind of have to experiment and find what works best for you.
00:38:49.269
I don’t know if anyone in here has had the experience of learning something, writing a blog post so you don’t forget it, or taking some notes, and then six months later being confused about a topic, googling, and finding your blog post you wrote six months ago when you had the problem.
00:39:20.970
I mean, what a love letter that is to yourself—where it's like past you saying, 'Jessica, you are going to struggle with this six months from now. I know how to explain it to you; here you go!' In those moments, the time you took to write that blog post helped you either learn it better or created a great resource for that next time you’re confused about it.
00:39:50.500
I think in those instances, people really see the value in documentation and learning. Certainly, if you spend a couple of months writing a lot of stuff down and nothing's getting better for you, then, yeah, scale it back and find a different approach that works better.
00:40:34.590
Sure! So concrete steps that senior developers can take to help junior developers document and learn from their failures? I mean, it's probably going to vary by individual and vary by team. I think certainly writing tests is great! Without getting too pedantic about it, just having some test coverage forces you to consider the system that you're about to architect.
00:41:06.170
It forces you to have a safety net for when you make a change later and don’t realize that it’s going to break things. Tests are amazing! I’m a big fan of having junior developers and senior developers alike write blog posts and documentation.
00:41:43.709
Because we get so much, especially, I mean in the industry, I think most of us are Ruby and Rails developers, probably working with other open-source libraries and other things, and maybe we’re not at the point where we can write a gem or a framework that helps tens of thousands—or millions—of people. But we can write a blog post that says, 'I struggled with this. This is how I got around it. This is what really made it clear to me.' And that helps a person learning solidify what they’ve learned.
00:42:17.470
And it’s just like this wonderful gift to the rest of the community. I can’t tell you how many times students have googled an issue and had it resolved by a blog post that a student wrote two, three, four semesters earlier when they went through that same issue.
00:42:58.430
So it’s both a great way for juniors to learn and a great gift to the community, especially by people who can’t necessarily give back through writing code yet. Sorry, the question is if I’ve experienced a situation where I thought covering up a mistake was better than admitting it? I mean, all the time! Because I don’t like being yelled at.
00:43:29.680
I have such an irrational fear of authority that has zero to do with how my manager actually interacts with me. But every time he says, 'Oh, do you have a minute to talk?' I think, 'Oh my god! This is it! I’m being fired!' and everything is the worst. He’s just like, 'Oh, I wanted to tell you you did a great job on that feature launch!' And I’m like, 'This might be my last day!'
00:44:00.480
I’ve never actually found a situation where it would be better to hide a mistake. I've found situations where I was really scared and the thing I thought would be bad, which is a manager yelling at me, happened because I worked at a crappy place where that’s how they treated small mistakes.
00:44:32.740
Like a typo in a report that the client said, 'Oh, we never look at that because there’s just too much data in there.' Then my manager was like, 'You made a typo! You don’t care enough!' And I was like, 'Yeah, it’s not the 18-hour workdays; it’s my level of caring!'
00:45:00.760
I think there are situations where it feels better to hide the mistake, but I’ve never actually seen it where there’s long-term value in doing so. I may be privileged and lucky that it’s never killed my career. Sure, being seen as someone who makes typos in reports didn’t help me at the ad agency, but I left there and learned to code, and my life is better for it. So screw those guys!
