 How's everybody doing? Awesome. Okay, round of applause if you're having an amazing morning. Round of applause if you're having like an okay morning. It's not great, it's not bad, it's somewhere in the middle. Just you, okay, that's fine. Round of applause if you're just having a crappy day. Clap for crap, anybody? One, oh, I'm sorry, it's okay. We're gonna make it better, we're gonna have a great time. So I'm super excited to be here. This is my first time in Austin, first time in Texas. Yeah, it's great. When we can clap for that, that works. So when I told people that I was keynoting Lone Star RubyConf in Austin, they just started yelling food names at me. And they were like, oh my God, tacos, burritos, barbecue. So I have very high expectations for the cuisine here. I'll let you know how it goes. I'll report back on Twitter, so follow up on that. So today I'm gonna tell you some stories. I'm gonna tell you a little bit about myself. So let's start at the beginning-ish. Two years ago, that's the beginning of my coding journey anyway. So two years ago, I was this chick. I worked at startups. Isn't that fun working at startups? Anybody work at startups, Chef Hans? We're in Austin, so I feel like that's kind of the rule. So yeah, I worked at startups. I did the things that were not technical. So I've done sales, business development, marketing, lots of schmoozing. And I felt like it was fun and it was great, but I felt like I was always looking over the shoulder of developers and the product people, the people who actually made stuff. And I thought, man, I really wanna do that. Those are the people who have the real power. And I felt very frustrated by how much I could contribute because I wasn't a technical person. And so I decided to learn to code. And when I graduated from a programming bootcamp, I was so excited because I felt like for the first time I had superpowers and I could do things that I couldn't do before and I was really excited about it. And I felt like I had conquered all the code. And then I got my first job. And I realized that there's so much more to learn. There's the stuff that you don't know, the stuff you don't know you don't know, the stuff that you forgot and you don't know you forgot it yet. There's the stuff that keeps changing all the time because this is programming and welcome. And I felt like I was such a novice. I was so aware of how much of a beginner I was. So if you're not familiar, this is the Dreyfus Model of Skill Acquisition and it says that if you are trying to become an expert in a skill, you kinda have to go through these five phases. And I was very aware that I was at that very beginning phase. And I didn't wanna be there. I don't think any of us want to be novices. We wanna be experts. We wanna be people with those badass glasses and those orange capes. And so I went to the mentors and senior developers I knew and I said, how can I become an expert? How do I move along that scale from novice to expert? What do you think they told me? You can talk. Come on, bye. I'll put the time in. All good answers. I don't know if I actually heard the right answer. There's too many people talking. But the answer that I got that was most frequent was to read code. And they said you are gonna build because you're a developer and that's your job but make the time to actually read, dissect and digest code. So I got my group of friends together and I said let's come together and for one hour every Sunday at 11 o'clock we're gonna pick a code base and we're gonna go through it and we're gonna read it together as a team. So the first thing you have to do when you get a group of people together is you have to pick a name. Very important. And so we decided on code club. I know, super creative. And the second thing you have to do is you have to pick something to read. So we went back to our team of senior mentor developer people and we said what should we read? And they said anything. That's not helpful. Someone comes to you and says where do I begin? What do I do? Don't say you can begin anywhere and do anything. That's not helpful. And so we decided that we had to come up with some guidelines. We had to come up with some rules to find good code to read. And so we decided the code base we read should be exemplary. And we defined exemplary as having four qualities. We're very organized. This is awesome how organized we are. So the first thing is it had to be popular. Something that we recognized, something that we knew was endorsed by the community. It had to be well documented. And this one was really important for us as beginners because if we got stuck and we didn't know what something was doing, we had documentation to go to. Third, it had to be well written. This is tricky because as a novice programmer you don't really know what good code looks like and what well written means. We felt like it should be well written, however we defined that. And lastly, it should be well maintained. So something that was up to date and something that was actually being used currently. And we believe that if we follow these guidelines, we would go from novice programmers to badass experts. So we started by looking at Sinatra. Sinatra was the first Ruby framework that we learned in school and we didn't quite understand how the internals worked. And so we thought, let's start with Sinatra's get method. Let's figure out what that is. And we can definitely do that in an hour. So we got on Hangout. This is my favorite thing. I love doing remote meetings and remote everything because I can just be in my boxers and it's fine. And so we got together and we were so excited and we started with that get method and we were reading lines of code and then that line led to a different method and that method led to a different method and all of a sudden we were jumping from file to file to directory and we got along the way. We saw these little things that distracted us and we started going down rabbit holes and we very quickly got overwhelmed. And so we did a retro, I'm a big fan of retros. And so at the end of that first session, we stopped and we said, okay, how was that experience? What do we like about it? What did we learn? And how can we improve? When we meet again next Sunday, what can we do that is different and hopefully better than the way we did it this time? And the first rule that we came up with, the first takeaway was that it needs to be way more manageable. The get method was still a little too much and a little too deep for us at that point. And so we decided to define manageable as being 100 lines of code. Now this is super arbitrary and for us that kind of ended up being the right amount and based on your skill level and experience, you can try out what manageable means to you. And when you pick a manageable code base, what that means is you have way more time. You have the time to ask questions. You have the time to try things. We can comfortably open up IRB without feeling like we were slowing anyone down and try out different things. It was great because we could research topics. If we wanted to pause and do a search on a method or something that we hadn't seen before, then we could do that comfortably. And we realized that the reading code part wasn't the value. The value was the digressions. It was those rabbit holes. Those rabbit holes were where we did a lot of learning and the code was a jumping off point. It was just a way and an excuse for us to have deeper and more meaningful conversations. We also realized that it was a team effort. We had a team of five, which felt like just the right group for us. And with that size, it was really easy to make sure that everyone was engaged and interacting and really excited about what they were learning. And the fourth thing that we learned was that it's really important to have a tour guide. The tour guide is not the expert. They're not the teacher. They're the person that makes sure that everyone else is happy and comfortable and is learning. They're the person that says, Stephanie, it seems like you've been a little quiet. Do you have any questions? Are you stuck? Let's start on line 10 and then go to line 21. It's having that person be almost like the host of the party. So the first few weeks were awesome, but we quickly ran out of exemplary code, especially exemplary code that was manageable. That was 100 lines only. And so out of necessity, we kind of ended up reading bad code or at least code that didn't fit our guidelines. And in doing that, Dan looked at a method and he said, this method sucks. And he asked, how would we write it? And what was really great about that question is that it gave us our first moment to interact with the code. It gave us our first opportunity to say, we're not just gonna read it. We're not just gonna talk about it. We're actually gonna try it out. We're gonna maybe rewrite a couple things from it. And so after that session, we started doing more active interactions. So we started asking questions like, what was the intent? Why was that method written that way? Why, how does it fit into the larger code base and the overall design of it? And we learned that it doesn't have to be exemplary. Bad code is awesome. And it's great because knowing that it's not that good gives you permission to dissect it and to critique it comfortably. If you're reading code that you know is pristine and beautiful, you're gonna hold back a little bit more, especially as a novice programmer. And so reading code that we didn't think was good gave us permission to really engage with it in a whole new way. So we threw out our exemplary guidelines and everything was going great. And then one day Dan says, guys, I don't really think I understand how Rack of Middleware works. And we said, Dan, it's so simple. And we started explaining it to him. And then we realized, none of us knew how it worked either. And what he did was he, and Dan is really valuable in this group, by the way, I'm like realizing this now. And what Dan did was he gave us our first knowledge gap. He gave us these opportunities to say, we're reading the code, we're learning from this, but what are some larger concepts or larger tools that we don't quite understand? And let's see if we can use these weekly sessions to dissect and unpack those knowledge gaps and hopefully fill them. So everything was going great again. And then came the Omnioth Meetup Gem. So this is a gem that I had to use on the job. And the documentation wasn't very good for it. And I had to read it to kind of understand what's going on, I had a bit of a hard time. So I said, can we do this for our code club? Can we bring it in and read it together and get some help on it? And for me, this really changed the game because having a relevant code base that I had to understand to do my job made it so much more personal and made it so much more interesting and engaging for me. And so after that moment, we started trying to find code bases that were much more relevant and that connected with us on a more personal level. So those were our guidelines. Picking a manageable code base, learning, knowing that learning happens in those conversations, understanding that it's a team effort and making sure the whole team is there with you, picking a good tour guide to help you get through that session, interacting with the code and not being afraid to try stuff, knowing that it doesn't have to be good, bad code is awesome, finding and filling those knowledge gaps and finding code bases that are really personal and that you connect with. And then there were a few unexpected benefits. So the first was the organization of the code. When you learn to code, whether it's in school or online or yourself taught, it might be hard to look at how files are named and what the directories look like and what the structure of the code is. And so this gave us an opportunity to read the lines of code but also understand how things were organized. The second thing that I really loved about it is you got to see the collaboration. When I first started coding, I heard all this talk about how awesome open source was and how beautiful it was to have all these people all over the world coming together to build code together. But when you read the code, you get to actually see it. We saw that the devised gem was a fork of the warden gem and we could see how these different players and repos work together and that was really, really fascinating. And the third thing is building your confidence. I realized after many months of doing this that I felt more and more comfortable to not only rely on documentation when I didn't understand something and it gave me the confidence to read just the code itself to understand what the code was doing and that shift was really important especially for a novice. So we did this for a while but then I decided that I wanted to try something new. I didn't want to just read code anymore and I didn't want to do it with people that I knew. So going back to when I first learned to code, it felt like this. I thought it was going to be really awesome and super and exciting but it was really lonely and really frustrating and really hard. I did it for a few months, I quit my job, I was doing all the online tools and reading books that I could and it was just a really lonely and frustrating experience. And then when I got to bootcamp, all of a sudden I had this community of people who were just as excited and just as terrified of this as I was and it made the journey so much easier and what I honestly valued more than just the education was the people. It was the people there who helped me get through it. But that community cost me $11,000 and many months without a salary and this is New York so I feel like if you're in Austin this is like even more crazy money. And I was very lucky and very privileged to be able to afford it but I knew that not everybody could. And I didn't like the idea that if you wanted to have a community, if you wanted to have a support system and you're learning on your own, it's hard to find that. So I started something called Code Newby. Raise your hand if you know what a Twitter chat is. Like a half, that's pretty good. So for those of you who don't know, a Twitter chat is when you pick a hashtag so our hashtag was Code Newby and you pick a specific day and time so we do it every Wednesday night at 9 p.m. for one hour. And what I did was I just started tweeting out questions and I started saying what are you learning about in code this week? What are you excited about? Where are you stuck? What resources do you wanna share? And it was really just an excuse to get people to talk to each other and it was an excuse to connect people who were on the same journey who were trying to get to the same place and to leverage each other as resources. And so we did that for a few months and it ended up growing and developing into something I didn't really intend for it to be but it's awesome and ended up being this incredibly diverse group of people who come from all different walks of life, all different backgrounds and we have dancers and truck drivers and teachers and all kinds of people who were all trying to become programmers. And so we grew from being just the Twitter chat to having a weekly podcast and having a blog and a discussion forum and all these other things but it wasn't enough. I wanted to do something that more directly helped people learn together. So I had this code club thing. Now we have this code newbie thing. So what happens when we bring them together? So what if we didn't just read code? What if we read blog posts and tutorials and we watched videos and we read book chapters and we used all these different resources to become better programmers? And what I learned from interviewing and talking to so many people learning to code is that they like a lot of different formats and so let's leverage all these different formats to grow. So I started code club. And so anybody could start a session. You pick a topic, you pick an activity, it's one hour. You get a group of four people and you work through the activity together. And we did about 50 plus code club sessions and what was great was that they were happening and they seemed to be working but I wasn't there. I wasn't actually in the sessions myself. And so I didn't know what the best practices were. I didn't know what worked and what didn't work. And so it was really important for me to take a step back and actually talk to the users. So I've talked to most if not all of the people who did those 50 sessions and I came up with a few takeaways. Some things that really helped code club succeed. The first was that having a manageable activity was really important. I got such great feedback from people who finished their activity in that one hour, who felt very accomplished just by the fact that they finished it. And for people who still had a little bit of work to do, didn't quite get there, there was a sense of kind of disappointment at that. So having something that was completable in a short time seemed really crucial to the success of a code club. Calling people out worked. So this idea that I told all the hosts ahead of time, feel free to call people out. Someone is a little too quiet. Say, Bill, I noticed you haven't spoken very much. Anything you wanna talk about, any questions you have. And so calling people out and making them interact actually worked. I got so much feedback from people who didn't intend on participating and people who were shy and were reserved and wanted to be quiet, saying I really got a lot out of it because the host called my name and asked me to participate. And I got more out of it than I would have if I just stayed quiet. Broken activities still worked. There were a couple of tutorials where the links were missing. The links were broken, it was out of date. But even in those sessions, instead of it kind of imploding the code club itself, what ended up happening is they were forced to find a way to make it work. They were forced to search it and they were forced to try different things and really push through and that made them stronger. So these lessons look kind of familiar. The manageable code-based part, that's similar to the manageable activity part. The calling people out, that goes back to the interacting with the code, to making sure to have conversations, to make sure that the team is fully involved. The broken activities, that kind of sounds like bad code is good too. But there was one really big problem, the tour guide. No matter how many times I told people that they didn't need to be experts, that they didn't need to be teachers, I couldn't convince them of that. They felt that if they were starting the session, they were responsible for all of the knowledge and information shared. And no matter how many conversations I had, it was really hard to shake that idea that if you are leading the conversation, you must have all the answers. And this was a really big problem that we had to solve. So we tried a slightly different format. We tried a format where there was one tour guide consistently and it was a consistent tour guide week over week. There was one set time and date that the group would meet and that anybody could come and go as they please. So it was a drop-in style. And we have three versions of those groups. We have one for Ruby, Ruby Monday. We have one for JavaScript, Tuesday. And we have one for Python, Thursday. And we did way more than reading code. We actually built things together. One of the biggest problems that I've heard and I've seen in the Learn to Code community is that there's this gap between I've done all the online tutorials, I've read all the books, I've built a few clones, but I don't quite know enough to get that first job. I don't quite know enough to fill that gap. And a big part of filling that gap is knowing how to work in a team. When you're learning on your own and you're in that silo, you're get pushing to yourself, which isn't quite applicable. And so you don't get the benefits of code reviews. You don't get to do pull requests. You don't get to learn about feature workflows. There's all these things about being a professional developer that you don't get when you're learning on your own. So we decided to give each team their own project to work on over many weeks. And we enforced this collaborative workflow so that people can get those skills to hopefully get their first job. So there are a few pretty big differences between this format and the previous ones. One was the unpredictable attendance. It was drop-in. For the other two sessions, you had to sign up, you had to say, you know, I'm coming on this day. With this style, anybody could come and we could have a full, a fully booked session, or we could have no people at all. So very unpredictable. The second was that there wasn't really any clear agenda. The projects that people worked on, they worked on in their free time during the week and on the weekend. But during the two-hour session, we used that session however made the most sense. So if we had to do code reviews, then we would do that. If we wanted to get unstuck, we would do that. So there was no set agenda for those two-hour sessions. And there were very different skill levels. This is probably one of my favorite differences, saying Ruby Monday gives you no real sense of what level you need to be. And it's great because we have people who've been developers for quite some time, who play more of the mentor and help the newer coders out. And then we have people who've done the Ruby Track and Code Academy and that's it. And no matter what skill level you are, we make sure to find the way to get you involved and to get you to contribute. And the biggest difference was that each club had its own long-term project. And this long-term project is still manageable. So Ruby Monday actually officially launched their completed project this week and they did a blog app. Nothing crazy, pretty simple. Everyone knows what a blog is. And so it was manageable in terms of the concept and the features it needed. But it was nice because it had all these little components that you need to leverage your skills in a collaborative manner. And the fifth and I think the most important one was having that consistent tour guide. Angel Jose is the lead for the Ruby Monday project. And my favorite thing that he does is if there's a new person who joined that session, he'll go to them and he'll say, what are you interested in? What kind of work do you wanna do? What kind of stories do you wanna pick up? What level are you at? And then he'll matchmake. And he'll say, you know, you should pair with so and so. They've got a really good handle on how we did these tags. And he really brings people in. And having someone who's going to be very inclusive and kind and understanding as a tour guide has been definitely the success of this format. So what's interesting to me is I think about the evolution of the Code Club idea is that we did it in three ways. The first way was just me doing it with my developer friends, getting a group together and coding. The second was having strangers start and sign up for sessions, one-off sessions that happened just for one hour at whatever time they chose. And the third format being these drop-in long-term projects with one consistent host that you can rely on but letting contributors come and go as they pleased. And these are three pretty different ways of doing things. But even with these differences, the guidelines still applied. The initial guidelines of picking something that's manageable, making sure that the team is fully engaged, feeling free to have these conversations and digressions, knowing that even if the code that someone submits isn't good, there's still a really great learning opportunity there, knowing that these are great times to take a step back and find those knowledge gaps and hopefully fill them and to find features and stories that are relevant to you and that you connect with, all these things still apply no matter what the format was. And what I realized was that the guidelines weren't for this concept of a Code Club. It was really just rules for social learning. And social learning is when you get a group of people together and you understand that you can get further together as a team and you can grow and develop as programmers and as people way faster and probably with a lot more happiness than you can if you do it alone. So when I talk about Code Club, people automatically think education. I've had a few people say, oh, you're in the ed tech space. And that's not entirely accurate because the problem that we're solving for isn't an education problem. It's not a coding problem. It's not even a learn to code problem. We're solving for a problem that's way more basic and way more human than that. We're solving for the problem of feeling incredibly overwhelmed by this awesome thing you wanna do and feeling deeply and painfully alone. And I feel like everyone in this room, I bet, has felt this way at some point in your coding journey where you wanna do something and you see this huge mountain that you have to climb. And you just don't know if you can do it. And you don't know what creatures are gonna find along the way. You don't know if you're fit enough. You don't know if you brought enough water with you but you wanna get there. And you know that other people have gotten there. You see them at the top. You've read their books. You've used their code. You've watched their videos. But you don't know if you're even half as good as they are. And you don't know if you're as capable. And those demons of doubt are so loud and so annoying. And they're there maybe because of where you come from or what you look like or the accolades you wish you had. But whatever the reason is, that mountain is terrifying. And it would be so much easier if you had a friend to go with you. My biggest concern is that as we all grow and become more experienced and more knowledgeable, that we'll forget what it's like to be at the bottom and looking at that mountain. And we'll forget what it's like to feel so overwhelmed when you open up that code base for the first time and you have no idea what's going on. And you feel this cold panic. And you feel the shame of not knowing which we often mistake for being stupid. And my favorite thing about these Code Club sessions is that I get to see these people who don't know if they're gonna make it, but they're climbing anyway. And it keeps me grounded and it keeps me connected. I've got a pretty long way to go in my own coding journey, but I've gotten this far in part because of the amazing people who've helped me and helped make that climb a little bit easier. Who saw my passion for this community and for code and who helped make it a little bit better. And I hope that you all do the same for all the code newbies behind you that are climbing. Thank you.