RailsConf 2017: The Good Bad Bug: Learning to Embrace Mistakes by Jess Rudder


(bright, emphatic band music) – Cool, so first of all, thank you all for coming out here today
to spend your morning talking about failure,
which is a light topic. So, I think DHH sort of set you up, and I’m just gonna knock you down. As was mentioned, I’m Jess Rudder and if you’re the tweeting kind, that’s my Twitter handle, so there we go. Onto the show. When I was 26 years old, I decided that I wanted to learn how to fly a plane, and 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. 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, and my instructor was like, “I’ve got the plane,” as I go,
“You’ve got the plane,” and he brought the plane
to a stop on the runway. And as our hearts calmed down, we got out, and we looked at the damage. It was a flat tire. Now, my heart rate, finally, was calm, 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 out 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. “Woah, 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 my
instructor in a lot of trouble. But, it turns out, that
the FAA collects details on all events, big or small. Even a tiny tire blowout during a landing in my little four-seater plane. They want to get as much data as possible, so that they can work out patterns that can help them
implement safer systems. 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. When I was twelve years
old, I was riding home from the Saturn dealership
in a shiny brand new car. It was the first brand new car that my parents had ever purchased. We’re sitting at a stop light, and suddenly we lurch forward. We’d 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. My dad looked it over, and he 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, and 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’s 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. I looked at the most
recent stats available, which were for 2015, and
for every one billion miles people in the US travel
by car, 3.1 people die. And, for every one billion
miles people in the US travel by plane, there
are only 0.05 deaths. 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 you’re mind about, 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. 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’ll all on the same page when we talk about failure. So, what is failure? I think for some of us, it might be that sinking feeling that you get in the pit of your stomach, when something didn’t go right, and the person is yelling at you, and they have the angry
face, and you’re like, “Why did I even bother getting
out of bed this morning?” And, I can absolutely relate to that. And, I was prepping for this talk, and looking at what different people said, I found a lot of people that were like, “Oh, failure, that one’s simple. “It’s the absence of success.” And, I was like,
“Sweet, what’s success?” And, they were like, “Pssh, so easy, it’s
the absence of failure,” (audience laughs)
“Oh, not really helpful.” But researchers, they actually have a very specific definition of failure. Failure, to them, is deviation from expected and desired results. And, that’s not bad. Now, I honestly think there’s some truth in all three of these
definitions, but that last one, deviation from expected
and desired results, that’s something that you can
actually test and measure. So, we’re going to stick
with that one for now. I couldn’t actually find
any definitive data on this, but I think that, as developers, we have more results that
deviate from our expectations, than just about any other group of people. So, you’d think that programming would be the perfect place
to learn from failure, but one of the few places
that I could actually find people routinely, most of the
time, capitalizing on failure, was in video game development. And, one of my favorite examples of this is with the game Space Invaders. Do you guys know the game Space Invaders? It’s the old arcade game where you control a small
cannon at the bottom that’s firing at a
descending row of aliens, and as you defeat more
aliens, they speed up, making them harder to shoot, right? No, that actually was not the game. That’s not what it was supposed to be. The developer, Tomohiro Nishikado, he 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. And, 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 shelve the project until processor speeds were fast enough, and that might seem silly,
but maybe he had a vision, and he was not going to compromise. He could also have
modified the game design, put 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, they would actually project emotions on the
aliens, they were like, “Oh, these guys are getting scared, “I’m taking them out and
they’re trying to speed up, “because they know that I am
about to kick their butt.” And, 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. Before this, games would always be the exact same difficulty
for an entire level, and it wasn’t until you
got to the next level that things would actually
get more difficult. After this, all bets were off. Things could get difficult at any point, whenever the developer pleased. 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 actually presents a
greater learning opportunity, because there’s more information encoded in failure than in success. Think about it, what does
success usually look like? A check mark, a thumbs up, a smile from a manager. And, what did you actually learn? Well, there’s research on this. Research actually shows that people in organizations that
don’t experience failure become rigid, because the only feedback that they get tells them, “Just keep doing the exact
same thing you’re doing, “Don’t make any changes because “you’re already winning, buddy, “Don’t change anything,” Failure, on the other hand, looks a whole lot more like this. (crowd laughs) Okay, look at this. Look how much information there 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 we have some experience with this particular error message, we probably know what
that issue most likely is. And, 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. Video game development actually 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, that actually came in very
handy for a group of developers that were working on a street
racing game in the ’90s. The concept for the game had players racing through city streets, and they were being chased by cop cars, and 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, and instead of law-abiding police officers
trying to pull you over, you had these super aggressive cops trying to slam right into your car, and they would do it at full
speed, no matter what you did. The beta testers, they actually had way more fun avoiding the cops than they’d ever had with the racing game. And, as a result, the
entire direction of the game was switched up, and the Grand
Theft Auto series was born. So, I want you to 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. They made a mistake, but
instead of freaking out, they thought,
“All right, “let’s see what happens.” And, they cashed in. Now, there’s actually
some larger programs, where hundreds, if not
thousands, of hours of work have already been done by
product leads, and designers, and business people before a developer ever gets to write their
first line of code, and in game development, the work in encapsulated in a document called the Game Design Document. The GDD is considered a living document. However, it’s actually a pretty big deal for changes to be made late in the game. In 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. 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, it 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. And, as you can imagine,
that sort of like, “Oh hi, trees,” suddenly, distracted people from a game. And a horror game is very
dependent on atmosphere that sort of 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 played their part. From the designers who just
put one or two more buildings in the background to make it interesting, 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, 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 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 find a work around. The filled the world with
a very dense, eerie fog. And, it turns out that fog is
actually pretty lightweight for a graphics card to render. So now, it obscures distant objects, which means you couldn’t really see buildings and textures on the
horizon popping in anymore. And, as an amazing added bonus, it is really, 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 pop-in wasn’t an issue anymore. So, that’s another example of success being ripped from the jaws of defeat, simply by embracing your failures. These examples from the programming world actually help to illustrate
what was happening at our more high-stakes example in aviation and automobile accidents. You see, the aviation
system saved so many lives because accidents are treated like lessons we can learn from. Data is gathered, and 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’s
schedules, and staff 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, he does
not know how to drive.” 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. “I definitely stopped at that stop sign, “that’s the guy who went through it.” Meaning, they spend time covering it up rather than just
acknowledging their failures and learning from them. Not everyone in this room is a pilot, but I actually think that
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. But, that sort of begs the question, “What should that system look like?” In broad strokes, I think that there are three very important pieces
that the system would need. On 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. Cool, that is much easier
said than done, right? Learning not to beat yourself up over a failure and mistakes, that’s probably 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. There was actually a case where the pilot made a critical error by dialing in the wrong
destination in the flight computer, and it caused a wreck. In 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. 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 had a hotel during his layover. But, that wasn’t enough. So, they verified that he had checked in. And then, they 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. 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 tonight.” They looked at the three
letter flight computer readout, and they were like, “Wow, now that we’re thinking about it, “That’s an incredibly confusing interface if you’re tired or distracted,” Which, a cockpit is a
pretty distracting place. 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. 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, given enough time, you’re probably going to find
that the voice in your head starts to contribute helpful insights, rather than just criticism. Step two, document everything. Even things that seem small. Heck, I think 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, and 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, actually,
of 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. 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, I can
do all of this with jQuery, “Why is my boss torturing me?” (audience laughs) Because that does not help. Trust me, I tried. (laughs) (audience laughs) Now look, the final step is
to make use of all that data that 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,
and 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 notice 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 PM, or that you 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. 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. And, you’re also going
to have a really nice log of all the concepts that
you’re struggling with, which if anyone 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 source right there. 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, “I was trying to wire up my form “for my Rate This Raccoon app, “And it worked, sort of, “The data got where I was sending it, “But, it 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
the GET action on that form, and GET requests put the data in the URL. Post requests are the ones that keep it hidden in the request body. So, now you’re just gonna need 20 minutes of puppy cuddle time, and you’re ready to go fix that form. I’ve been focusing on how individuals can learn from failure
today, and the thing is, it’s also incredibly important for teams. So, in the research on failure, there’s actually a pretty famous study that looks at patient outcomes at demographically similar hospitals, and they found a very strange thing. At the hospitals that had nurse managers that were 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.” And, so they dug in, because that was not what
they were expecting to find, and what they found was that it was just that people were more willing to report their mistakes, which meant that the hospitals could find what was causing the
mistakes and correct them, which meant that patients
had better outcomes. At the blame-oriented hospitals, people were afraid of losing their jobs over even tiny mistakes, and they would spend a lot
of time covering them up. And, maybe some of you have
been on programming teams where that’s the situation,
like if you break production, everyone’s gonna yell at you, and you’ll have to wear a stupid hat, and people are going to make fun of you, and so you spend a lot of time, like, “Oh crap, I just pushed a debugger up, “All right, maybe I can do a hotfix “before anyone finds out,” And the underlying issues
never actually get dealt with. 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 postmortems, rewarding experimentation,
and just, you know, not being a dick to people,
because humans make mistakes, you are actually gonna have
very different outcomes, and probably more longevity and
less turnover on your teams. Now, look, like everything
else that you try, the process that I’m proposing may not actually work perfectly for you the first time around, thank you, I know,
(audience laughs) others can feeling 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. (audience laughs) And as you get more comfortable
gleaning info from failures, you’re actually gonna
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. (audience claps) Sure, that’s a great question, so, it’s, “How to communicate that failure
is something to learn from, “from the engineering
side to the business side, “that might have a different perspective,” And that’s absolutely gonna be tough, because if you are at a corporation that sees a bugged production
as the end of the world, and you might lose your job because of it, then that’s going to be a problem, 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, 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 that’s obviously, your
work is building things, and fixing bugs and
maybe not fixing people, 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 the
space, so maybe it’s like, fail internally, be open about it, have blameless postmortems, but put a nice veneer on
top for the sea-level people that need to think everything’s perfect, and that’s the best way to do things. 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 that
was applying for the job, “and being open about
failures could tank my career, “what do you recommend?” And, I was like,
“I’m not an expert, “I recommend you protect
your fucking career,” (audience laughs) But, I would say that I think 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. I’m not embarrassed by
not knowing something, so when I’ve been in code
readings or anything like that, and they’re like, “Oh, are there any questions?” I’m always more than happy
to raise my hand and say, “I didn’t understand that thing,” because, for me, it’s not embarrassing
not to know something, and so I’m willing to
take one for the team and afterwards people
will come up and say, “Oh, thank you so much for asking, “I thought I was the only
one that didn’t know.” And, so I think part of it is, if you’re late in your career and you’re comfortable with where you are, and you’re willing to show
that it’s okay to fail, then take that one for the team. 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, than we will be covering it up, and so, if you think that
it might cost you your job, cost you your livelihood,
cost you the ability to go down the career path you want to, don’t lose out on the value that you get from at least acknowledging
internally your mistakes. 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 that you want to be, and if the way that you get
there is by trying stuff out, writing the code, breaking the code, and then going back and fixing the code, don’t be afraid to do that. 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, you do you. You be good engineers, don’t be afraid. So, the question is about
being so cool with failure that people no longer worry
about making mistakes. So, they’re just like,
“Whatever.” (audience laughs) 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 that’s like, “I don’t care that it’s
not working for people, “Whatever, it’s lunchtime.” Most of us are like, “My baby is broken, my code doesn’t work,” We put all that pressure on ourselves. In the research, at least
in Western cultures, I can’t speak for other cultures, but Western cultures put
such a stigma on failure that it’s very rare that
you would find someone that’s gone too far the other way, and it’s much more likely
that you’re going to end up in a place where people
are covering up mistakes, and making things even
worse because of that. I think if you do find
yourself in a situation where, sort of, I think, the tell if someone is getting a little too
comfortable with mistakes is that they keep making the
same one over and over again, and that’s not what this is about, this isn’t about being, “Oh, stuff breaks, whatever,” It’s about saying, “When stuff breaks, what can I learn “to do it better next time?” And so, if you’ve gone too far on the la ze faire side of
things, where you’re like, “No, nothing’s a problem,” You just reel it back in, and you’re like, “Hey, I noticed that you pushed
a debugger up to production “three times in the last
week, let’s come up with a way “that we can make sure that
doesn’t happen anymore,” and so, yeah, you just
course correct there, yes. So, the question is, sort
of finding the balance between the extra time
cost of documenting things versus the value that you
get when it works out well, and you get some value from it. At the risk of this being a cop-out, I’d say you’re going to have to experiment and find what works best for you. 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 writing some notes,
and then six months later being very confused on a topic, googling, and finding your blog post that you wrote six months
ago when you had the problem. What a love letter that is to yourself, where it’s like, past you is like Jessica, “You are going to struggle
with this six months from now, “I know how to explain
it to you, here you go.” And so, in those moments,
that time you took to write that blog post,
you either learned it better and were able to do it
more fluently next time, or you have this great resource,
written by you, for you, for the next time you’re confused on it. And, I think, in those instances, people really see the value, and the documentation and the learning. Certainly, if you spend a
couple months, and you’re like, “I wrote a lot of stuff down, “and nothing’s getting better for me,” Then, yeah, scale it back and find a different
thing that works better. Sure, so, concrete steps that senior developers can
take to help junior developers document and learn from their failures. It’s probably going to vary by
individual, and vary by team. I think, certainly, writing Test is great without getting too pedantic about it. Having at least some Test coverage, forcing you to think about,
especially as a junior, the system that you’re about to architect, forcing you to have a safety net for when you make a change later, and don’t realize that
it’s gonna break things. Tests are amazing. I’m a big fan of having junior developers and senior developers alike, write blog posts and documentation, because we get so much, especially, in this room, 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 all at the point where we can sit down and write a gem, or a framework that’s going to help tens of thousands or millions of people, but we can write a blog post, that’s like, “I struggled with this,
this is how I got around it, “This is what really made it clear to me.” And, that helps the person that’s learning solidify what they’ve learned, and then it’s just like
this beautiful gift to the rest of the community. I can’t tell you how many
times people have been, so I work at a school
where we teach developers, and there have been plenty of times where students have googled an issue, and it’s been resolved by a blog post that a student two, three,
four semesters earlier wrote when they were going
through that same issue, and so it’s both a great
way for juniors to learn as well as a great gift
to the community by people that can’t necessarily give
through writing code yet. The question is, if you’ve
experienced a situation where you thought covering up a mistake was better than admitting it. I mean, all the freaking time, ’cause I don’t like being yelled at, I have such an irrational
fear of authority, which has zero to do with how my manager actually interacts with me, but every time, he’s like, “Oh, do you have a minute to talk?” I’m like,
“Oh my god, this is it, “I’m being fired, and
everything’s the worst.” And he’s just like, “Oh, I wanted to tell you, “you did a great job on
that feature launch,” And I’m like,
“So, when is my last day?” (audience laughs) The thing is, is that I’ve never ever actually found a situation where it would be better
for me to have hidden it. I’ve found situations
where I was really scared, and the thing that I
thought was going to be bad, which is like a manager yelling
at me, actually did happen, because I worked at a crappy place, where that’s how they
treated small mistakes, like a typo in a report
that the client had said, “Oh, we never look at that, “because there’s just
too much data in there,” And then, my manager’s 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,” And so, I think, there are situations where it feels like the better option is to hide the mistake, but
I’ve never actually seen it where there’s long term
value from hiding a mistake, and I may be privileged and lucky in that, that it’s like never killed my career. I’m sure, being seen as someone
who makes typos in reports certainly didn’t help
me at that ad agency, but I left there, and learned to code, and my life is better, so
screw those guys. (laughs) (audience laughs) Anyone else? Awesome, you guys have been
fantastic, thank you so much. (audience claps)

, ,

Post navigation

Leave a Reply

Your email address will not be published. Required fields are marked *