 This is a really good first talk to give because even if it sucks, I can learn something from it. So I hope by the end of this everyone will have learned how to move forward from their failures. So if you are anything like me, and I suspect that some of you might be, you were probably called smart a lot when you were a kid. Maybe you took AP classes and honors classes and you got through high school really easily. I graduated high school with honors and I had a full ride academic scholarship to any Florida State College because I'm from Florida. It wasn't like some weird lottery where I won just only in Florida. That would kind of suck. And so my first semester in college, I did not do as well as I thought that I might. Professors actually don't care who you were in high school, which was like a weird thing for me. All of my teachers in high school would just sort of like let me slide because they knew that I could make it up on the test if I didn't do my homework. Professors didn't really care about that. And so I was at risk of losing my scholarship. I needed to keep my GPA above a 3.0 in order to maintain it. So they gave me a semester to sort of redeem myself. So I took the spring off and I went back for the summer and I wanted to find a class that was easy enough to help me get my grade up so I could keep my scholarship. But also maybe something that I could learn from. Maybe I could become more successful. So I found a class that seemed to fit the bill. It was called College Success. And so I took College Success that summer semester. I failed college success. I've lost my scholarship. I dropped out of college and I sort of figured maybe college wasn't for me. But beyond that, I kind of felt a little bit like lied to. I had been told that I was smart and that I was going to be able to basically have it easy and just breeze through because I wouldn't really have to try. And when I came up to this failure of this like failing college success, which is kind of awful, I didn't know how to move forward from it. I'm sure maybe some of you might have had a similar experience and sort of felt like everything that everyone had told you about how smart you were was maybe not true. So I started talking to some other people who had had similar experiences. And I started to do a little bit of research. And after talking to other people and doing research, I found that my experience wasn't unique. And I came to the conclusion for myself personally that I don't like being called smart. The one thing that I sort of noticed that we all had in common was that we were all called smart. We were all called geniuses. We took honors classes, whatever it was. And so it sort of led me to ask this question, if this is the constant in all of these like stories of people's failures, could smart be toxic? Could smart be toxic? All the connotations that come along with it? And just like the phrase of just the compliment of telling someone you're smart, could that be a bad thing to do? And so I found this study by Carol Dweck, who's a researcher from Stanford and a psychologist. And basically what her and her researchers did is that they went to New York City public elementary schools and they wanted to see what a single line of praise effect would have on a group of students. And overwhelmingly what they found was that smart causes underperformance. Labeling someone as smart causes them to not do as well as their peers. And so what they did to come to this conclusion is that they went into a classroom and they divide it in half randomly. And they gave them a series of tests and they wanted to see if a single line of praise would affect the way that they took the test. And so for the first test, one at a time they pulled students out and they gave them an easy puzzle, something that they wouldn't have to really expend very much effort to complete. After they finished the puzzle, they received one line of praise. Half of the students were told, you must be smart. Half of the students were told, you must have worked really hard. Next, the next test that they took was one that they were all in the same classroom together and they had a choice in the test that they wanted to take. They could pick an easy test like the one they had just taken or they could pick a hard test that was grade levels above where they were at. But with the knowledge that it would be a really great learning opportunity. By and large, the students who were praised for their smarts took the cop out. They wanted to take the easy test. Meanwhile, 90% of the students who were praised for their efforts decided to take the hard test. So after just one single line of praise, we start to see this pretty deep divide. Students who are praised for their smarts are kind of told that in order to keep being smart, you can't risk making mistakes. When we praise children this way, we sort of tell them that this is the name of the game. So they took another test and this time they didn't have a choice in the difficulty level. And this test was designed to be several grade levels above where they were at. It was going to be really difficult and as expected, everyone failed this test. But something kind of peculiar happened. The students who were praised for their intelligence looked anxious during the test. Some of them were sweating. They looked miserable. The students who were praised for their effort, they looked calm. They didn't seem to phase them at all. After the test, the kids who were praised for their efforts when asked why they failed said things like, I must not have tried hard enough or I could have focused more. A couple of the students who were praised for their effort unprovoked said things like, this was my favorite test of the day. So for the last round of testing, they gave them another puzzle that was basically the same as the initial puzzle they took where they got their first line of praise. And the students who were praised for their smarts just three tests ago, their scores dropped on average by 20%. The students who were praised for their efforts had scores that rose on average by 30%. So what we can learn from this is that when we praise someone for their efforts and not their innate intelligence, we provide them with this variable that they can control. If they come up to a failure, they'll approach it and they'll say, oh, I must not have tried hard enough. Or if they come up to something that's really difficult, they'll say, I must need to focus more or work harder or exert more effort. When we praise someone for natural intelligence or for their smarts, we really are not providing them with a recipe for responding to their failures. They start to think things like, if I'm smart, I shouldn't fail. Therefore, if I fail, I must not be smart. And this leads to expending effort. It becomes the stigmatized thing. In follow-up interviews, students who thought that natural intelligence was the key to success begin to even discount the importance of effort. And eventually they seek to avoid exerting effort at all. Because if you have to work hard at something, it sort of becomes this public proof that you can't cut it on your natural gifts alone. But this wasn't a one-time study in one classroom in New York City. This was replicated many times in all different types of socioeconomic classes and found the same results with all genders and all types of gender mixed groups and found the same results. And with all ages, even as young as Pre-K, like three and four-year-olds, they started to see this divide after one line of praise. And so you might be thinking like I did after reading this study. That's great, but I can't go back in time and not be called smart. So how can I, you know, move forward from this? So I guess a little bit more about me is this time last year, I was just getting started becoming a developer. And this time, a little bit more than like almost two years ago, I was on the fast track to a really exciting career as an assistant manager at a really cool retail chain that you might know called Hot Topic. When I was a kid, or when I was like a teenager, I taught myself HTML and CSS. And I really enjoyed it. But my dad told me the internet was a fad. And so I didn't really think I could find a career in it. When an opportunity came up to become an apprentice and to be paid to learn how to write software, this field that I didn't even know was open to me, I knew I had to take it. And I knew that it was probably going to be really tough. But I didn't really expect failure to be such an important part of my job. That little red F in my terminal was like the bane of my existence when I started my apprenticeship. Failing was really awful for me when I started to start writing tests. Sometimes I would spend almost the entire day staring at a failure, kind of scared to do anything. But most of all, I was really scared to ask for help. And I felt selfish and I felt kind of wrong for the way that I felt. I had this great opportunity, this dream job, this like really rare privilege to learn software and to be paid to do it. And so I'd come home from work and I'd tell my roommates and I'd tell my boyfriend that I can't do it, I hate this job, maybe I should just go back to folding t-shirts, that was kind of cool. So why did failure have such an effect on me? Even a failure just as insignificant as a failing test. I think it kind of goes back to these fun things, standardized testing with the Scantrons. There's this stigma around failure and with development, there's no one right answer like there is on a standardized test. With standardized testing, it rarely matters how you get to the answer just that you got there. With development, I'd argue that almost the exact opposite is true, especially when you're first starting out. When I first started, I would just create really simple programs, really simple apps. I think this is something that most people do when they first start writing software. And I would solve these trivial problems. And it wasn't really about getting to the solution, it was more about the process. The trivial problem that I kept solving was tic-tac-toe games. Here's a sampling of some of my repositories on GitHub of all the tic-tac-toes that I've written. And it took me a while to understand that the main goal in creating this game wasn't getting a tic-tac-toe game because it's been done. It's not exciting, it's not groundbreaking, it's just something to practice on and to build a solid foundation on. So sort of the side effect of learning how to write good code, learning how to test, and learning how to learn was that I would create a new tic-tac-toe game. And yeah, that's cool. But how did I ever get over that red F in my terminal? So you guys have, you all have probably played this game or whatever at some point where somebody will hide an object in a room and they'll direct you to the object with one phrase. They'll either say you're getting warmer if you're getting closer to it, or they'll say you're getting colder if you're getting further away. When they tell you that you're getting colder, you don't freeze in place, scared to move because you failed. You view that as feedback and you move in a different direction knowing that moving further in that direction is going to take you further away from the object. I started to try and adopt this mindset when I was approaching failures in my development career. So a failing test or a falling short of a goal was going to be feedback for me now. I was going to start viewing my failure as feedback. If I got an error in my console, I would read the error, try and fix it, modify my code a little bit, run it again, and then if I get a new error, then maybe that's the computer telling me that I'm getting warmer and I'm getting closer to finding the solution. If I wasn't able to get any further and kept getting the same error, then I knew that I had some gap in my knowledge that I needed to fill in. And so I would go back to the last time I understood something and see what I didn't understand since then. And so like I said, I was an apprentice for a while. I had an apprenticeship for a little over a year. And it was really great because I got to learn in this like semi-controlled, low-risk environment, but that's not really the case for most people. You're expected to deliver software. You're expected to bill for your work. You're expected to not sit around failing. So I wanted to still foster this mindset that I had about failure beyond my apprenticeship and beyond any type of beginner. And so on my first client project, I got right back into the saddle and I failed again. And I wanted to know how I could learn from that failure because I wasn't able to deliver the story that I was supposed to deliver, but I thought there might be a lesson that I could learn from this. And so it's really important to not fail at your failures. And failing at your failures looks like deferring them until you can't defer them any longer. And at that point, they sort of blow up in your face. This always happens. And so for me, the failure that I was struggling with was that I had an iOS feature that I needed to implement. And I was the second most senior person on my team with iOS experience because I had a whopping three weeks of iOS experience. So this story was mine to work on. And since nobody else on my team that was readily available had experience, my estimate of it taking about three days was way off by about four weeks. So what could I learn from this? And I think the most important thing was that in order to not fail at your failures, you need to fail quickly. Like I said, deferring your failures won't make them go away. And failing quickly means that you can move past it and get to new failures and then eventually maybe get to successes and then more failures and successes. A way to fail quickly is to not spend your wheels for hours at a time. This is something that I used to do. 25 stack overflow tabs open in Chrome convinced that I was finally gonna figure out the Google food to get this problem solved instead of just turning to somebody who could probably help me in a matter of minutes. And I do think that there's value in getting yourself unstuck. But I also think that spinning your wheels is not gonna help you get there. So what I like to do when I come up to a problem that's difficult, I will time box an amount of time to solve it, maybe 45 minutes. And if I'm not able to get on the right track or if I'm still lost after that time, I'll ask for help. Just getting a new set of eyes on a problem is really good to get you out of your tunnel vision. Sometimes I would just start, I work remotely now and so sometimes I'll start typing out an email and just by simply writing out what I'm trying to do, it comes to me and I figured out where I went wrong. So it's just really great to just try and pull yourself out of the tunnel vision in order to fail fast. Because in order to get that feedback from your failure, you need to get to the failure. Part of failing fast is exposing your ignorance. Exposing your ignorance can be really scary and it's way easier to guard your pride and to not expose your ignorance because asking questions and exposing that you don't know something can be uncomfortable. But if you started viewing exposing your ignorance as really exposing that you have the ability to learn, it spins it into a more positive light. It's something that you should seek to always be learning new things. Being outside of your comfort zone most likely means that you're learning something and so I try to expose my ignorance about things as quickly as possible so that I can just get to my successes and get past my failures. And so something that I like to do that is to document basically everything. Ben said earlier that he likes to write down problems so that he's faced so that he can go back and search for him if he comes up to the same errors. I have the same sort of process. I have like 1200 notes in Evernote that I have all tagged and ready to go if I ever come up to a problem. And so I'm sure that none of you here have probably ever been derailed due to lack of or outdated or unhelpful documentation. That probably never happens. So maybe this isn't for you. But for me, when I come up to bad documentation, I like to document my process of how I solve something. Maybe if it's something, a client project, I'll update the read me so that a new person rolling onto the project is able to get up to speed. There's no point in having somebody take two weeks to get their environment set up if you know how to do it in two hours. And I figure that if I'm spinning my wheels on something then there's a pretty good chance that somebody else is gonna be spinning their wheels on it as well. And so if I can help them get past that spinning their wheels process and get to the failures then I wanna do what I can to help them with that. So at the last company I worked for, we practiced agile methodologies. And one of the things that I liked about, one of the things I liked about agile was retroactives after a sprint or an iteration. Retros were a really great way for me to voice my concerns about the projects I was on. Basically you say what you're happy about on the project or about the iteration, what was just okay, and then what made you upset or what was a pain point. And it's really helpful because you get insight from your team that you might not usually get. And so at the end of everyone sharing how they felt about the iteration or the project, you come up with action items to fix the things that were pain points. And so like I said earlier, one of my pain points was this iOS story. And since my teammates were upset because they didn't know Objective C, they didn't know iOS, they couldn't help me. Even if I wanted to brainstorm with them, they wouldn't really be able to bring much to the table. And so my action item was that I was going to start teaching a workshop on Fridays for them where I would be teaching them Objective C and iOS so that they could at least be around for me to rubber ducky pair. Just something so I could talk to somebody, talk it out, or even just have them take small parts of the stories I was working on. So we did a few workshops. I just gave them homework throughout the week and then on Fridays we went over it and we talked about things that were confusing, mostly Xcode related. And now both of those women that were in my workshop were tackling iOS stories together. So I took what I learned of not having anyone on my team working in the same technology or even knowing it as a failure and I wanted to see how I could fix it. And so that's an example of something that I did in a retro. Something that's kind of interesting that I heard about recently in the Harvard Business Review was this notion of a pre-mortem. And so basically you know what a post-mortem is and a pre-mortem is kind of the opposite of that. You get the people who are invested in a project in the room. You tell them, you give them this scenario where you say okay, we're X amount of time in the future and we failed the project or we failed the iteration. And you ask them, why did we fail at it? You give them two minutes to write down why they failed at it. And it sort of provides this perspective hindsight. It helps to reduce overconfidence. People who are just like, yeah we can do this in six months. It helps to also liberate people who might be scared to speak out because they don't want to not look like a team player. This happens because now everyone's pulling in the same direction. Everyone's trying to think of ways why this project failed. And I think it could also be great if maybe you have somebody on your project or on your team who has done something similar to this and they failed and they can tell you we tried to do something like this and we failed. So maybe we should try and avoid this or just keep in mind that this might be a pain point. So it can be really beneficial to get feedback from other perspectives as well. So these are ways that we as individuals can foster failure and foster this learning environment. But it's a little bit harder to maybe get your company or your employer on board with this. So I'm gonna try and help you with that. Like I said, there's still this stigma around failure and it's kind of silly because we all fail and no one wants to admit to it. When we don't admit to our failures, it causes things like imposter syndrome, burnout. Burnout especially from people who push themselves really hard because they think it comes easy for everyone else and they need to try twice as hard in order to be just as good as somebody else. And this leads to stress and anxiety among other things like people leaving the industry. And we can also be potentially alienating and intimidating people if we only talk about our happy paths and we only talk about our successes. So we should try and empower our teams and empower our coworkers and maybe even try and empower our communities. And we can do this by trying to chip away at the stigma that surrounds failure. A great way to do this is to talk about failures publicly with your team, maybe at a company meeting, at a meetup, maybe write a blog post about it or speak at a conference. You, I enjoy talks about somebody's new gym or new library as much as the next person. But I'm always kind of disappointed that they don't talk about how long it, maybe how long it took them to get there or how many times they failed before they finally were feeling confident enough to publish their code. And this is, this kind of does a disservice to people because it's not as relatable. There's probably not a ton of people that are gonna be in your audience who have published a gym or published a library that they're super proud of enough that they would wanna give a talk about. But I guarantee you that everyone in the audience has failed at something. You're automatically more relatable this way. Maybe if you talk about your failures and then say, and then finally, here's how this gym was born. I had to go through all of this growing pains beforehand. Somebody will be in the audience and they'll say, I fail so much, maybe I could do that as well. You sort of start to remove these heroes from the pedestals that you put them on top of. And who knows, maybe next time, it's that person from the audience who's giving a talk at a conference or writing a blog post. So if we started to chip away at the stigma around failure, we would start to foster a community of expert learners. Expert learners are people who are constantly pushing themselves outside of their comfort zone to learn something new. Instead of repeating the same year over and over again, you would be constantly learning new things, trying new things out, doing new things all the time. I think for me personally, that's kind of an exciting thing. So I have this little simple feedback loop for you if you wanna try and put this in three easy steps for how to learn from your failures. So it just goes like this. Praise effort, expose ignorance, safe place to fail. So if we wanna empower our teams and our communities and even ourselves, we can follow these steps. The first step is praising effort and we all just heard the study of how important it is to praise effort in students and young people. But could praising effort for people who are not elementary school students have an effect? I think so. In fact, when I mentored a young woman, she came in for a code review and she submitted her code and she was all nervous and I was sitting next to her. And the first thing I said to her was, thank you for submitting your code. I can tell that you worked really hard on it and I appreciate how much effort you put into it. Later she told me that it meant so much to her that I appreciated how hard that she worked on it and that would actually helped her to wanna improve and do better because she knew that if she was able to do this by working hard, if she kept working harder, she would be able to write better code and be able to do more. Next is exposing ignorance. And so exposing ignorance is sort of a side effect of praising effort. If we started to praise effort instead of intelligence or instead of reaching to tell somebody, hey, you're so smart, people are no longer gonna be scared to not be the smartest person in the room. And then they're going to be okay with asking for help if they know that the merit is in how hard that they worked on something and not what innate ability that they have. And when you praise effort and expose ignorance, you provide a safe space to fail. And this is the most important part, is you need to have all three of these things in order to foster this community of expert learners. And when you have a safe space to fail, it's okay to praise effort. And when you praise effort, then people are okay exposing their ignorance. And so this all just feeds into each other. So if there's sort of like one thing that I really pride myself on, it's my ability to quote movies and just pull a cliche quote out of nowhere. But I didn't want to put the life as a journey, not a destination quote. I wanted to find something maybe a little bit more eloquent. And so I found this quote by Charles Dallin that I think is really nice and sort of sums up this whole experience for me was the road leading to a goal does not necessarily separate you from the goal. It's essentially a part of it. Quote, like reading this sort of made me feel validated a little bit. But as eloquent as this is, I kind of like this one more. And it says, sucking at something is the first step towards being sort of good at something. So I like to think about this when I'm trying to figure out how like Ruby Garbage Collection works and I just can't wrap my head around it. I like to think about this quote. So I hope if you walk away from this talk with anything, it's that sucking at something is the first step towards being sort of good at something. And then maybe you can also learn to be okay. And maybe even appreciate, maybe love your failures. Thank you. Thank you.