 So, yeah, this talk is Emilia Bediria Learns to Code. I am Kylie Straubly. I just want to welcome you guys to Atlanta. I'm sure you've been welcomed already. I just want to brag and say that I live here in this awesome city. So there's that. It's just a fact. I live and work here, like I said. This is my first time speaking at a tech conference if you didn't notice by my, like, complete lack of respect for, like, societal expectations and, like, how to not be a weirdo. Yeah. So I wanted to tell you guys about a character who was really important and special to me when I was a child. I guess before I get started, though, can I get a quick show of hands? Who here, at any point, so now or sometime in the past, was ever a child? Any current or former children? You laugh, but not everyone raised their hand. So we have a couple in the audience. Cool. Yeah. So the special character in my childhood was Emilia Bediria. And I liked Emilia Bediria because I really identified with her. She is notoriously literal, and she's practical to a fault. In many of the stories she works as a maid. And in the titular Emilia Bediria story, Emilia Bediria, she's working as a maid and she gets these to-do lists. And on one of the lists it just says, prepare a chicken dinner. And Emilia's never heard the term or the phrase chicken dinner before. So she tries to rack her brain and figure out the most logical conclusion. What is a chicken dinner? Emilia surmises that a chicken dinner is a dinner for chickens. So, yeah, she serves up cracked corn because if you know anything about chickens, you know they love eating cracked corn. You know who doesn't love eating cracked corn for dinner? Emilia's employer is the Rogers family. In the book she is consistently just causing them to be super exasperated and flabbergasted at her unique new ways of being extremely literal. She's determined to complete work, like even when it doesn't make sense to her. Another time in the same story she has a to-do list item that says dust the furniture and the way that it reads is strange to Emilia because it seems to indicate they like dust applied to the furniture and she's like, that's weird, but that's what was written. So that's what I'm going to do. Even though I think it makes more sense to remove the dust from the furniture. Does this sound familiar to anyone in here at all? A request is worded in a way that seems to indicate that something really, really strange is needed and you're thinking surely this isn't what they want, but it's what they wrote so you deliver to them only to be informed that this is not the desired result. This happens sometimes in software development, maybe, to a couple of people. That guy laughed, it happened to him, so that's all I mean. Thank you, whoever you are. I feel like I have a really strong connection to you now as friends. So as an adult now you can see how I'm starting to think of Emilia Les as just kind of a silly character and more of maybe kind of an archetype of a developer. The literal interpretations, the silly mistakes, they're not asking for help. Yeah, and then at the end of the stories, Emilia always saves the day. She usually does this by preparing one of her awesome desserts, usually a baked good. In this story, Emilia Christmas, Emilia Bedelia, she saves the day with a date cake, but because it's Emilia Bedelia, when she can't find the fruit dates, she cuts up a calendar and uses those dates instead. But everyone, yeah. In the last picture of the book though, everyone's eating cake and smiling, so I guess that is really good for them. That one still escapes me. I don't claim to be the Emilia Bedelia scholar. But everything ends well. And so I think that as developers, we tend to talk about our own stories this way, especially people who are maybe self-taught developers or you went to a boot camp. Just those of us who don't have the traditional computer science background, we say, you know, I wanted to be a developer, so I did this stuff and I made a lot of mistakes and at the end we have this redemption that we talk about and now everything's perfect. And that works because it's a really good story. People want to hear these good stories. You know what? Honestly, okay. I'll level with you. This is my first conference talk. I am extremely nervous. It is the afternoon. You seem sleepy. I'm seeing glazed eyes. What if instead of doing the talk, I read you a really good story instead? Yeah? Okay. I'm going to get my book. The name of the book is Emilia Bidella Learns to Code. Written by Kylie Stravely, very good prolific author. Look that person up. Illustrated by Sam Smith and inspired by the works of Peggy and Herman Parish. Emilia Bidella is speaking with her employers, the Rogers family. It's time for our annual review. Mr. Rogers says, Emilia, you've always done good work once we managed to get on the same page. We definitely appreciate your unique approaches to problem solving. But you're so literal, it drives me insane. It's like talking to a robot or a computer. Talking to a computer, Emilia, thanks to herself. Now that sounds like fun. If you don't have binary memorized still, I know everyone obviously hasn't memorized, but if someone didn't, she's saying hi in binary. Emilia reads that to talk to a computer, you have to speak their language. But it looks like there are quite a few languages you can use to talk to computers. Emilia's new friends, some Rails girls, mentioned she might enjoy a language called Ruby. Emilia thinks that sounds nice enough, but why Ruby specifically? Why Ruby? Why not Ruby? I bet you guys would like that. Shout two strange foxes who have mysteriously appeared. Ruby has elegant syntax. It's natural to read and easy to write. They follow up. If you like Ruby, you'll love Ruby on Rails. It's a web framework that's optimized for developer enjoyment. Rails lets you write beautiful code by favoring convention over configuration. Yeah, what he said. An easy way to talk to the computer that's designed with developer happiness in mind. If being a developer is what it takes to talk to computers, I certainly want to be happy while I do it. Ruby it is. Emilia says to no one in particular, as the strange foxes have already disappeared in the same mysterious way they arrived. If you're a beginner or someone who didn't read Wise Elegant Guide to Ruby, you should check it out. Sorry, I didn't want to make an inside joke. I thought it was rude. This Ruby on Rails stuff is easy, Emilia thinks. It's got HTML and CSS. I know how to use those. There's a database. I've worked with databases before, too. Emilia is working her way through a beginner Rails project when she realizes that she needs to add a table to her database. Looks like this schema file is a central resource for the state of the database. There's a bit of audience involvement on the next slide. I'll do it first and you guys can join in. On the next ones, you'll get it because there's a pattern. So what does Emilia do? You guys could say that. So what does Emilia do? Oh my gosh, I knew you'd get it. She edits the schema, of course. Now she has another table in her database without involving those strange, randomly numbered migrations. I can't read this at all, exclaims Emilia's computer. In some languages or frameworks, you can edit the database schema directly to make changes to the database, but in Rails, the database schema is just a representation of the state. The migrations seem to be randomly numbered, but those numbers at the beginning of the file are actually the date time that the migration was created. Emilia nods and her computer continues. Since we've only built a really basic database, it seems like the migrations represent individual tables, but they really represent the changes that are going to be made to the database. I use the migrations to make the database for you and put the date time of the last one migration at the top of the schema to let you know that the migration and all of the previous migrations are included. What a silly mistake. I won't do something like that again. I'll remember to write migrations when I want to update the database and run them using rakes so that they'll update my schema file. Emilia is cheerfully working on a brand new application, totally independent of tutorials and guides. She's not exactly sure what all she needs, but she knows she can cover most things using the Rails Generator to scaffold new models, views, and controllers. You guys ready? She uses the scaffold for everything, of course. I'll just use the Rails scaffold to create my new model. That's just as easy as writing the files myself. In fact, it's even easier. Plus now, I have the controllers and views pre-made in case I need them later. Can you guys see from the illustration? Oops, she has a blueprint for a doghouse, but because she used the scaffold, she's building this dog mansion instead. Do we really need all of this? Ask Emilia's computer. The Rails scaffold is handy, but you don't have to use it to create everything. You can just use the generator to generate a model, view, or controller. You can even create new files without using the generator, and Rails Convention over Configuration Design will make sure things match up how they should. But it's so much easier this way, says Emilia. Easier for you maybe, replies Emilia's computer. I still have to load all of the assets created by the scaffold. Plus, do we need all these scripts? I thought you just needed a model. You're right, we don't need all of this stuff. I didn't realize it added a lot of extra work for you. I'll be sure when I use the scaffold to only use the parts I really need. Okay, so I know I don't need the Rails generator to make everything. I can just create the files myself, Emilia says. She remembers what the foxes told her, that Rails is designed with Convention over Configuration. Still not sure what that means, but I want to write the best code that I can. I'll follow the framework's Convention and write good code the Rails way. In each of her new files, she mimics the code and style generated by the scaffold. If this is how DHH would write Rails, this is how I'll do it too. He didn't come to this, did he? Is he here? Raise your hand if you're DHH. Perfect. Oh no, Emilia, exclaims Emilia's computer. Convention over Configuration doesn't mean you only have to use Rails within the framework's conventions. It just means you don't have to configure the connections between conventionally named models, views, and controllers. When you include all that code, you can accidentally include different features. For instance, leaving the two respond width blocks in the controller could allow you to inadvertently expose a JSON endpoint for that controller. So that's what that means, says Emilia. I definitely don't want to expose a JSON API in this application. Just because I can do something with Rails doesn't mean that I should. I should only include those things when I need them and not just hold on to them for later. You got it, Emilia. Emilia's having a lot of fun at her first hackathon. The team she's working with is requesting a ton of features, many of them directed to all different routes. Emilia's teammates are excited but getting antsy for the new web views for their app. I need to make a lot of routes, Emilia says. She activates each of the routes by raking them before committing and pushing her code. With each new route, she writes a new HTML file, adds the route to the RouterB, and rakes the route. Rake is shorthand for Rubymake. So I rake each new route so it will be available in my web views. I'm not going to make the same mistake I made with migrations. Forget to rake my routes, expecting them to be there anyways. Did you guys read the Rails 5? Here's just a non-sequitur. Did you guys read the Rails 5 proposed changes yet? Okay. They might alias Rails to rake and change some of this stuff up so it won't be as confusing. So this is a really good slide, so do welcome for this good slide in that fact. Oh, no, Emilia. You don't have to rake the routes to activate them for your application. Rake just shows you a preview of what the routes will look like in a URL. Why not, asks Emilia? I have to rake the migrations. It makes sense that I need to rake the routes, too, right? Emilia's computer explains. It is a little confusing that rake creates your database migrations, but you don't need it to create routes. Rake is just a tool that run tasks. The routes are created when you add them to the RouterB. There's no harm in raking the routes, but it's not needed either. Oh, I think I'm getting it a little bit now, says Emilia. Rake is a tool, and it can run a lot of different tasks. Unlike the schema, routes aren't generated. I wrote them myself, so they exist as soon as I write them. I can't believe I spent so much time raking each new route I added. My teammates are going to be excited to see all the new routes much sooner. You're really starting to get it, Emilia. Emilia is writing an application with her to out-of-town friends, Fred and Carrie. Fred and Carrie have been developers for a while and always hit the latest trends and ruby gems. Fred and Carrie say, gyms are great, they're just libraries of code. Why write it yourself when you can put a gym on it? You can find a gym for everything. It's like you never have to write your own code. Emilia thinks, what, did you guys do that? That's so bad. I can't believe you guys would do that. Emilia thinks, these gyms are pretty handy. Seems like I can just drop them wherever and have access to a ton of code written by someone else. Emilia adds all of her favorite gyms to each new project she starts. I'll save myself some time and some code. Fred says, you know what this app is missing? Gyms. Let's spruce it up. Make it pretty with the draper gym. Carrie says, what a sad little application. I know, I'll put the Rails admin gym on it. That's the whole joke. Just kidding, I'm sorry, that's a great gym. Whoever did it, you did a good job. Did you see this app before? I didn't. Right, I thought so too. Not so fast, says Emilia's computer. Gyms can be very useful, but they're not the answer to every problem. Every gym that you add to the gym file might have dependencies on other gyms, and those might have even more dependencies on other gyms too. All of those dependencies can cause complications and eventually make it harder to upgrade your project. Oh no, I don't want that. I heard Rails 5 is coming out soon. I'll want to try out TurboLynx 3. Try it, Emilia. I guess I should make sure the gyms I'm including are the ones I'll really need. Emilia is working as an intern at a software development company. The client she works with, Business Corporation Inc., requests that new parameters be added for customer addresses. Parameters, Emilia thinks. I know exactly what to do with params in a Rails app. She does exactly what they ask for and adds them directly to the params hash. They'll be so excited. Have you guys... All right. Two people have had potato hash before. Potato hash is hash browns and onions and customer address parameters. And it's an Atlanta specialty and you can get it at Waffle House. I'm glad my friends came to this. I get the feeling that some of you don't find this as amusing. Whoops, says Emilia's computer. A client can save parameters which seems like a general term, but that word has more meaning in a Rails application. Turns out what the client really needs is just a table column to save records to. Well, at least my workplace has code review, so the mistake is caught and corrected before being deployed, says Emilia. Hey, don't be so hard on yourself, Emilia, says her computer. This is a great opportunity for you to push back on a client request in the future when they seem off to you. And you were able to teach a semi-technical client a little about Rails architecture in the process. Yeah, I guess you're right. Nothing bad happened and I learned something. I guess I am getting the hang of this. Emilia is coaching at her very first Rails workshop. She finally knows enough to feel comfortable coaching and helping others learn to code. She overhears a group talking about scheduling tasks for an add-on to the workshop's base project. They want to use a time field for this, but everything falls apart when they try to schedule dates very, very far in the future. Emilia's worked with future dates before and made this very same mistake before too. She heads right over and explains, hey, I've had that problem before too. It's an easy mistake to make, but if you use date time instead, you won't have that problem. That's why I always use date time whenever I need dates. That's a good one. So you had to be here at the beginning, but... That's not even the silliest mistake I've made yet. I'm still making mistakes every day, and that's okay because making mistakes means that I'm learning. Even if it feels like I'm learning things the hard way, I know a lot more about why things work the way that they do. Plus, sometimes my mistakes help someone else learn too. When we talk about why it happened, I can help them learn better. Maybe they try to edit the database schema because they've worked with Microsoft Access before. Whoever that is could be anyone here, probably one of you guys. And I can help them learn by pointing out the analogous parts of ActiveRecord in a Rails application. I think, though, that's what software development is about, making a lot of mistakes and learning from them. That was pretty cute, right? Yeah. But that's not really how it is, though. Before I told you the story, I told you the story about the story, the meta-story, if you will, which is that a lot of times as developers we frame our struggles into a cute little story and tie it up with a little bow at the end. It was hard and then I figured it out and I redeemed myself and I feel good now. And Amelia always has a redemption at the end of her stories, too. But what you may or may not know is that there is a series of Amelia Bedelia stories. She's always having these ups, these highs, the date time cakes, I assume, full of calendar clippings as well. And she's having loads, again, and that's exactly how it is being a developer. You have the highs and the lows, you have the awesome days, and you have the Amelia Bedelia days. You don't really ever stop making mistakes. This is what the day-to-day is more like. So, unlike a book, our stories don't end with a cathartic day anymore. Ideally, our stories don't end for a long time because, I don't know, that might mean that you're dead or something, and that would be sad, and we would hate that. But beginners don't know that this is what our day-to-day looks like. And I wrote this talk because I want people to share their mistakes. So I guess I should probably put my money where my mouth is, and I'll go first since I'm saying that I want you guys to share your mistakes. Have you guys heard Gary Bernhardt's talk? He gave it at Codemash in, like, 2012, maybe, maybe some other places, about wets. This is how you say it, that sounds familiar. All right, like, two people have heard it. Okay, well, this word, which I won't try to say again. It just means, like, a weird quirk or strange, unexpected bug in a language. And so Gary found a bunch of these in Ruby and Python, maybe, and definitely in JavaScript, where the language just behaves strangely. So recently, for me, one of my big mistakes, I was working with a more senior developer at my company, someone I really respect. And we were pretty deep, like elbows deep, like in the mud of writing a spec for like a strange, fragile case. And as part of this, we wanted to verify that something happened at a certain time. So we were trying to force equality on time.now. So time.now equals equals time.now. And they were returning false. They were not returning as equivalent. And we thought we found a what in Ruby, and we were like, oh, my gosh, these should be equal to each other. And they're not. Like, we're the Gary Bernhardts of our time. Like, even though he is alive and is the Gary Bernhardt of our time, yeah. We were like, we're Ruby Heroes. And so we go into the company chat room of the back end team and we tell our teammates, we're like, you guys can't explain this. Look, time.now equals equals time.now returns false. Isn't that ridiculous? And everyone was like, that's pretty standard stuff. That makes sense. Like, what is the problem here? And we were just so entrenched, like, super laser focused on this one thing that we were doing. We forgot how time worked. Like, that's a pretty silly mistake. And that happened recently. And the person, yeah. And like, not just it happened recently to me and like, I know about time and stuff. But like, this happened to like a senior developer that I work with who I think is extremely smart. And they are extremely smart. But because we were so entrenched in what we were working on, we just forgot and we weren't thinking. And this kind of stuff happens all the time. These kind of things happen to me, obviously. Like, six of them happened up here. I didn't tell you about all of them. They happen to the people that I really look up to and in real respect. They probably happened to you. Probably DHH is in here. So they probably happened to you guys. So, that was a good trip. Whatever, fine. And they happen to the developers that you work with that you might think are infallible. Beginner developers make a lot of mistakes. I'll come out and say it. They make a lot of mistakes. I make a lot of mistakes. But the biggest mistake I think beginner developers make, and the one I made too, was thinking that I was alone in all of this, that I was the only one making these dumb mistakes. It's easy to feel like you're the only dumb one. It's so easy to feel that way if you're not talking to people about it. And, sorry. Beginner developers are much more prone to these amyloidialisms, because unlike senior developers, they don't know about that, like, sine wave of highs and lows that I showed you guys that we kind of go through on a daily or depending on how quickly you work hourly basis. And they don't realize this for two reasons. One, they don't ever ask us. And two, we don't tell them. They don't ask for a lot of reasons, but basically it boils down to the same thing. They're afraid of looking dumb. Afraid of asking such a silly question. Hey, did you ever make a mistake? Like, how silly would you feel asking that to someone? Not at all. Okay, never mind. Please remove that from the video. Thank you. Thank God for modern video editing. Either way, they're afraid of asking a question that makes them look silly or dumb. And they don't want to look like Amelia Vadilla. But it's okay. It's okay to ask these dumb questions. And it's okay to ask someone if they've ever made any mistakes, because advanced developers make a lot of mistakes. And we don't tell beginner developers this, right? If they wanted to know, they'd ask. Right? How many times have you ever said, hey, if you have any questions, just ask me. Right, so you put it out there. You've done your part. They have no good reason to be afraid to ask, except for they're new and they want to impress you. And from where they're sitting, it looks like you're holding all the cards. We don't tell them because we don't think about it. We forgot what it's like to be afraid to ask dumb questions. And so a lot of times we assume that other people aren't afraid either. I think this is one of the biggest mistakes advanced developers can make. And it's okay. It's okay that we make that mistake. But what I think that what we should do instead is try to remember the mistakes that we made when we were first learning. And I'm grouping myself with advanced developers now. I don't know how that happened. But you guys, you advanced developers. Just everyone should do it. Everyone does it now. We're all advanced developers. Congratulations, welcome. We should remember the mistakes that we made when we were first learning. Sharing these slip-ups with the junior developers that you work with or the junior developers in your community. One, it humanizes you to them. When the person I was working with made that mistake, I was like, oh my gosh, they're a person. Two, and not a highly sophisticated robot. Because there was some concern. This person seemed infallible up to this point. And I just felt better. I was like, okay. So even if I do get really good at this, I could still make mistakes. This is okay. And then it also just humanizes the process of learning to code. When we think about it as you're going to make mistakes. And not when you make a mistake, but you will make a mistake, that's okay. When you're learning the mistakes you're making are common. You feel like you're heading down the right path. It still feels not awesome to make a mistake. But you're like, well, at least a lot of other people were thinking that way too. Making mistakes means that you're learning. It means that at some point you look back on what you did and realize that it's wrong. That's learning. I think that a lot of us say that we want to create safe spaces for people to learn in. And I think that a place that's safe to make mistakes in is that is the environment that's safe to learn in. We want people to learn the hard way, but we don't facilitate that. I was going to say we don't make it easy for them to learn the hard way. If you really want people to learn the hard way, make it easy for them to talk about their mistakes. So talk about your own mistakes. Go to where you work. Tell your boss that you have to do this, because it's the law, and tell them you just want to talk about mistakes. Maybe just have a, hey, everybody does this. Everybody always, whenever you work on whatever app first, everybody makes that mistake. Don't worry about it. Just talk about your mistakes and create the safe place to learn that you say that you want. Illustrations for this talk created by San Smith, who works with me, and she is an excellent co-worker and illustrator, and that is her website, if you want to go to it. Should have ended on a higher note, huh? My name is Kylie Ferris-Stradley, so you can find me at K-Y-F-A-S-T, basically everywhere. Well, probably everywhere. Probably. And like I said, because I've been really, really lucky that when I first started learning Ruby, I felt really comfortable making mistakes. I started going to Rails Girls Atlanta when I first started writing Ruby, and everyone was working on an extension of the Rails Girls workshop application, and they were going up, complete beginners, at each meetup, and talking about the application that they built and the mistakes that they made. So when my database schema looked exactly like it should, according to the tutorial I was following, but I couldn't get the Rails server to start, I felt comfortable going up to the front of the room and saying, hey, I don't know what I did, but it's clearly wrong. So it turns out, you can't or you can't edit the database schema. Should you? It seems like no. This is what my sources are telling me. And then when I started working at Big Nerd Ranch, I was exposed to a ton of people who were extremely smart, who were extremely comfortable talking about their mistakes. And even though the environment was really great, when I first started, I was still really scared to talk about my mistakes, because I thought they would find me out, and they would find out that I was in the Ohia and they would have read the books and they would be like, we got to get her out of here. But even in that super welcoming environment, it took me some time to warm up to talking about my mistakes. Once I started talking about my mistakes, though, I started learning so much faster. And I think that if we really want to facilitate learning, what we need to facilitate is making mistakes. So clap now. Yeah, just like that. That's it.