 everyone hear me well, just before I get too far in. Okay, perfect. This talk is called Emilia Vidoya, Learned to Code. My name is Kylie Stradley, and like Floor mentioned, I'm a developer. I live in Atlanta, Georgia in the United States, so not the country, Georgia, but that would probably be cool. I love making and eating pizza so much that this is my work photo. Like, if you go to my company's website, that's my photo. This is my Twitter handle if for any reason you want to reach me or tweet at me. I am very excited to be here because this conference comes very highly recommended. I have had such a good time here so far, and every single talk that I've been to has been just such an overwhelmingly enjoyable, positive experience, so that's been really great. I'm not here to tell you about me, though, and how much I love Yerukamp. I am here to tell you about a character from my childhood. Her name is Emilia Vidoya, and she is a children's storybook character. But before I get too far ahead of myself, could I get a show of hands? Is anyone here currently or at any time in the past ever been a child? Okay. Some of you are laughing, but not everyone raised their hand. So I just wanted to gauge that number in the spirit of inclusiveness to find out what the demographic is here today. So, yeah, like I said, let's meet Emilia Vidoya. In America, this character, Emilia Vidoya, is used to teach young grade school age children about idioms and figures of speech. And the children really identify with the mistakes and mix ups that Emilia makes, because like a child, she doesn't realize until she's told that the phrases have more meaning than some of their parts, she takes them literally. And so I might say idiom a lot, so let's just be sure we're on the same page. And idiom is a phrase whose meaning is more than the sum of its parts. For instance, America, someone might say take a hike. And that does not literally mean the sum of those words, like do not take a hike, although you're more than welcome to. The whole phrase is more akin to something like go away or get out than it is to literally take a hike. And we have a lot of phrases in programming that just summing their parts seems to mean one thing. But really, it actually means a very different thing that you might not guess if you don't have all the context. Emilia, like a new programmer, is very eager to please. So when she isn't sure what a phrase called a date cake is, she does the best job that she can with information that she has. I guess she can't find the fruit dates, which are a bit like raisins I think. And maybe she doesn't even know what the fruit dates are. So instead, she cuts up a calendar and takes those dates instead and mixes them into the cake batter. And I assume that at the time of writing of this book, that would be an acceptable cake substitute, because all of the people in the book are smiling while they're eating the cake. I don't claim to be an expert on that, but it does seem like she does her best and she saves the day. Did this sound familiar to anyone? I think so. Someone is using a language that they're new to. They don't understand all of the phrases that they hear, but some of them sound very familiar. Unfortunately, those phrases have completely different meanings than the meanings that they know. Emilia is eager to do a good job, and she is a hard worker and tries really, really hard, even though she doesn't understand all the phrases in the language she's using. That is why I think Emilia Bedoya is a great lens to examine the kind of mistakes that beginner developers make. And so this is why I'm here today. And I know that the after-lunch spot is not usually a popular one with speakers, but I am very glad Ucamp has given me the after-lunch spot, because I think that the best way to talk to you about this, about learning idioms and phrases and the kind of mistakes that they cause for beginner developers, is to read you a book about it, like you might at a summer, or a library summer camp. So if you don't mind, I'm going to sit here and I'm going to read to you. You haven't heard it yet, so it might not be. You may want to take that back. I'll allow you if you choose to. The name of the book is Emilia Bedoya Learns to Code, written by Kylie Stratley, illustrated by Sam Smith, and inspired by the works of Peggy and Herman Parrish. Emilia Bedoya is speaking with her employers, the Rogers family. It's time for an 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. Now that sounds like fun. Hey, where are you going? Don't you want to know what your raise will be? Shout to Mr. Rogers. Emilia doesn't hear him. All she can think about is how much fun it will be to talk to computers. Emilia reads that to talk to a computer, you have to speak their language. But it looks like there are quite a few languages that you can use to talk to them. Emilia's new friends, some Rails girls, mentioned she might enjoy language called Ruby. Emilia thinks that sounds nice enough, but why Ruby specifically? Why Ruby? Why not Ruby? Shout to strange foxes who have mysteriously appeared. Ruby has elegant syntax. It's natural to read and easy to write. If you like Ruby, you'll love Ruby on Rails. It's a web framework 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 to develop a 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, says Emilia to no one in particular, as the strange foxes have already disappeared in the same mysterious way they arrived. I'm really glad that Jason mentioned why earlier. These are wise foxes from wise poignant guide to Ruby, which if you like weird Ruby stuff, you should read. 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. I forgot to mention this. Sometimes when you do group readings, there's maybe like an audience participation part, and so there's an audience participation part coming up and I think it's not going to be a problem. So we'll just try it. So maybe this would be a good time for you to jump in, all of you. Yes? That's exactly it, yes. Perfect. The next one will go much smoother. She edits the schema, of course. Now she has another table in her database without involving those strange randomly numbered migrations. Oh, no, Emilia. 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, but in Rails, the schema is just a representation of the database 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. 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 I'll remember to 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 this application needs, but she knows that she can cover most things using the Rails generator to scaffold new models, views, and controllers quickly. She uses a 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 by hand myself. In fact, it's even easier. Plus, now I already have the controllers and views pre-made in case I need them later. I can just delete them then if I decide I won't need them. Emilia, do we really need all of this? asks 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 generator model, view, or controller. You can even just create new files without even using the generator, and Rails convention over configuration design will make sure that 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 have to load all of the assets created by the scaffold. Plus, do we need all these JavaScript files? 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. And this is what happens when you use the scaffold. She just needs, from her blueprint, a very small dog house. But she used the scaffold so she got this dog mansion instead. Okay. So I don't need to use the Rails generator to make everything. I can just create the files myself. Emilia remembers what the fox has told her. That Rails is designed with convention over configuration. I want to write the best code that I can. I'll follow the frameworks convention and write good code the Rails way. And each of her new files, oops. 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. If you don't know DHH, the framework designer also races formula one cars. And I have to assume that this is how he reviews pull requests to the Rails project. Oh no, Emilia explains the computer. Convention over configuration doesn't mean you have to use Rails only within the framework's conventions. It just means that you don't have to configure the connections between conventionally named models, controllers and views. When you include all that code, you can accidentally include different features. For instance, leaving the two respond with blocks in the controller allow you to inadvertently expose a JSON endpoint for that controller. Ah, so that's what that means, Emilia. I definitely don't want to expose an 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, not just hold onto them for later. You got it, Emilia. Emilia is having a lot of fun at her first hackathon. The team she's working with is requesting a ton of features, and many of them directed to all different routes. Emilia's teammates are excited but getting antsy for the new web views for their app. She activates each of the routes by raking them before committing and pushing the code. With each new route she writes, a new HTML file adds the route to the RouterB file, 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 and forget to rake my routes expecting them to be there anyways. 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. 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 runs 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. Okay, I think I'm getting it a little bit now. Rake is a tool and it can run a lot of different tasks. Unlike the schema, routes aren't generated. I write them myself so they exist as soon as I write them, explains Emilia. You're really starting to get this stuff. Emilia is writing an application with her out-of-town friends, Fred and Cary. Fred and Cary have been developers for a while and always hit the latest trends in RubyGems. Fred and Cary say, Gems are great. They're just libraries of code. Why write it yourself when you can just put a gem on it? You can find a gem for anything. It's like you never have to write code yourself. Emilia thinks these gems are pretty handy. It seems like I can just drop them wherever and have access to a ton of code written by another person. Emilia adds all of her favorite gems to each new project she starts. I'll save myself some time and some code. Cary and Fred say, put a gem on it. You know what this app is missing? Gems, let's spruce it up. Make it pretty with the draper gem. What a side little application. I know. I'll put the Rails admin gem on it. Did you see this app before? I didn't. Not so fast, says Emilia's computer. Gems can be very useful, but they're not the answer to every problem. Every gem you add to the gem file might have dependencies on other gems, and those might have dependencies on other gems, and those might have even more dependencies too. All of those dependencies can cause complications and eventually made 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 upgrade and use turbo links, cried Emilia. I guess I should make sure the gems 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 to the params hash. They'll be so excited. This is a bit cultural, but I had already printed the book, so it stayed. But a hash is like a potato salad kind of in America, so she's adding them to this params hash, which is potatoes and database columns. Whoops, says Emilia's computer. A client can say parameters, which seems like a general term, but that word has more meaning in a Rails project. Turns out what the client really needs is just a new table column to save records to. Well, at least my workplace has code abuse, and 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 the client request in the future when they seem off to you, and you were able to teach a semi-technical client a little bit about Rails architecture in the process. Yeah, I guess you're right. Nothing bad happened, and I learned something. I suppose I am getting the hang of this. Emilia is serving as a coach for the first time at a 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 space project. They want to use a time field for this, but everything falls apart when they try to schedule dates very, very, very far in the future. Emilia has worked with future dates before and made the same mistake before, too. She heads right over and explains, hey, I've had that problem, 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 very good joke. Back to the beginning. So if you're at the beginning, that one is funny. 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 have worked with access, 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. So that's a pretty nice story, right? And we tied up all the loose ends, and it's over, and Amelia is now a professional developer. And I think it's really easy to frame our struggles this way, as you worked really hard on something, and it was difficult. And now you're done working hard on it because you're there, you've got whatever it was you're striving for. And that's not realistic, and I think it's not great that we tell that kind of story to people who are brand new to programming. So it's not this, you know, it ends with a day new model, and then it's done. It's more like this. You never really stop making mistakes. And this is a cute fun talk, but I wrote it because I want everyone to talk about how you keep making mistakes. You never stop. I certainly haven't stopped making mistakes. Very recently, not very recently, somewhat recently, I made a pretty big mistake. I thought I was working with a colleague at work, and we thought that we found a bug in the Ruby programming language, and we thought that we were smarter than the core contributors of Ruby, and that we had found this amazing bug, and we told everyone on our development team, everyone else on the Ruby team, about the bug that we found. And we were just very in the weeds writing a test, and we were trying to force equality on two separate instances of time.now. And obviously this was returning false because they are instantiated at different times, but all we could see was time.now equal equal time.now was returning false, and it looks exactly the same. And obviously when we told our teammates they were like, well yes, of course, because that's how that class works. And we made a huge mistake and embarrassed ourselves in front of a lot of people acting, thinking that we had found this bug in Ruby. But that's the thing, though, is no one gave us a hard time about it, because it's fine. These things happen. They happen to everyone. They happen to senior developers that you look up to, too. But what people don't think about is that beginners make a lot of mistakes, and when you are a beginner it seems like you're the only one making all these mistakes. Maybe in the book some of the mistakes that I mentioned you did make. I gathered all those mistakes from my own experiences and working with Rails Girls in Atlanta, and these are common mistakes for beginners, but when you're more senior maybe you forget. And beginner developers, you know, whenever you have beginner developers on your team you say, you know, if you have any questions just ask me. And maybe you would say like, oh, you know, if they wanted to know if I made any mistakes they would have asked me about it. But we don't, beginner developers don't ask advanced developers if they've made any mistakes. And I think that that's okay. That beginner developers don't ask. Because advanced developers make a lot of mistakes. And to beginners they don't look like mistakes because you're typing so fast that no one catches your mistake or they're just not thinking at the same level yet so that they don't see the mistake. And that's okay, too, that advanced developers make mistakes. And that's okay because making mistakes means that you're learning. And you're realizing the things that you did before don't always work still. But what's really important is that we share mistakes. Beginner developers again think that they're the only ones making these mistakes. But if more advanced developers share with them and let them know, hey, you never really stop making mistakes. Becoming a senior developer, working in programming for a long time suddenly seems a lot more attainable. Everyone talks about they want to have a great engineering culture and they want their company to be awesome. And you want to hire minorities and diverse candidates. But I encourage you to put your money where your mouth is and talk about your mistakes. Because like truly a great company culture like somewhere that people can learn is a place that's safe to make mistakes. So make it safe to make mistakes where you work and you're going to make the place where you work safe for people to learn. And that is the end of the talk.