 Hi guys, my name is Amanda Chang and I'm going to talk quickly about what I've learned about life through teaching adults to code. So the other day I was going through some old blog posts and I found this one from that I wrote when I was 23, which contrary to popular belief was three years ago, not five years in the future. And at this time I was teaching at a coding boot camp, which I am a big proponent of coding boot camps. And I think in order to understand why these lessons were so important to me, I'm going to take a tangent and or go on a tangent and talk about what I was doing before and then come back to these lessons, which I'm sure you guys are all anxiously awaiting. So unlike many of you guys, I was not a computer science major. I was a theater major, which is close. That blob on the right is me. It's a really low quality photo. And after college, I pursued lighting design for theater. So my first job was working at a summer camp. And the director of the camp every year had some counselor who for no particular reason she just didn't like and made their life very difficult. Luckily for me, that was me. I'm still not sure why she didn't like me. I think it had something to do with unrealistic expectations on her end. But five weeks in, I woke up after just being completely exhausted, having pulled some all-nighters, and realized I couldn't do another seven weeks. And I had to leave. So I told the director of the camp that I was leaving. And she said something to me that I will never forget. She said, I want you to know that I think you will never have a career. Because if you're the type of person who leaves when things get hard, nobody will ever want to work with you. Which is a really hard thing to hear as a 22-year-old from a 40-year-old. So next, I went down to Florida for an internship. And five weeks in, I got fired. So yeah, it was a great time. I didn't work a lot that next year. I was freelancing. And I started to believe a little bit that I actually wasn't going to have that career. Until one day, I woke up and something had to change. I read an article about coding boot camps. Enter the Flatiron School in New York City, which some of you may have heard of. At that time, I had a year of college computer science under my belt. I had started college as a computer science major. But I had no idea how to use that practically. None of it had stuck. And for the first time, I really had the opportunity to challenge myself intellectually again. I learned that code is creative. And I drank the Flatiron School Kool-Aid 100% and ended up teaching there after I graduated, which takes us back to the article. So what did I learn about life through teaching adults to code? First of all, I learned that being a beginner takes courage. I taught almost 100 students in a range of people who left their jobs. And every day was a reminder that the best things in life come from hard work and struggle. If you're not struggling, you're actually not learning. But there was another thing, and there's another thing that is really great for your mental health about being a beginner. And that's that this idea of being good. We really like being good as adults. But when we're a beginner, we don't have to think about being good because as a beginner, nobody is good. And also, nobody is bad, right? When you start something, you can't just say, like, oh, I took my first dance class and I'm really bad at dance. No, you took your first dance class and you are a beginner at dance. You have not had the time to figure out whether you are good or bad yet. And realizing this allowed me to start playing Ultimate Frisbee after I started teaching. So outside of code as well, that mindset allowed me to go and do something that I was not good at. And let me tell you, I was terrible. There is a picture of me there dropping a disc. And I've been playing for like two and a half years now, and I'm still not good. But it was that beginner period that made me realize that, despite not being very good at it, it's something that I love to do. So I really encourage taking advantage of that beginner mindset. The next thing I learned about life is that a positive or negative attitude is contagious. So I have a little anecdote from my time teaching, which is that I had a student named Seiji. And you guys have heard of Project Euler? Yeah, raise your hand if you've heard of Project Euler. OK, for those of you who haven't, for those of you who haven't, then Seiji set up a club called Club Euler to meet at 8.30 every morning to do puzzles. So not only were they learning from 9 to 6, they were also meeting half an hour early. Most of the class chose to attend it twice a week because he was so positive about it. It works negatively as well. In the theater, you work with a lot of jaded people, and the cycle just continues. How this applies to working in development, at my current job, I'm lucky to not be stressed out a lot of the time. But one week was just a really hard week. I was on call the same week as doing feature work. And one of my coworkers came in and offered to take my on-call shift from me. And I was like, you're the best person ever. This is great. And a few weeks later, he needed me to work late to get to deploy out. And it was easy to agree to do that because he did something positive for me. And the last lesson here is that there's always more to learn. When I was working in theater, a more experienced designer gave me some advice, which is to be a sponge. And in development, you can learn anything. You don't need anybody else to be there, right? In theater, I couldn't make a new theater unless I had a team, unless I got hired. In development, you can learn a new language just from your computer whenever you want. I recently started playing with processing. It's really fun. I can make the bunny move from the bottom of the screen to the top of the screen. And it makes me feel really accomplished. So in conclusion, this is a quote from the original blog post from 2014. All in all, I'm thrilled that my first full-time job demonstrates how important it is to strive for happiness, your own, and that of the people around you. So everything that I said today, these are all things that I knew. None of these are big life lessons, where I was like, this is crazy. I was so much wiser three years ago. But it was a good reminder for me, and I hope you all enjoyed it. I'm Dave Rupert. You might remember me from the internet. I am here to tell you. Oh, she just had slides here. So I made a slide deck in PowerPoint, and it's called, Hey, did you know Ruby kind of actually works on Windows now? Yeah. You maybe didn't know that, unless you're Yuhuda Cats. I wanted to tell you a little bit of the story. I do a podcast with Chris Coyer from CSS Tricks. Who likes CSS? Not, wow. OK, not many hands. That's actually really surprising. I usually hang out in the CSS crowd and y'all are different. So do a podcast about front-end web design and development. And we were looking at our stats for this podcast. It's like 16,000 listeners. And I went to the website, did the Google Analytics, and I was like, who does what? And I was surprised to see the demographic between Windows and Mac was 50-50. And I was just like, oh, wow, that's unexpected, because when I come to things like this, Macintosh, like everywhere, just a sea of glowing apples. And that's OK. That's fine. But we're an advice podcast, which isn't, I don't know, advice. Anyway, those are so dangerous, especially with two-wide dudes. So we're an advice podcast, but people would be like, right in and be like, I want to, how do I do this? My designers want me to do this thing in Sketch. And our advice was always kind of like, well, buy a Mac. And that's good advice. It's good business advice, probably, if you're doing a lot of Sketch work. But it's bad advice if, I don't know, you live in a country where that is 12 months of working to save up $3,000 for an aluminum laptop when you can get a Windows laptop for $200. Anyway, so I did a stunt on the podcast where I switched to Windows for a year. And it was like, whoa, what did I get myself into? Ray Bingo from Microsoft sent me out a laptop, a Surface. And he was like, here, try this out for a whole year. And I was like, all right, let's go. And I install, I got it. I install, set it up. And then I was like, doing a website and Ruby Rails project. And I went to do the Rails project and nothing. Didn't work at all. The Noko Geary gem had been broken since January. And it was like September. And in fact, one guy in Germany patched it, but no one merged the PR. Because no one had a Windows machine. Yikes. And then you go back and you're like, why is Ruby like this? And there's a video of DHH going, Windows is stupid and it's never going to succeed and it's dead. And you're like, ah, that's probably why. That was my great DHH impression. Is he still around? I don't know. All right. So it was really bad. And I even got on Skype calls with Scott Hanselman. He's a very popular .NET open source developer. And we just sat there and gem-installed things and watched it break for two hours. We were just like, gem-installed this. And you're like, oh, OK. All right, let's try it again and compile the MRI ourselves and stuff like that. And it just didn't work. And then three, fourish months later, I'm not saying it's because of me, per se. But Microsoft made a very exciting announcement that they are now offering Linux, a Linux subsystem on Windows. Has anyone played with this? Is this? All right, yes. OK, it's very exciting. And at first you're like, yeah, that's fake, right? Like, there's a Linux on the Windows. And it's true. They actually hired Canonical, who's like a they make Ubuntu. And Canonical came in and somehow patched this system into native window functions and things like that. And it works. And I use it every day. And it's awesome. And I'm here to show you how that kind of works. Is that OK? You guys want to see how it works? All right, one minute. Holy god, let's go. So you go to the Microsoft Store. And then you type Ubuntu. OK, no one knows how to spell it. You get Ubuntu as an app. Oh god, you tried on Windows. You can get the app. And then you just install whatever flavor of Linux you want. And then you get an app on your thing. And then you type bash. And then you get bash. And then it runs. And now I have a bash prompt. And you can do anything you do on your Mac or on your Linux machine inside this window. All right, great. Hi, I'm Jordan. Can you see this? Can you see this thing up on here? This arcane syntax on the top, on the left side of the screen. Yes? Great. OK, how many of you in here are Rails developers? Makes kind of sense. How many of you here do front end development at all? How many do React, Redux, cool stuff? How many love ES6, ES7, Babble, Webpack, whatever, whatever, whatever? So JavaScript, yeah. For those of you who don't do that, I recently started doing it maybe like six, seven months ago. And I'll say that the JavaScript ecosystem is great. It's very enthusiastic. It's fast-paced. And I'll say that about the JavaScript ecosystem. But of course, everything changes really quickly. And if you're not on React, 0.15, or is it version 15? I don't know. If you're not on React, 0.15, you have to be on 0.16. And PropTypes has to be moved out of the pack. It's all very difficult to keep up with. And I find it really difficult myself because I come from the Ruby world. I actually come from the Perl world where things move even slower. But in Ruby, you can just say gem install, whatever. Rails is pretty stable. Rails has a lot of convention. And Rails is easy for the easy stuff. The hard stuff is still hard, but the easy stuff is really easy. And JavaScript is not the case. So I went running away from JavaScript. And I found a programming language called Elm. Brad, is that your name? You talked about it a little bit. It's a cool language. And I don't pretend to know a lot about it, but I like it a lot. How many have heard of it? Show of hands? Oh, wow. So next year at ElixirCon for something, you're going to go to all the Elm talks. What is Elm? Elm is a functional programming language that compiles to the browser environment of JavaScript. It doesn't do the server-side stuff yet. And it's designed to replace everything that you do on the front end. It will replace everything you do on the front end. And it's very cool. So it's a functional language. So you have purity, meaning side effects are data. And all of your functions have inputs and outputs and no side effects, like console logging. It's not a thing you can do it. But you don't do it as console logging in Elm. And it went away. It's going to come back. OK. Wallet's coming back. One of the great things about Elm is that it's a programming language, yes, but it's also this whole design pattern as well that ships with the language. And you can't really choose to not use that design pattern to write your applications. And if you ever use React and Redux, it will feel very familiar to you because React and Redux took a lot of their inspiration, especially Redux, from the Elm architecture. And that constraint helps a lot. But we know that when we design by constraint, the more constraints we have, the finer it gained our design in, the more concrete things are, and the easier it is to do certain things in those constraints. It turns out that Elm picks a bunch of really cool constraints to make it easier to do one thing, and that is write single page web applications. And that's it. So this is the basic version of an Elm program. The real version is not too different. But we have here, I've never one-handed vimmed before. We'll see how this works out. So we have three functions that make up an Elm application. The model, which is the state of the application, is kind of like the Redux store. The view, which is kind of maybe your React JSX. And the update, which is maybe your reducer, if you've ever heard of Redux reducers. And all the application is you start with a state. In this case, this is like the Hello World Elm app from the Elm documentation site. I'm not going to type, so it's good. Yeah, I don't do live coding. This is, it never works out well. So thank you, though. This is the Hello World application. It's a counter. And we can click it, and it goes up, and it goes down. And that's kind of it. So instead of having event handlers, like we would do in JavaScript, in Elm, we have, well, this is kind of, this is our view. This is like equivalent to writing JSX. Maybe I will type something. OK, so let's say I'm writing JavaScript instead. And to do that, I'm just going to open a multi-line Elm comment, because Elm format would do bad stuff if I didn't. OK, so let's say we want it to make div, and we put inside of it a button that's our click handler. And we would have some text for minus. And we have another div. Oh, I'm so sorry. I can definitely do that. That happens everywhere. We'll have another div, and we'll have whatever the model is. And we'll have another button here. Buttons have opening and closing tags, right? I think so. Yeah, that goes to show how great of a JavaScript developer I am. And you can point out mistakes to me, as I'm typing, if you'd like to. Like, I think I just switched increment and decrement. Increment, sure, that'll work. OK, so this is kind of the equivalent JSX you would write. And the decrement function would be some function that would take the model and just decrement the state, just like we're doing here. And the increment function would do the same thing for the plus. The cool part about Elm is that you get, so it goes, you start with the model. You start with the model. And in this case, the model starts out as being the number zero. And then you render a view, which is this tree of HTML. And inside this tree of HTML is a bunch of event handlers that can get dispatched to the Elm runtime. And when you click on either of these buttons, Elm will dispatch a message. You see that type message? And it will go into the magical Elm runtime. It'll handle all the side effects. And Elm will invoke the update function that you provided with the message itself. In this case, if we click decrement, it'll pass in decrement to that lowercase m message. And model will be, well, the current state is zero. Well, the current state here is negative 3, but the current state is zero. And when I say decrement, it will invoke update with decrement and zero. And then we go into this case statement and we pattern match on decrement. And then we return a new version of the model. We don't mutate the model. We return a new version of it because in functional programming languages, you have immutable data. And it just returns the model, whatever it was, subtracted one from it. And then that gets invoked with your view function, or your view function is invoked with that new model again, and you get your new state. So it's all one directional. Of course, we've gone from the Polymer 1 and Angular 1 land of two-way data binding, and everyone realized that one-way data binding was better. But anyway, that's an overview of Elm. It's great. Elm-ling.org. That's it. Thank you. Thank you. Hey, so my name is Nick, and I like to give disaster talks. So this, of course, is one of those. I'm going to tell you about Cockroft's Folly, which is my favorite British nuclear disaster because it's the only one, really. So after World War II, this guy, Sir Winston Churchill, decided that the UK needed to be a nuclear power. They needed a nuclear weapon to remain relevant on the stage of World Affairs. And the United States was only willing to share nuclear technology with nations that had already developed a bomb on their own. The reason for this is the US wanted to prevent proliferation. You see how well that's worked out. Despite British scientists being part of the Manhattan Project and actually working to develop a nuclear weapon in the United States, the US still wouldn't share intelligence with them. So Churchill and other people in the British government gathered British scientists together who had been part of the Manhattan Project and asked them to build a bomb. Well, to build a nuclear weapon, you needed fizzle material. And so they decided to skip uranium and go straight to plutonium. And in order to get plutonium, they had to build a nuclear reactor. So their scientists, having been exposed to the Hanford B nuclear reactor in Hanford, Washington, or in Richland, Washington, excuse me, decided to build a reactor based on that. And that reactor is actually one that produced a lot of the plutonium the US used during the Manhattan Project. There's one key difference, though. Hanford B was a water-cooled reactor. Now the challenge with that is if you lost electric power, you lost your water cooling, and the reactor explodes. Well, Hanford B had a 30-mile evacuation zone around it. The UK didn't have that kind of space. They're a tiny island. They don't have that much room to build a nuclear reactor. So they decided that they needed to make their reactor passively safe, something that would work even if the power failed. And so they built an air-cooled nuclear reactor. Seems like a great idea, right? You can see lots of little holes in the picture. That's actually where they would put nuclear fuel into the face of the reactor. They would load it with uranium. And the way it worked is you would put these canisters in the face, push it through the core over a period of time, like a month, two months. And as these fuel cylinders passed through the core, they would become more and more a higher and higher percentage of plutonium. Eventually, they'd get pushed off the back of the reactor in this channel of water and flow out the other end to a plant that would extract the plutonium out of them and send it on into the weapons program. And to cool the reactor, there was air forced through it by these big fans. And if the big fans failed, the genius of this design, at least in the scientist eyes, is that it would still cool itself by convection. There would be hot air still rising up this chimney that would pull air into the reactor and keep it cool. There is a slight problem with that, though. Terrence Price, one of the physicists on the project, theorized that a fuel canister could theoretically fall out the back face of this reactor, crack open, and release all sorts of nasty stuff into the atmosphere. And if that happened, it would pollute a large portion of the British countryside, along with the Irish Sea. So he brought this up in a planning meeting and said, we should really do something about this. We should put a filter at the top of our chimney. But the general consensus was, well, this is not really that a real risk. We're not going to miss the channel that often. We don't really need a filter. And what's more, if we try to do this, it's so horrendously expensive that we can't afford to build this reactor. And that's where they left it. It was considered so expensive it didn't even get recorded in the notes from the meeting that he brought it up in. It was so unrealistic. And that's where things stood until this gentleman, Sir John Cockcroft, the director of the program, heard about the situation. Now, he fully understood the risks that Terrence Price raised. And he personally insisted that they install a high performance filter at the top of their chimney. And those filters became known throughout the project as Cockcroft's folly, because everybody knew they weren't going to need these filters. That's foreshadowing. Now, the interesting thing about this reactor is it used graphite as a moderator. Now, when I say moderator, the way nuclear chain reactions work is they throw neutrons around. And neutrons fly into other uranium atoms. And that causes more neutrons to be released. And it's a self-sustaining cycle that releases heat. Well, the problem is those neutrons fly off so fast that unless you slow them down, they're not going to hit anything. They're just going to fly off into space and not cause a chain reaction. So you layer the uranium in there with graphite, which slows the neutrons down. And that allows the chain reaction to sustain itself. There's one problem with using graphite as a moderator, though. When you bombard it with neutrons over a long period of time, eventually the crystalline structure of graphite gets all out of whack. And it builds up what's called Wigner energy. Wigner energy is huge potential energy that will eventually release itself as a burst of heat. Well, the way that you combat this in a nuclear reactor is you have to heat the graphite up enough that it becomes plastic. And this crystalline structure will snap back into place. And so they had done this several times. It was a routine part of operating this particular reactor. So on October 7, 1957, when they noticed that the reactor about six years in was running hotter than they expected it to, it was just a sign that there was Wigner energy built up. And so they needed to do an annealing cycle to get the graphite to snap back into its lattice structure. As they heated the pile, though, they noticed that the temperature of the pile began falling everywhere, except for fuel channel 2053, not the even heating that they would have expected during an annealing cycle. So at the end of the cycle, once the reactor cooled back off, they came to the conclusion that, oh, well, the reactor hasn't actually annealed, we need to do another annealing cycle. And so they started to back up. This time, the temperature rose across the pile exactly as they expected, but then at the end of the annealing cycle, the temperature kept on rising. Well, they needed to cool the core down, so they turned the ventilation fans up to full and started blowing as much air through this reactor as they could. Well, about that time, the radiation alarms in the chimney started going off. The team assumed it was just a burst fuel cartridge, no big deal, had happened before. They tried to scan the core of the reactor with a remote probe, but it was stuck. So Tom Hughes, the assistant reactor operator, convinced the team that they needed to go to the reactor face and pull out an observation port and look and see what was going on. To his horror, the fuel inside was glowing bright cherry red. So at this time, Tom Toohey, the director of the reactor, climbs up to the top of the pile, looks over the back, and can clearly see fire coming out the back of the reactor core, not a good situation. It turned out that the anomalous heating that they saw in fuel channel 2053 wasn't annealing after all, it was a burst fuel cartridge that had caught on fire and was burning hot enough to ignite the normally-inflammable graphite moderator. It turns out when they had turned up the fan to cool down the core, all they had done was fed this fire and allowed it to really catch. It was burning really good at this point. And so they had to try to figure out how to get this fire out. Luckily for them, there was a shipment of liquid carbon dioxide for a gas-cooled reactor on site. They tried to pump the carbon dioxide into the reactor core, no fact. They attempted to use water, which is a really terrible idea on a nuclear reactor, because when it's burning that hot, the fire actually strips the oxygen out of the water and you run the risk of a hydrogen explosion. That still didn't get the fire put out. So finally, after the core had been burning literally for four days, they evacuated everybody from the site, except for the fire chief and the site manager, and they turn off these big fans. They turn off the only means they have of cooling up down this reactor core. Slowly but surely, the core temperature begins to drop. They go out to the reactor face and try to pull the viewport out, and they can't, because the fire is trying to get oxygen from wherever it can, so it's sucking that viewport seal in tightly. They finally started decommissioning this reactor last summer. This is one of the fuel cartridges, and you can see that telltale yellow at the top. That is uranium oxide. So there were fuel cells like this throughout the reactor that are bursting. Ruptured, melted, all the way through the core. Had it not been for John Kotcroft and his folly, the stuff that burned out of those fuel canisters would have been scattered throughout the English countryside. Instead, it's all entombed inside this reactor. It was so toxic, they literally let it sit 60 years before they started trying to clean it up. Building software, especially something brand new, is a lot like how these early nuclear reactors were built. They needed plutonium and they needed it now, just like you need to ship software and you need to ship software right now. I've noticed in my time in software that software engineers fall into two buckets, pragmatists and idealists. The pragmatists are wired to get the job done. They're almost always comfortable taking on technical debt to get the job done faster and get working software out the door. Idealists, on the other hand, want to build properly engineered systems. They're the ones that will fight for more time to build it right. And guess what? They're both right. Every team needs a mix of idealists and pragmatists. Had the windscale team not had a couple of idealists in Terence Price and John Kotcroft, the reactor would have gone online without a filter at the top of the chimney and it would have radiated a big chunk of the British countryside. The rest of the team was of a pragmatic bent. Completely ignoring Terence Price's concerns is too expensive to solve and just trying to get the reactor online, which they did. They produced plutonium about a year after they went live. The trick to getting this balance is to make deliberate choices together as a team and you can't do this unless you have both idealists and pragmatists on your team and you have these discussions on a regular basis. So learn to make the deliberate choices as a team. Find the balance between idealism and pragmatism and write great software. Thanks.