Amelia Bedelia Learns to Code
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 29 | |
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/30639 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 201529 / 94
1
4
7
8
9
10
11
13
14
16
17
19
21
24
25
29
30
33
34
35
36
37
39
40
42
47
48
49
50
51
53
54
55
58
59
61
62
64
65
66
67
68
70
71
77
79
81
82
85
86
88
92
94
00:00
DeterminantInterpreter (computing)TrailExpected valuePoint (geometry)Connected spaceFamilyFigurate numberMultiplication signMaizeOnline helpComputer scienceWebsiteSpeech synthesisResultantGoodness of fitComplete metric spaceWikiState of matterEvent horizonTerm (mathematics)Electronic mailing listLevel (video gaming)SoftwareBootingComputer animation
05:18
Goodness of fitReading (process)Computer animation
05:47
Human migrationRepresentation (politics)Computer fileRuby on RailsNumerical analysisFormal languageBinary codeRoboticsSoftware frameworkRoutingWeb 2.0Image resolutionTable (information)Pattern languageWeb pageNeuroinformatikMultilaterationAuthorizationCartesian coordinate systemGame controller1 (number)FamilyBlock (periodic table)Dependent and independent variablesState of matterSlide ruleBitDatabaseMathematicsCodeConnected spaceConfiguration spaceMultiplication signPerfect groupView (database)Mobile appGoodness of fitWritingMereologyCoefficient of determinationCASE <Informatik>Endliche ModelltheorieElectronic program guideAnalytic continuationProjective planeRight angleVideoconferencingOnline helpScripting languageCuboidAreaDivisorFigurate numberPoint (geometry)Mathematical optimizationNatural numberGroup actionBit rateReading (process)Arithmetic meanInstance (computer science)WordRoundness (object)Position operatorDifferent (Kate Ryan album)Independence (probability theory)SimulationInclusion mapLink (knot theory)Computer animation
15:27
Projective planeWordCartesian coordinate systemComputer fileSoftware developerGroup actionMereologyDatabaseBit rateMultiplication signProcess (computing)Series (mathematics)Term (mathematics)NeuroinformatikParameter (computer programming)Scheduling (computing)Computer architectureAreaHash functionRoundness (object)CodeClient (computing)Task (computing)TheoryRouter (computing)Library (computing)RoutingAddress spaceRow (database)Twitter1 (number)Table (information)Design by contractCASE <Informatik>Human migrationAnalogyVideo gameArithmetic meanScripting languageState of matterFormal languageModal logicSurjective functionDifferent (Kate Ryan album)Lattice (order)Electric generatorMobile appField (computer science)Uniform resource locatorBitMeta elementMUDSoftware bugComputer animation
25:07
VideoconferencingMultiplication signGodFront and back endsInheritance (object-oriented programming)Integrated development environmentWaveInterior (topology)SineState of matterFormal grammarCondensationBasis <Mathematik>Cartesian coordinate systemExtension (kinesiology)Focus (optics)Standard deviationOnline chatPhysical lawMereologyBoss CorporationSpacetimeExterior algebraArithmetic meanPoint (geometry)Process (computing)RoboticsEvent horizonDatabasePlastikkarteGoodness of fitWebsiteEquivalence relationMobile appBoiling pointSource codeSign (mathematics)Server (computing)Equaliser (mathematics)Forcing (mathematics)Ultraviolet photoelectron spectroscopyComputer animation
34:47
Computer animation
Transcript: English(auto-generated)
00:12
So, yeah, this talk is Amelia Bedelia Learns to Code. I am Kylie Stradley. I just want to welcome you guys to Atlanta.
00:22
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 complete lack of respect for societal expectations and how to not be a weirdo.
00:46
So I want 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 with any current
01:07
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 Amelia Bedelia.
01:21
And I liked Amelia Bedelia 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 Amelia Bedelia story, Amelia Bedelia, she's working as a maid,
01:40
and she gets these to-do lists. And on one of the lists, it just says, prepare a chicken dinner. And Amelia'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? Amelia surmises that a chicken dinner is a dinner for chickens.
02:03
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? Amelia's employer is the Rogers family. In the book, she is consistently just causing them to be super exasperated
02:22
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 Amelia because it seems to indicate they'd
02:43
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?
03:02
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 delivered to them, only to be informed that this is not the desired result.
03:21
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 just, I feel like I have a really strong connection to you now, best friends. So as an adult now, you can see how I'm starting to think of Amelia less
03:45
as just like kind of a silly character and more of maybe kind of an archetype of a developer, the literal interpretations, the silly mistakes, the not asking for help.
04:00
Yeah, and then at the end of the stories, Amelia always saves the day. And she usually does this by preparing one of her awesome desserts, usually a baked good. In this story, Merry Christmas, Amelia Bedelia, she saves the day with a date cake. But because it's Amelia Bedelia, when she can't find the fruit dates, she cuts up a calendar and uses those dates instead.
04:22
But everyone, yeah. In the last picture of the book, though, everyone's like 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 Amelia Bedelia scholar.
04:40
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.
05:02
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, OK, I'll level with you.
05:22
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? OK.
05:44
Let me get my book. The name of the book is Amelia Bedelia Learns to Code, written by Kylie Stradley, very good prolific author. Look that person up.
06:03
Illustrated by Sam Smith and inspired by the works of Peggy and Herman Parrish. Amelia Bedelia is speaking with her employers, the Rogers family. It's time for our annual review. Mr. Rogers says, Amelia, you've always done good work once we managed
06:23
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, Amelia thinks to herself, now that sounds like fun.
06:44
If you don't have binary memorized still, I know everyone obviously has it memorized, but if someone didn't, she's saying hi in binary. Amelia 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.
07:04
Amelia's new friends, some Rails girls, mentioned she might enjoy a language called Ruby. Amelia thinks that sounds nice enough, but why Ruby specifically? Why Ruby? Why not Ruby?
07:23
I bet you guys would like that. Shout to 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.
07:41
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.
08:02
Ruby it is, Amelia 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
08:20
Why's Eloquent Guide to Ruby, you should check it out. You might hate it, but that's what that joke is from. Sorry. I didn't want to make an inside joke. I thought it was rude. This Ruby on Rails stuff is easy, Amelia thinks. It's got HTML and CSS. I know how to use those. There's a database. I've worked with databases before too.
08:43
Amelia's 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. So I'll do it first and you guys can join in
09:02
and then on the next ones you'll get it because there's a pattern. So what does Amelia do? You guys could say that. Yeah. So what does Amelia do? Oh my gosh, I knew you'd get it. She edits the schema, of course.
09:22
Now she has another table in her database without involving those strange, randomly numbered migrations. I can't read this at all, exclaims Amelia's computer. In some languages or frameworks, you can edit the database schema directly
09:40
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. Amelia nods and her computer continues. Since we've only built a really basic database, it seems like the migrations represent individual tables,
10:02
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
10:21
when I want to update the database, and I'll remember to run them using Rake so that they'll update my schema file. Amelia 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
10:42
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.
11:01
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,
11:20
she's building this dog mansion instead. Do we really need all of this? Asks Amelia's computer. The Rails scaffold is handy, but you don't have to use it to create everything. You can just use the generator
11:41
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 Amelia. Easier for you, maybe, replies Amelia's computer. I still have to load all of the assets created by the scaffold.
12:01
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
12:20
the Rails generator to make everything. I can just create the files myself, Amelia says. She remembers what the foxes told her, that Rails design with convention over configuration. Still not sure what that means, but I wanna write the best code that I can. I'll follow the framework's convention and write good code the Rails way.
12:59
In each of her new files,
13:01
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. Perfect.
13:21
Oh no, Amelia, exclaims Amelia'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.
13:40
When you include all that code, you can accidentally include different features. For instance, leaving the two respond with blocks in the controller could allow you to inadvertently expose a JSON endpoint for that controller. Oh, so that's what that means, says Amelia. I definitely don't want to expose a JSON API in this application. Just because I can do something with Rails
14:02
doesn't mean that I should. I should only include those things when I need them and not just hold onto them for later. You got it, Amelia. Amelia'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.
14:23
Amelia's teammates are excited, but getting antsy for the new web views for their app. I need to make a lot of routes, Amelia says. She activates each of the routes by raking them before committing and pushing her code.
14:41
With each new route, she writes a new HTML file, adds the route to the route rb, and rakes the route. Rake is shorthand for Ruby make. 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.
15:03
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 you're welcome
15:21
for this good slide and that fact. Oh no, Amelia, 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 Amelia. I have to rake the migrations. It makes sense that I need to rake the routes too, right?
15:41
Amelia'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 route rb. 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 Amelia.
16:03
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.
16:21
You're really starting to get it, Amelia. Amelia is writing an application with her two 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, gems are great, they're just libraries of code.
16:42
Why write it yourself when you can put a gem on it? You can find a gem for everything. It's like you never have to write your own code. Amelia thinks, what, did you guys do that? That's so bad. I can't believe you guys would do that.
17:01
Amelia thinks, these gems are pretty handy. Seems like I can just drop them wherever and have access to a ton of code written by someone else. Amelia adds all of her favorite gems to each new project she starts.
17:23
I'll save myself some time and some code. Fred says, you know what this app is missing? Gems, let's spruce it up, make it pretty with the Draper gem. Carrie says, what a sad little application. I know, I'll put the Rails admin gem on it.
17:44
That's the whole joke, just kidding. I'm sorry, that's a great gem, whoever did it, you did a good job. Did you see this app before? I didn't, right? I thought so too, thanks.
18:04
Not so fast, says Amelia's computer. Gems can be very useful, but they're not the answer to every problem. Every gem that you add to the gem file might have dependencies on other gems, and those might have even more dependencies on other gems too. All of those dependencies can cause complications
18:22
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 wanna try out Turbolinks 3. Cried Amelia, I guess I should make sure
18:41
the gems I'm including are the ones I'll really need. Amelia 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, Amelia thinks.
19:00
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.
19:21
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.
19:42
I'm glad my friends came to this. I get the feeling that some of you don't find this as amusing. Whoops, says Amelia's computer. A client can say parameters, which seems like a general term, but that word has more meaning in a Rails application.
20:03
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 Amelia. Hey, don't be so hard on yourself, Amelia, says her computer. This is a great opportunity for you to push back
20:21
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. Amelia's coaching at her very first Rails workshop.
20:43
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.
21:02
Amelia'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,
21:21
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
21:42
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.
22:02
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.
22:33
That was pretty cute, right? Yeah. But that's not really how it is, though.
22:42
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 like 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.
23:01
And Amelia always has 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 lows, again, where she edits the database schema.
23:22
And I mean, 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 denouement.
23:42
Ideally, our stories don't end for a long time, because, I don't know, that might mean that you're dead or something, or you leave software. 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.
24:03
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 2012, maybe, maybe some other places, about wets.
24:23
This is how you say it. 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 a strange, unexpected bug in a language. And so Gary found a bunch of these in Ruby and Python, maybe, and definitely in JavaScript,
24:45
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,
25:02
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.
25:21
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. We're the Gary Bernhard's of our time, like. Like, even though he is alive
25:43
and is the Gary Bernhard of our time, like, yeah. We were like, we're Ruby heroes. And so we go into the company chat room of the backend team, and we tell our teammates, we're like, you guys, can't explain this.
26:01
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
26:20
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 not just it happened recently to me and like, I know about time and stuff, but like, this happened to like a senior developer
26:41
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.
27:01
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 really respect. They probably happen to you, probably, DHH isn't in here, so they probably happen to you guys, not DHH, so that was a good joke, whatever, fine.
27:20
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,
27:41
but 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 ameliora-pedialisms because unlike senior developers,
28:01
they don't know about that like sign 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,
28:21
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, nevermind. Please remove that from the video. Thank you.
28:46
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 Bedoya. But it's okay. It's okay to ask these dumb questions.
29:01
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? Right? How many times have you ever said, hey, if you have any questions, just ask me? Right, so you put it out there.
29:21
You've done your part. Yeah. 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.
29:42
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
30:01
when we were first learning. And I'm like grooving 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
30:22
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, too, and not a highly sophisticated robot
30:41
because there was some concern. This person seemed infallible up till 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
31:00
and not when you make a mistake, but you will make a mistake, that's okay. When you're learning and you finally recognize that the mistakes you're making are common, you feel like you're heading down the right path. 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.
31:23
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
31:45
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 gonna 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.
32:03
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,
32:20
everybody makes that mistake. Don't worry about it. Yeah, just talk about your mistakes and create the safe place to learn that you say that you want. Illustrations for this talk were created by San Smith, who works with me, and she is an excellent coworker and illustrator, and that is her website if you want to go to it.
32:41
I should have ended on a higher note, huh? My name is Kylie Farris Stradley, so you can find me at K-Y-F-A-S-T, basically everywhere. Well, probably everywhere. Probably. And like I said, I wrote this talk
33:01
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,
33:20
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,
33:41
but it's clearly wrong. So it turns out you can 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
34:00
who were extremely smart, who were extremely comfortable with 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 Amelia Bedelia, and they would have read the books, and they would be like, we gotta get her out of here.
34:21
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 wanna facilitate learning, what we need to facilitate is making mistakes. So clap now.
34:42
Yeah, just like that.