 Hey everybody, I feel like I just left the stage, I'm glad to be back, it's wonderful to be in Austin. This one's going on the list. You know, I've seen a lot of code this morning, so I want to show you some code that I wrote recently that prompted me to kind of like write this talk. And I worked with a lot of junior developers and one of them said to me a couple months ago, she said, I want to be you when I grow up. I'm a fuck up. Before I go any further, I suppose I actually do need to do a couple trigger warnings. First, a trigger warning for the trigger warning, I swear in the trigger warning. Trigger warning, I do kind of have a potty mouth and I apologize for that, I will try to tone it down. The second thing is actually on a serious note, I do have a couple of animated gifts, so if you have any sort of motion issues or DZY accessibility concerns, I do apologize, in future versions I will edit and remove those, so sure, to hug this mic. Okay, so let me show you some code. What did I do wrong? Anyone spot it? Yes! Where were you when I started those two hours of my life? I did this six weeks ago. I've been a web developer for 20 years. I've been writing HTML code for 20 years and I forgot that. Now granted, there was a whole bunch of like NG data angular bullshit in there, but still, right, like I'm clicking the submit button and nothing happens. I'm like it's gotta be angular. There's a reason I call it Angerler because it makes me feel like this guy. I need baseball fans out there. Raul Abanyez, a man who takes pride in his defense. I hate this guy. I've got like six more but I won't, I won't, we'll skip those. One of my devs I work with said this to me, you know, and it's really true, like any time like I'm finding a bug and I'm trying to fix it and the solution is more than six characters, I stop because I'm rewriting something. You know, like I'm fundamentally changing the way the software actually works at that point. Generally speaking, right? It's almost always like I'm using comma or semicolon or, you know, white space if you're in one of those languages. So, I mean, it's a kind of a nice reminder to me and I was doing everything under the sun. I was cracking open Angler. I was searching Stack Overflow and I was looking through, you know, Angler's issue tracker at one point. I mean, it was kind of crazy, you know, and this sort of like lesson that, you know what? The bug is never in Ruby. The bug is never in Rails core. It's your code that's wrong, 99% of the time. One time, one time I found the bug in Ruby and it was already a bug that everybody knew about. So, it wasn't that exciting. So I posted this and it got a whole bunch of retweets and my favorite reply came from Microsoft, which I, how's that Windows 8 working out for you? Earlier, there was a hippie up on the stage who kind of buried the lead about her alma mater, go moon bats. But while I was at Goddard College, I was actually a performance major. I thought I was gonna be a stage hand basically, a lighting and set designer and I did that for a number of years. And one of the performances that I absolutely loved was the Scottish play. And one summer I got to do it and Henry V and Richard III in a repertory theater. So every night we're doing a new production. And it was such a small company, you were a stage hand and I was a messenger. And so one night in a production to Macbeth, I go on stage and Macbeth has just received the tragic news that his wife has committed suicide and he gives the famous, tomorrow and tomorrow and tomorrow creeps forth that this petty pays from day to day into the last syllable of recorded time. And then the messenger, myself, bursts in on stage and tells him, Burnham Wood is marching on Dunsonane, which fulfills the mad witches' prophecy of his downfall. The problem is that I wasn't actually in a production to Macbeth. King Henry or King Howell looked over at me and they say it's never the mistake, right? It's the recovery. So what could I have done in that situation, right? But my Lord, that news does not concern thee. No, I say, oh shit. Which, while technically, Elizabethan English, not good for the dinner crowd. It's always the cover up, that's what gets you. So without any other jokes, liar. I wanna tell you about my very, very, very first job. I worked for this little tiny web design company called Level Nine and it was named after the ninth Yi Qing, whatever, some bullshit. But we were doing cold fusion and pearl-based sites, PHTML, if you remember that, or SHTML, back in the mid-90s and I got the job because I was one of only 50 applicants who had heard of the internet. Which, you know, that was pretty awesome. I had not gotten a touring gig that summer as a stagehand, so I needed to find work, I needed to pay for things and I knew enough about computers to kind of fake it for the first few weeks while I madingly read, you know, HTML in 24 hours. And the job just kind of took off. But you know, it was the 90s. Yeah, we did not know what we were doing. If you think the plethora of JavaScript frameworks is insane, you have no idea. Does this look familiar to anybody? Okay, those of us who recognize it, I was at IHOP this morning, their Tuesday discount will be going tomorrow. Show your AARP card. Yes, this is VRML, or Vermel, virtual reality markup language. This was gonna be the hot new thing. And somehow I managed to convince a client, a local news station who were very impressed with our three simultaneous webcasting at six frames per second of their newscast to give us $35,000 to build a virtual marketplace where you could like wander through and purchase things from their advertisers. I don't think we actually shipped that. That was six months of my life. Quicktime VR, that was a hot thing. Remember that? This was back before digital cameras were even hot. And so you actually had to get this special camera on a motorized mount that made these very long film strips like this that you put on a scanner in sections and then paste it together and then use the $2,000 Apple proprietary software. And this was Apple pre-jobs, by the way. That's what got sucked. And I had to go to like a week-long workshop that cost my company $5,000. It was like literally like $15,000 my company spent. And on my say so, I said, this is the thing, right? This is the bomb. We never sold a thing. But I know a lot about camera focus angles and lenses now. My career really took off. Yeah, yeah. Somebody's computer crashed out there, I heard that. I apologize for that. I was part of that generation that made all of your website splash pages suck. But it paid the bills. I did a fun little basketball game for the Basketball Hall of Fame in Springfield, Massachusetts. And on the strength of that, got hired at a little bookstore in Seattle that you might have heard of. Somewhere in the six weeks between hiring me to be an action script flash developer and my showing up for day one, they canceled the project. No more flash for Amazon. But they hired me, so they figured I know what I was doing. Here's your Unix desktop. I've been using a Windows NT machine for the last eight years. So like, okay, system admin, I don't know. But I kind of faked it for a while because the state of Amazon in the early aughts, their software, this was a mess. It was this one giant monolith C two gigabyte compiled thing called Ovidos. And we all use this special little like C macro language that someone had written and extended until like it was actually touring complete, the scripting language to work with the C binary. It was pretty horrible. But I did five years there on the personalization and discovery team, which really meant that I was a cold heartless robot that used algorithms to fire people. We would price in the headcount with the number of people we could remove by doing an optimization. It was pretty brutal. Basically anything you read in the papers about how awful Amazon is, I gotta say, yeah. During my time there, around 2002, 2003, I was seconded to the email team because they needed a little boost in motivation. Sending one of us to work on your team was bad. And so I was tasked one day with sending out an email about the latest top selling opera book to everyone who had signed up for the opera newsletter. Email me when new books come out, right? That's kind of cool. And I love email. Emails is really great direct marketing tool. You can really reach out, make connections with people and you can track the click-through rates and everything. Unfortunately, opera and opera are right next to each other. Yes, so the book about the opera instantly became a number one top seller and business people were trying to figure out what the hell we did to make that sell so well. So that was a pretty clear mistake and I got in a lot of trouble for it. But why was I allowed to make that mistake? Right? Like why wasn't there a confirmation box or like multiple steps or like somebody who knew what the hell they were doing actually scheduling these emails instead of a new developer on her like second or third day on the team. I appreciate the trust, but maybe it was a little misplaced. But the cool thing about that is, it reminds me of Play-Doh. You all know how Play-Doh was invented? Okay, this is a great story. There was this guy, okay? And his job was to come up with a better kind of wallpaper cleaner. Did you know there was a kind of wallpaper cleaner to begin with? I certainly didn't. So anyway, this guy, you know, tries to figure out this wallpaper clean. I guess you would like smear it on the wall and peel it off or something. You know, but he tried, he came up with a kid's toy instead, non-toxic of course. But it's that idea that like, even our failures are these great opportunities to experiment, whether it's, you know, I've talked a lot about that with my students and my talks about like that idea that like failure is this learning opportunity for you to like understand how something changes and how, what the limits of your knowledge are. But from a business perspective, it's also a really interesting thing because the normal state of your code is now your control and your failure state is your experiment. You're doing a natural A-B test against your actual live running code and you can discover some really interesting things about your website's behavior or the way that your software handles stress, all those sorts of things. Those are really available if you have a really healthy engineering culture that can do things like post-mortems and learning reviews and you don't fire people just because they bring the website town in December, you know, during Christmas season when it's about, you know, $300,000 an hour in sales and good times, good times. I love Amazon. The shock treatments like really helped and like got me over those. All right, my next story. So how many people have hired somebody who just absolutely sucked? Like honestly. Okay, not as many hands as I would expect given how afraid we seem to be about hiring somebody who sucks. And either says that our process is really good for filtering those people out so we should just trust it and go with it or maybe there's just not that many bad people out there that we're hiring because I almost never worked with a bad person except for Dimitri. Now Dimitri got hired with this really awesome pedigree. You know, he had a master's degree. He was working on his doctoral in computer science. He had worked at several startups and my startup was so lucky to get this guy. He was gonna be our new head of engineering. He was just gonna do everything right and make everything happy in the world and we're gonna make millions of dollars and like move to islands. The reason there's a portion on this slide is because we gave him a very healthy signing bonus which he spent on a Porsche which he talked about in standup three times a week. He would start off with this whole speech about how the traffic was to get there in his Porsche and he would park in like very conspicuous spots and like offer rides to people and he was kind of a jerk and an asshole and one day actually my boss called me on a Friday night six o'clock and said, hey, we're letting Dimitri go. It's been three months. All he's done is write eight pages of documentation about something that we're not gonna use. I think that's all he'd done in three months. So, okay, we're gonna let him go. Carrie, I need you to go in and delete all of his passwords, all of his accounts so that he doesn't rage quit and like delete stuff. Fine, right? That's pretty standard. I mean, we're a very small company. We didn't have an HR or a policy for this yet. So I went in and I hard deleted all of his accounts, all of his passwords. My boss calls me an hour later and said, I think we changed our mind. So Monday comes around. Dimitri wants to know why he can't get into his email. I don't know, don't ask me. And of course, like we all knew, we all knew on the team because like immediately, like when I deleted everything, like I told the rest of my team, I'm like, hey, by the way, if Dimitri contacts you for any reason, please let myself know or our head of engineering then. So they all knew he'd gotten fired and now he's showing up on Monday and they're like, what are you doing here? So it was kind of a bad scene. And we eventually let him go two weeks later and he did actually rage quit and delete a bunch of stuff, but a backup sucker. This was a super dysfunctional company and at this point in its life cycle, it started like six of us in a garage. We'd gotten up to about 30, 35 at that point. I was really mad. I was really mad. I was just tired of this bullshit all the time. So like any good hippie socialist, I wrote a manifesto. That's the link to a somewhat redacted and not so cursey version on that website that I posted a few months ago. And when you hit this point of just like, you just give up, right? And I actually had a little model of a table, like a dollhouse table on my desk for a while with like tea cups and everything was all set. So I could just scatter and it felt really good. I've mellowed out now, I've mellowed out. So in this email, this is really distracting, isn't it? So in the email, I ended up like actually telling my boss, no, you're the problem. It is your bad leadership that's gotten us to this point. You're not running this company well. You need to fire yourself. You're the CEO. You can't be doing this, all this sort of stuff. And I expected to be fired. I mean, he just fired, then unfired, then fired this guy, right? So this is what he came back with. Good job. So now I'm the head of engineering. Now it's my fault. And so there's this idea that like, even though I did this completely crazy thing, it was self-destructive. Somehow I landed on my feet in that situation and I got a promotion because I told the truth. Because I said, hey, this is wrong and I wanna fix it. And this is how we're gonna fix it. Not just, I've got some complaints and you're gonna fucking listen to me. But hey, I've got some problems. Here's what's going wrong. Here's the solution. And so I've always taken that lesson that like, don't bring complaints up, you bring solutions up. And somehow people start thinking that you're good at your job when you do that. I don't know. Seems like this weird adult trick that I never learned. Cause I went to hippie school. Okay, I'm gonna show you some pseudo code now. A few years ago, I worked for a Rubian Rails hosting company. I'm not gonna mention their name. Some of you may be doing business with them. One of the little side businesses that we had was handling domain name processing, registrations and renewals, those sorts of things, right? And so we had a bulk deal with some third-party registrar service that would charge us $12 a thing. We would charge our customers 15. Excuse me. So we made about $3 per registration. Y'all with me so far? We make $3 per domain name. Okay, here's what our code did. So for each domain name the client had that is due for a renewal. Gonna queue up a rescue job. We're gonna build the client on our internal accounting system. Then we're gonna use our company's credit card to renew the domain. If the registrar returns any error, literally rescue. We're gonna retry. We're gonna time out after three attempts and we'll just recue this whole job and start over in about five minutes. Anyone see the fatal flaw in this? Yeah. So what we noticed was our largest customer, a six-digit a month customer, 120,000, got a new CFO. And he said, hey, I noticed about five months ago our bills went up quite drastically. Can you explain that? So this was the key problem for us. We were using our company's credit card to try to register. Unfortunately, its expiration date had expired. So we would try to renew this three times and then recue the entire job. Five minutes later, we would charge the customer again, another $15. So you can do that math and figure out how much we were overcharging the customer every day for every one of their domain names, for every customer. I'm not gonna tell you what Git Blame said about who did that because I think it's really petty and shallow to look to label blame on people. It took us about a week and a half to figure this out. And so you start doing the math, right? And I did the math and I said, we gotta get out of the domain name business. We're taking a beating. Like we're only making $1,800 a year on this service. And the same thing happened last year but the developers who fixed it last year didn't really fix it. They just like manually redid all the jobs and then they left, right? So two years in a row, we lost money on domain name registration. This kind of math and ability with money, if you believe that this is good, I want you to meet somebody. His name's Ray. Happy to take your money. So the thing I love about software and the thing that I'm learning about software after 20 years, I'm starting to learn this, is that there are two kinds of complexity, right? There's inherent and applied complexity. And some things are just complex, right? Some things are complicated. Some things are difficult. Software can exist in these different states and we have to grapple with that. But then there's this idea of applied complexity. And those are the problems that we introduce because we're humans because we exist within a framework of how we believe code should be developed, how it should be delivered, how it should be managed over time. Shazlav Vizek had this wonderful quote about ideology. And it's this idea that, you know, ideology is a set of lenses that we view the world through. However, ideology isn't a thing in and of itself. It doesn't bring anything new to the situation. What ideology does is merely open up the abyss of the present. That's on your sheets, yo. It's a bingo word, the abyss of something. I'm sorry? Yes, your ideology is in fact insufficient for dealing with the kinds of complexity that we work with. Very often we're approaching this from a very, a sense of things are what they are. A equals A. It's almost an objectivist. If anyone is familiar with Randian objectivism, right? The code speaks for itself. The code is correct. No, the code is not correct. The code is merely an expression of someone's ideology about how a problem should be solved, about what the best way to do it. Within the context of the time that code was written. It is when we apply a more romantic, if you will, ideology to go along with that, to say not what is the code, but what does the code mean? What is the sum total of it? What is it beyond simply the facts of it? What problems does it solve and who does it solve them for? Those sorts of problems are the ones that failure exposed to us. When we find a bug or we cause a bug, we can look at process. We can look at, well, maybe you're just not a good developer. We can say, well, maybe we need to do more testing. We can do all those sorts of things. Maybe we have to fire you. But ultimately as a developer and as a manager of developers, when my developers cause these sorts of problems, when they cause bugs and errors and cause these companies, sometimes lots of money, in the post-mortem process, in the learning review, I point out and I bring up the fact that our ideology has now changed. We can no longer assume that that will never be nil, that an outside user will never somehow get behind our firewall. That would never happen. We will never accidentally drop all tables from production. Too soon? Too soon? Okay. Wasn't even there then. Was it my fault? So when we start to question our ideology, it's an opportunity for us to question our ideology, to look at the lenses through which we're viewing the process of software and the process of how we're doing it. In my career, I was never strapped to a rocket and given high fives on the way up. I've made all of these mistakes and every single one of these mistakes, I thought, that's it, I'm done. I'm gonna get fired. Luckily, I can fall back on this punning poker player tippy thing. I guess I could follow fish or something. But every single time, what it turned out to be was, it made me a stronger developer. It made me see that failure states of code exist. That I questioned myself and I respect the code and I understand it in a more intuitive way because I see how it can fail. It is no longer a collection of parts that were put together in some other far off factory but I can see now the subtle interplay between disconnected pieces of that system. I become more in tune with it. I have more of a material tactile sense of that code and how it operates under different conditions. Something that's on the diagram on this side breaks and this thing over here breaks, how is that? I understand that now. I can do a fuller understanding of it. In poker, we talk about this idea that you're only ever playing one poker game your entire life, right? Sometimes players will come and go and sometimes the entire table will change but it's always the same game because the only constant that you have that you can control is yourself. And if you're playing against a specific player and you lose or you win, that has no bearing on the next hand or the next day or the next month no matter what you might think or how superstitious you are. And in a very similar way, the code is all one repository through our entire lives. Sometimes the problems change. Sometimes the technology changes. Sometimes the people we're working with change but we are that constant and it's what we are bringing to that code, our experiences and yes, our ideology that will inform us and make us the best developers we can possibly be. Thanks y'all.