 Lebanese and from Lebanon and from far in the mountains that had no interest in the modern world post 1961, Lebanon, and she asked me once what I did for a living. And I just thought about how could I communicate to you this sort of compiler, I told her I worked with computers and that's like my favorite description of what I do, so that's a great intro. So who else here writes code? There's one. Great. Who's seen something like this? Yeah, if you're not raising your hand you're lying. So this is what I want to talk to you all about today. So I think about failure a lot. I write code, I teach code which basically means I marinate in failing code at all times from all angles. And it's something that's, this talk is kind of a collapsing of a bunch of things I've been thinking about in terms of failure over the past few years. So I'm Ramsey Nasser. Is that too small? This is me on Twitter if you do that thing. There's a story behind that, grab me and I'll tell you. So I write code because it makes me feel like this. Like sometimes, right? When it works I feel post-human and I'm like levitating and I'm blowing shit up. But in reality this is actually the experience of writing code, right? Like that, why is that? Why do I live between these two worlds? So, you know, failing feels bad, right? And it's not a thing that people talk about a lot. And it's, you know, when you follow people's careers or Twitter accounts you see a lot of like, all this great stuff that they're doing but people tend to not share their failures publicly. And I think a big part of that is because it's not fun to talk about. So for this talk I'm gonna let you all in on a little secret to make things a little easier. So to feel is to emotionally experience something, right? To have feels about something. It's like, ah, it feels bad. But feel is also Arabic for elephant. So, you know, you could feel bad. Or you could feel, look at the little guy. You see, he's running around. Where are you going? So when things get a little heavy I'm just gonna put an animated gif of a baby elephant on the screen. And it's gonna be great, this is my feel. So I wanna talk about, I wanna start talking about what failure is and almost, you rebrand failure because I think the spectrum that it's looked at is right and wrong. You're either doing something right or you're doing something wrong, right? But in reality, I think what's actually happening is you do something and you have some expectations and then something else happened, right? I expected this code to work but it threw a bunch of exceptions. And when you look at it like that, given the set of all things that could possibly happen, some subset of those things are your goal, are your expectations. And the sort of right, wrong dichotomy would tell you that everything in gray is failure, right? You either did the thing that you wanted or you failed. But that's actually not true. There's a bunch of cool stuff out there, right? That you didn't actually know. And this is where programming and really any creative activity becomes powerful and interesting where you can set off to do something and run into something that you didn't even know you wanted. In many cases, this is what it's looked like for me. I've had some idea and I'd go out and different things would start happening and I'd end up with something completely way off goal but much better than what I set out to do, right? And this is what a healthy, I think, iterative creative process can need you to. So the possibility of failure and the possibility of surprise are linked. You can't actually separate the two. And that's why failure is important, right? Because failure is one manifestation of surprise, right? So I think about it as an undesirable result different from the intended one, right? You are deciding that this different result, this different thing that happened is actually not what you want. Throwing a bunch of exceptions may be your goal, right? Maybe you're writing an art piece about the collapse of the Java virtual machine. I don't know, right? And then you nail it. You're throwing a bunch of null pointer exceptions. And I love Bob Ross and I love this and I think about sort of Bob Ross's perspective on programming and what that would have been and this perspective on mistakes or failures is one that I like quite a bit. And we'll come back to Mr. Ross in a moment. Failure is also always useful, right? It's always information. It's never a waste of time. It's always, it tells you that something didn't work, right? That's this value in that. Like I know that this approach leads to this condition which is undesirable. So you're always actually learning things while you're failing. But failure feels bad, right? Failure is awful. And I think that's not to do anything with the act of failing itself, but I think it's more to do with external factors related to associated with failure. So in programming and computers, this is what errors look like, right? This is the Internet Explorer trying to be a browser. If you use IE, I don't mean to sort of make you feel bad. It just, it does errors a lot. This is Unity. This is the way Unity reports its error messages. This is even processing which is, goes out of its way to be, it's much better now, but it goes out of its way to present errors in a parsable and a palatable way. So all of these, you know, you have this theme of red, right? You have red on black text, are you kidding me? And you have, this is actually just, to be completely fair, one of my frameworks, this is what one of the errors look like. It's just text, so the colors aren't awful, but you can clearly see what's going on here, right? This is, you got lazy seek, sval at, okay, great. I'm just gonna go to philium unknown line zero, which is where all the bugs are, apparently. Good luck with that. So, and can we meditate on these pixels for a moment? Like, this is, you know, some human chose this, right? They chose, they drew this, and they decided that this is how we're going to visually brand whenever you make a mistake. And does anyone know what this is? Does anyone know what this is? The colors and the shape are modeled on? Stop sign, stop programming, right? Stop, no, you're doing the wrong thing. Go the other way. Go back to whatever it was you were doing before. It's terrible, right? This is, there's nothing semantic about this icon, right? This is sort of, the virtual machine does not depend on this branding to run. This is a choice, a design choice that continues to be made. So, our errors, programming errors are, you know, we get messages that are meaningless, that are very difficult to derive, you know, actionable meaning from, and negative imagery. And that's what we get bombarded with. And for me, the experience of getting an error, especially while I was learning, was this, see, what? Okay, the hobgoblin, what's, I didn't make a hobg, why, why does, I didn't do that, why is the world exploiting me, but no, I didn't, I'm sorry. I just wanted to write some, I'm a good boy, I didn't, I'm not the, why is your face, I'm sorry. And then we turned to the internet for help. And to challenge myself, I limited this part of my talk to Sack Overflow, which is actually quite good about cutting out, you know, really hurtful or, you know, unhelpful tech-bro answers. And they're still there, of course. So I searched for the, this little sentence that, I found a, I found this on Sack Overflow a while ago and I kind of freaked out on Twitter about it. Your indentation is terrible, as an opening sentence, right, it's not, you know, wrong, it's not that it could be better, it's just terrible. But at least this user posts a solution, he gives a sort of code as an example. I found this amazing user whose name I've blurred out just so I'm not, you know, publicly shaming him or them. I just searched for stop doing that, right? And look at the pattern of response here. It's one sentence, you're sending text somewhere before starting the session, period, stop doing that, period, end of thought, right? What else should I do, right? What, why is this wrong? What's going on? The amazing thing about this user is, this is just what they do. Yes. Most of his answers are either the only answers or the chosen answers. And this is, if you talk to this person, they probably don't think of themselves as a hurtful, toxic part of programming culture. But this is the stuff that chips away at people and makes them never wanna write code ever again, right? And when you're answering questions on a forum like Stack Overflow, you are a teacher. And if I was in class, or if I saw a teacher in class talking like this to students, you know, this is an awful teacher. This is just doing a bad job of teaching. And I've had people say like, oh, you know, people don't really have time. They're like, you know, they're being terse. They're in a rush. They don't post. Like no one is forcing you to post on Stack Overflow. It's fine. No answer is better than answers like this, I think. Because answers that are either overtly aggressive, which if you go on IRC, you'll find. Or sort of subtly micro-aggressive like this, they contribute to people feeling awful about programming and they make it very, very hard to fail. So this is sort of cut from the tweet that I wrote. There may have been more in all caps than I've been in here. Right, it makes people feel worse than they need to. So here's an elephant playing with a ribbon. Who gave him a ribbon? He's great. I'm happy. So we all feel, right? This is an example of a phenomenal error message. This is the programming language, ELM, which goes out of its way to present itself and be palatable to new users, right? They think about new users so much, the documentation is great, and their error messages are wonderful. So this is an error that I non-artificially ran into while learning ELM. ELM is a static type language. I have, most of my life I've been doing dynamically type stuff, so the static type stuff is unfamiliar to me. And I was like making mistakes. But this error message has, you know, most programming languages would sort of leave it at this one line. Type alias point must declare its use of type variable number. So that's not an incorrect error message, but it doesn't tell me a whole lot as a programmer. And then they show you where the error was, what you should change it to, and then this last paragraph is the home run. Here's why, imagine one point where, and so on and so forth, the rationale of the error is in the message itself. We just, I've never seen a language do this, right? It's, yes please, applaud ELM, this is great. I lost my mind, I'm so happy, it's great. Because when you're learning, this is exactly what you need, right? It's not just that what you did was wrong, I think that it shouldn't be that at all, but why the machine is sort of unable to continue. The rationale is how you grow. And I've been doing compiler stuff for a while, working on the closure compiler. And because of that, my understanding of errors has changed completely. This is actually what's happening when a programming system encounters an error, it just doesn't know how to continue, right? The information is either ambiguous or contradictory and it needs clarification or more information from the programmer. That's all an error is, right? It's a condition where continuing execution makes no sense, where a computer can't do that. Compared to this human did something wrong, right? And it needs to be punished for it. So that's what failure is, and that's why I think it feels bad. And the question of can we ever really avoid failing? The answer is no, right? I don't think that that is or will ever be possible. And the reason for that is there is a finite amount of things that we can fit in our brains at any point in time. All humans, without exception, right? Whatever that amount is, it's some finite amount. And it's immediately dwarfed by any non-trivial program. The total number of states that a program can be in just so quickly and vastly exceeds what a human can think about that we only ever really interact with computation at a very long distance. And because of that, certainty and predictability become very, very difficult. So this is a shtick that comes out at a lot of programming conferences, which is the total number of states that this function could ever be in. So this is a function that is written in C that takes two integers, sums them, and returns the sum, right? This is a very simple function that you almost wouldn't think about as a source of complexity, but an integer is 32 bits, so it could be one of four billion values. If you're summing two integers, the total number of states that that function can be in is their multiplication, which is that. 19-digit number. That's the total number of things that can happen in that function at any point in time. Given the semantics of C, when you factor in what is the compiler doing? What is the operating system doing? What time of day is it? How warm is the computer? The number of factors that go into the execution of software are just unknowable. You actually can't keep that in your head. So the fact that we're doing creative work, but also dealing with a medium that necessarily is this explosively complex system means that we are gonna fail. We're just gonna get things wrong. And this is why I think formally programming is and will always be difficult. It's a problem of managing complexity and irreducible complexity. And this is also why just seeing something work once doesn't guarantee that it'll ever work again because actually all the factors are changing. And there are operating systems like NixOS that try and solve this problem, but it's almost impossible to eliminate. So when you're doing something new, there's a chance of failure, because you don't really know what you're doing. This is the first time you're doing it. Likewise, when you're learning, there's a chance of failure because you also don't really know what you're doing. And when we're programming, we're always learning and we're always doing something new. It's very unusual to write the exact same program or app or script or whatever that you've written in the past over and over and over again. It's almost always something new, some combination of new things. And that newness, the fact that you never really know what you're doing is why just programming is prone to failure. And the reason I bring this all up is there may or may not be audio here. You probably can't hear that, I'm guessing. No, so this is a, I'll just play it on mute and narrate. So this is a scene from the movie Amadeus, which is about the very fictionalized account of the life of Mozart. And this is his rival, Salieri, who's been presented with original manuscripts written by Mozart because his wife is trying to get him this job at the emperor's court. And he's looking at these manuscripts and he's hearing the music, because he's a composer, he's hearing the music in his head and it's music like he's never heard of, he's never heard before, but he's also noticing that the notation has no corrections. That it's this first pass, absolutely perfect voice of God, no error thing. And the way he describes it. It was actually, it was beyond belief. First and only drafts of music. They showed no correct. I'll move on from this. But the, so it's just perfect music and the way he describes it is it's as if he was just writing down music that was finished in his head. And it's as if he was just taking dictation. And I watched this when I was really, really young and this sort of stayed with me. And I was kind of waiting for this moment when as a programmer, I would be able to just write perfect code, right? And when I went to school for programming, my teachers would show up to class with perfect code, right? And they'd hit run and it would run and then I'd go home and it would break. And I didn't understand that, right? And I thought there was some sort of light at the end of the tunnel when I'd actually be a good programmer and I could just sort of write things and they'd all be great. But that's fiction, right? That point doesn't exist and it can't exist. And that's a big part of what this talk is about is I think a lot of people feel like awful programmers because their shit is always breaking. And that's just what programming is, right? There's no, you're at the top level of the Pokemon evolution chain. There's no next phase, I'm sorry. And Alan Kay admits this. This is Alan, quote by Alan Kay, who's a titan of thought of computer science. And he equates failure with trying and pushing yourself. He's not at all interested in eliminating it or reaching some immaculate point where he just is never making mistakes ever again. Now back to Bob Ross. So Bob Ross fascinates me because his approach to teaching is so just positive and warm and welcoming and supportive. But he also produced a painting in 30 minutes on a weekly basis on television, right? So I do a lot of live coding and the systems that I built are live coded and to me this was kind of a goal. Like I'm not able to do this, but I would love to be able to come up and live code a video game in front of people in 30 minutes from scratch, just to show that whole process, right? That technology, I haven't built that and I don't have that skill, I can't do it. Now I was talking to someone about Bob Ross and how Bob Ross could do that and they pointed out that, yeah, but he, you know, kind of painted the same thing over and over again. Didn't you Bob? And that's not to knock him. That's the, there's a, not there yet, but there's a spectrum I think between predictability, which is doing something that you've done before that you know will work and exploration and experimentation. And they're not mutually exclusive, right? It's just, it's a spectrum and you just need to be mindful about where you are on that spectrum. How much of what you're doing do you want to be, you know, very similar to something you've done before or something you have, you feel good that it'll actually work and how much are you just trying something completely new? So this is, I made a couple of graphs to explain why I noticed that I have the same anxieties as a, you know, at 29 as a programmer that I did when I was a teenager. I don't feel measurably better about myself as a programmer over the last 10 years, although it is objectively true that I'm a better programmer, right? I just, this is just looking at my GitHub repo. Like I can see rationally that I have actually improved, but I was trying to figure out why I didn't feel any better. And my understanding of it, and this may be different for other people, but this is sort of my lens on it, is I don't think that my feeling about my skill as a programmer is actually tied to my skill at all. It's actually tried to the things that I'm trying to do at whatever skill level I'm at. So when I was 19, I was just trying to make websites. It was really hard, right? And 10 years later, I'm trying to write a symbolic compiler, and that's really hard, right? And the diff between what you're trying to do and what you're able to do is how you feel. And every, as I got better as a programmer, I just kept trying harder and harder things. So the feeling is constant, right? That's why there's no point where everything will just feel wonderful because I'd have to do this. I'd have to just make basic websites for the rest of my life. And I feel great, right? That sort of anxiety would go away. I could whip up a website really, really quickly, but that's not actually what I'm excited about anymore. So my ambitions and the things that I'm excited about grow with my skill, and that's what keeps that feeling constant. That's what it's been for me. Like right now I'm running this whole presentation out of custom slideshow software that I wrote, and I'm terrified that it's just gonna explode and eat this presentation in front of everybody, and I hope it doesn't. So if we can't eliminate it, I think we need to learn to love it, right? We need to embrace it as part of the craft of programming and not as this thing to be avoided. Failure, when you fail, that means you're pushing yourself. That means you're reaching beyond what you're capable of because you wanna be better. When you're failing, you're learning and you're growing, right? You're sort of saying to yourself that whatever you know now is great. It's wonderful, but there's more that you want, right? It's a sense that you haven't given up on just absorbing as much as you can. When you're failing, you're exploring things that are in that gray area, that there may be interesting surprises there, or there may be things that you don't want, but you're willing, it's a sort of brave commitment to go there and to see what's out there. Failing is not wrong, right? This is the slide takeaway from this talk, if anything, and the elephants, of course. But failure, and I mean this in your programming in particular, but also creatively, when you set off to do creative work and it doesn't work out, that doesn't mean that there's something wrong with you, right? That doesn't mean that you did something wrong. That means you did something right. That means that you're trying, right? For programming, there's a skill, and I teach this in all my programming classes, on extracting information from error messages. I notice that because of the way they're presented, a lot of students don't even read them, right? A lot of people will see an error message and like do this, do this. Even in better systems than mine, that report the actual line number where the error was, there's enough actionable information there, people won't look at it. So there's a skill involved in looking past all the sort of, you know, the mailstorm of text and finding stuff you can act on. But sometimes even descriptions are helpful, you know, less often than we would like. There's a trick of programming backwards. I don't know if anyone has seen this or done this. You could just write a game loop function and there's a get input function, update player, update enemies, update environment, and draw a frame. None of these functions exist. I run game loop and it says get input is not defined. It's like well I should probably write that function. And then you write that function full of a bunch of made up functions and it throws a bunch of errors. And you just sort of recursively write your entire thing backwards until there are no errors. This is a really interesting approach to prototyping that a couple of my friends take. And it uses errors as a channel of information, right? The computer then guides you towards the next thing that you need to do at all times. And like I mentioned before, just being mindful of the tension between exploration and predictability. So if you're writing code for a living on a deadline and you depend on that salary, you should probably not get fired, right? Not a crazy idea. But when I do freelance work, I turn into a very conservative engineer, right? I use logic and semantics that I've seen work before. I lean on things that are predictable and knowable. I don't get that crazy. When I'm doing my own stuff, I write my own programming languages and virtual machines, right, that are almost guaranteed to fail. But it's, again, it's not about exclusion, it's just about being mindful of what you're choosing to do, where on that spectrum you fall. So in this spirit of openness, I want to actually share with you one of my biggest, most recent failures. I was, you know, invited to show work at this wonderful game show called No Quarter. And I built a game for it. And I leaned very heavily on experimental tech, experimental game design. I was trying a bunch of stuff. And it didn't come together in the end, right? The controllers kind of broke. The game didn't really work. And even if they had worked, the game wasn't super interesting. And I learned a lot. I learned so much about the tech that I was building, about the designs that I was trying out and have all kinds of like directions to explore now. But that was a venue that I would have liked that to not fail as publicly as it did. And I wasn't being mindful about the predictability exploration spectrum, right? I leaned too heavily in one end of the other. And looking back, that's something that I wish I hadn't done. So I'm gonna show you an elephant fighting some birds now, because that sucks. Birds do not flinch, by the way. Did I get somewhere else, elephant? So, if failing is important and failing is such a big part of the creative process, but it's made hard by these external factors, how do we make it easier to fail is my next question. Another way of thinking about that is how do we make it easier to learn and explore, which I think is an easier slide to swallow, maybe. So, as someone who thinks about languages and compilers a lot, I think this is huge and not talked about enough. Languages, compilers, VMs, everything, they just need better error messages. And this is a really hard problem. The way many VMs and languages are built, once an error happens, there's actually no information to report to the user, right? The line number and all this kind of stuff has been optimized away. And there are ways to get it in there so that it's still present when things break. But really a lot of it is languages like Elm were built from the scratch to support that kind of very rich, very helpful error messages. But people building programming tools just need to take this more seriously, I think. We also, we need spaces where we can fail, right? We need spaces like BangBangConf, right? Where it's okay to just talk about broken things and share that experience. And we need less of this kind of programming, I think. And more communities where failure and experimentation is supported and celebrated, right? And the processing foundation and the community around processing and open frameworks and Arduino are wonderful examples of that. And that's why beginners flock to them. It's not because of the technology, it's because the communities are warm and welcoming and supportive. And if you teach code, I strongly encourage you to fail in front of your students so that they're not waiting for that Amadeus moment where they, like you, could just show up with immaculate code. And I mean this for any definition of teacher and student. If you're a popular programmer on Twitter with a bunch of followers, maybe don't only tweet about your greatest accomplishments. Maybe share with the people who look up to you the fact that it's okay to stumble, that it's actually you're gonna stumble. That's just what writing code is. As a rule, I prepare very little code in front of, for class. I mostly just confirm that what I'm doing is not impossible. And then I write the code in front of everyone and I mess up. Because I don't have the processing API memorized, no one does. I don't have, you know, I write in a lot of languages, I forget the particular syntax rules of this language versus that one. And I stumble and I get errors and I deal with them and I move on. And demonstrating that, I think, is a very important part of communicating to people what writing code is actually like. I have to acknowledge that in larger programming culture, being able to fail visibly and publicly is a privilege. And it's a privilege that I experience as a man. If you're a woman publicly failing in code, you're gonna get shot down a whole lot faster than I ever would and I acknowledge that. Which is why these safe spaces and safe communities that allow and support for that are extremely important. Because being deprived of the ability to fail, you're actually being deprived of a whole, you know, facet of the craft and it's unjust and unfair. So I hope that felt okay. Here's an elephant playing on the beach and I'll leave you with these words. Thank you.