00:00:11.230
Welcome to my talk, "Amelia Bedelia Learns to Code." I'm Kylie Stradley. I live in this awesome city, Lima, which is a fact I'm very proud of. This is my first time speaking at a tech conference, and if you couldn't tell by my complete lack of expectations and how to not be a weirdo, I’m a bit nervous.
00:00:46.579
I want to tell you about a character who was really important and special to me as a child. Can I get a quick show of hands? Who here was ever a child? Yeah, I see a couple of hands! The special character from my childhood is Amelia Bedelia. I liked her because I really identified with her; she is notoriously literal and practical to a fault. In many of her stories, she works as a maid. In the titular story, she is given a to-do list that simply says 'prepare a chicken dinner.' Amelia has never heard that phrase before, so she tries to figure out what it means.
00:01:19.520
Amelia interprets 'chicken dinner' as a dinner for chickens. So, she serves up cracked corn, which we all know chickens love. But, of course, her employers, the Rogers family, are left flabbergasted and exasperated by her literal interpretations. In another story, she has a task to 'dust the furniture.' To her, the request seems strange, as it seems to indicate they want dust applied to the furniture. Despite her better judgment, she follows the instructions. Does this sound familiar to anyone? Sometimes, requests in software development are worded in a way that leads to confusion, and you think surely this isn't what they mean.
00:02:06.530
This can happen to a lot of us in software development, and I connect with Amelia because even as an adult, I am beginning to see her as more than just a silly character. She embodies the archetype of a developer who makes literal interpretations and commonly repeated mistakes without asking for help. However, at the end of her stories, Amelia always saves the day, often by preparing some fantastic dessert. For instance, in "Merry Christmas, Amelia Bedelia," she saves the day with a date cake, but in typical Amelia fashion, she can't find any dates, so she cuts up a calendar instead!
00:03:06.830
This serves to show that everything turns out fine in the end, even though the method may not make sense. As developers, we often recount our stories in a way that emphasizes redemption, especially those of us who are self-taught or come from non-traditional backgrounds. We focus on our mistakes but then ultimately share how we overcame those mistakes as part of a good story. However, while those narratives are satisfying, they don’t always reflect the continuous cycle of learning and making mistakes in development.
00:04:06.600
Now, I'll be honest with you. This is my first conference talk, and I'm extremely nervous. Instead of conducting this talk, let me read you a really good story instead. The title of the book is "Amelia Bedelia Learns to Code," written by Kylie Stradley and illustrated by Sam Smith, inspired by the works of Peggy and Herman Parish. In this story, Amelia is having her annual review with the Rogers family. Mr. Rogers praises her good work but mentions that her literal interpretations can drive him insane.
00:05:20.180
He compares communicating with her to talking to a robot and thinks it would be fun if someone didn't have binary memorized. Amelia understands that to talk to a computer, you have to speak its language. Thankfully, she learns that there are many programming languages, including Ruby, which she finds appealing. Ruby is favored for its elegant syntax, stating that if she enjoys Ruby, she'll also love Ruby on Rails, which is a web framework aimed at developer happiness.
00:06:30.250
Amelia decides that she wants to become a developer because she wants to communicate with computers, and Ruby seems like the right choice for her. She finds out that Ruby on Rails incorporates HTML and CSS, which she already knows, along with databases she has worked with before. Working on a beginner Rails project, she notices that she needs to add a table to her database. She thinks the schema file will allow her to do this.
00:07:40.540
She mistakenly edits the schema directly, believing this is how to make changes in Ruby on Rails. However, her computer then explains that in Rails, the database schema is not actually where you make changes to the database; it’s a representation of the current state. The process involves migrations, which are randomly numbered based on when they are created, and Amelia struggles to understand this until her computer clarifies how these numbers indicate when changes were made.
00:09:40.490
After realizing her mistake, Amelia vows to write migrations for any future updates to the database, rather than directly editing the schema. Full of confidence, she moves forward to create a new application, still operating under the ethos of using Rails scaffolds to generate the models, views, and controllers she thought she would need.
00:11:55.150
However, she makes another mistake. Instead of recognizing that she doesn’t require a complete scaffold for a simple model, she ends up constructing a large dog mansion based on a blueprint for a doghouse.
00:12:03.890
Later in this process, her computer reminds her that while scaffolding can simplify things, she doesn't need it to make every file and that Rails follows the principle of 'convention over configuration.' This means she can create models and controllers without relying too heavily on the scaffold. Amelia realizes that using Rails correctly will help streamline her process.
00:13:05.730
As she writes her new files, she mirrors the style and code produced by the scaffold. However, her computer reminds her that convention over configuration allows flexibility; just because a feature is there doesn’t mean she should use it, especially when she doesn't need it. For instance, including certain responses in her controller might unintentionally expose a JSON endpoint, which isn't appropriate.
00:14:53.470
Amelia proceeds to enjoy her first Hackathon, trying to manage numerous feature requests from her excited teammates. As they focus on implementing various routes for their web application, she mistakenly believes she needs to 'rake' her routes like she did for migrations. Her computer clarifies that while rake is a useful tool, it is not necessary to activate routes; they are activated simply by adding them to `routes.rb`.
00:15:44.810
This realization encourages Amelia, who understands that she has incorrectly spent time raking her routes when she could have been committed to the implementation. Realizing the routes are already present once she writes them, she is eager to inform her teammates about the improvements.
00:16:38.340
Amelia collaborates with her friends Fred and Carrie on a project, where they discuss using gems to enhance their functionalities. Expecting them to be solutions for every problem, Amelia learns from Fred and Carrie that while gems are convenient, they also come with dependencies which may complicate upgrades. This prompts her to reconsider her approach to including them in her projects.
00:17:36.220
As she works at a software development company as a junior intern, Amelia faces a client request to add new parameters for customer addresses. Confident in her understanding of params in Rails, she goes ahead and wrongly adds them directly to the params hash, thinking she understood the requirements. Thankfully, during a code review, this mistake is caught, and Amelia learns the importance of clarifying client needs.
00:19:08.600
Although it was a silly error, she knows that sometimes even senior developers forget details. This moment provides an opportunity to teach her clients about Rails architecture while building her confidence. Despite feeling frustrated at times, she recognizes that making mistakes is a critical part of her learning process.
00:20:00.500
At her first Rails workshop, she feels empowered to help others with their errors when a group struggles over scheduling future dates. They learn how to avoid the pitfalls she encountered. Amelia uses this moment to remind them that using the right date/time formats can help avoid confusion, as she still addresses her own daily mistakes.
00:21:23.969
She recognizes that learning from her mistakes can also help others learn. Sharing her own experiences fosters a collaborative environment where others feel safe to discuss their errors, ultimately deepening everyone's understanding of software development.
00:22:20.310
Before I wrap up, I want to mention how we often narrate our developer journeys as redemption stories with a neat conclusion. However, learning to code is an ongoing cycle of highs and lows. It’s critical for beginners to understand that every day involves mistakes and learning. The learning path doesn’t have a defined endpoint.
00:23:28.310
Many beginner developers hold a false belief that they're alone in their struggles, but often even seniors make similar mistakes. They feel overwhelmed and may avoid asking questions for fear of looking foolish. It's essential for us to share our own mistakes to demystify the process of learning and to show that it's okay to make errors.
00:24:52.310
By sharing our slip-ups, we create a supportive environment for others, helping to humanize the learning experience. It’s vital that we remind ourselves of how we felt when we were first learning. We all feel insecure at times, and by fostering an open communication channel about mistakes, we can ease that tension.
00:26:51.310
This talk aims to encourage sharing mistakes and asking questions among developers. Mistakes are part of the learning process, and by creating safe spaces for discussion, we empower one another to grow and develop.
00:28:36.310
I want to thank Sam Smith for her incredible illustrations in this talk. Remember, creating an environment where mistakes can be discussed openly is crucial in our industry. Thank you for joining me during this talk, "Amelia Bedelia Learns to Code." My name is Kylie Stradley, and feel free to find me online!
