 energy has everybody doing, much, much better. So this is my first time in Europe, very excited. Everything I know about England comes from Harry Potter. And it's pretty accurate, so I'm really happy. Bath is an absolutely gorgeous place, in case you didn't notice. And can I get a round of applause to the organizers, who are doing a great job. That's too much applause. That was more applause than I think I'm going to get, I'm a little jealous. So my name is Saran, and I would like to start by telling you a story. So two years ago, I was not a programmer. I was this chick. I worked for startups. Show of hands, how many people have worked for or are currently working for a startup? Raise your hand. Oh, that's wonderful. OK, so you know the life, right? There's like five people. You're all trying to make it work. And on that team, I was not technical. I was the person who did pretty much everything else. I did some marketing. I did some sales. I did some business development. But I found myself always looking over at the developers and the people that I thought had the real power. And I was so jealous of what they could do. Because they could build stuff. They could make actual things. And I couldn't do that. And I really wanted that superpower. So I quit my job at a startup. And I decided to learn to code. And I went to a three-month boot camp, and I graduated. And I was so excited. And if you don't know when you graduate from a boot camp to be a real developer, you have to raise a keyboard and click your heels. Otherwise, it's just not official. And when I graduated, I felt so powerful. There was all this stuff that I knew that I conquered. And then I got a real job. And then I realized that there is so much more to know. There's the code stuff that you don't know. There's the stuff that you don't know you don't know, which is a lot of fun. There's the stuff that you thought you knew, but you never really understood. Then there's the stuff that you forgot. And you didn't know you forgot. And when you do, that'll be a great surprise. And by the way, everything changes all the time. So welcome to programming. So if you're not familiar with the Dreyfus model of skill acquisition, it says that when you are trying to learn something new, you go through a couple of phases. Everyone starts as a novice. And when I got my first job, I was very aware of how much of a beginner I was. And I don't want to be a beginner. I don't think anyone here wants to be a novice. You want to be an expert. You want to be that chick. You want that orange cape and those really cool sunglasses. And that's the person I wanted to be. And so I went to all of my senior developer friends and I said, how do I do that? How do I become an expert? How do I go from novice to expert in as quick a time as I possibly can? And they said, read code. Wonderful. That's pretty straightforward advice, I think. And so I went to a couple of my friends that graduated with me and I said, hey, let's get together for one hour every Sunday at 11 AM. By the way, I am not a morning person. I don't wake up before 2 PM on a weekend. So this to me was just a huge amount of dedication. And so we decided to call it CodeClub. So we went back to those senior developers and we said, what kind of code should we read? What's a really good code base to study from a beginner perspective? And they said, you should read anything. That's not helpful. If someone comes to you and says, how do I start learning this thing? Don't say, oh, you can start anywhere because there's nothing I can really do with that. So we decided to create our own set of rules. We said that the code base we read should be exemplary. And we defined exemplary as being popular, something that we'd heard of before, something that was well documented so that if we ever got stuck, we had something to go back to, something that was well written, which is kind of hard to judge as a beginner. But we felt like we could kind of get a sense of that and something that was well maintained, something that wasn't totally out of date and was still being used. So we hoped that by reading code together on a regular basis, we would go from these poor, pathetic novices to badass experts. So we decided to start with Sinatra's get method. Now, in school, Sinatra was the first framework that we learned. And we never really understood how it worked. So we thought this was a good place to start. So we got together on Google Hangout. By the way, I'm a huge fan of remote working. Any excuse to not wear pants is great. And so we got together and we were so excited to finally understand how the get method worked. And after some time, we realized that it was a little too complex for us at that point because we found ourselves kind of following one method call to a different method call and we were going across files and we'd see something interesting and then we'd go down a rabbit hole and it just kind of all became very overwhelming. And we went from being very excited to kind of scared. And so I'm a big fan of retros. I like kind of taking a step back and saying, how did we do? What can we do better? And so at the end of that first session, we said, how was the experience for each of us? What did we learn? And how can we do this better next week? And the first lesson that we learned was to pick a manageable code base. So Sinatra was just a little too big to cover in one hour. And so we decided that for all future code bases, we're going to stick with 100 lines of code. And that was an arbitrary number but it ended up working out really well because when you start with something that's that small, it gives you a lot of leeway. It gives you time to ask questions. Everyone felt comfortable saying, hey, wait a minute. I don't quite understand what that is. Can we go into that a little bit deeper? It gives you an opportunity to try things. And very often we'd open up Pry or IRB and just start trying the things that we saw. And it was a great learning opportunity. And it was also great because we got to research topics. If there was a new method that we wanted to read the documentation for, everyone felt comfortable doing that and exploring it without feeling like we were holding people back. And what I learned in that first session was that it really wasn't about reading the code. The code was just a really good excuse. It was about the digressions. It was about these conversations. Those rabbit holes that I was initially kind of worried about were actually the best part of the whole thing. The third thing that we learned was that it's a team effort. We kept our group small. We kept it at five. And when we told people about it, people said, can I join? I had to say, no, you can't, sorry. But it really was a team effort. And by keeping the group really small, we had an opportunity for everyone to feel like they had a voice. Everyone felt like they could participate. The other thing that we found was really important is to have a tour guide. This isn't an expert. They're not teaching. It's not the person who knows everything. It's the person who says we're gonna start on line four and we're gonna keep going down. By the way, does anyone have any questions? You know, Stephanie, you've been a little quiet. How are you doing? And kind of checking up on people and making sure that everyone is engaged. So we realized after a couple of weeks that finding exemplary code is really hard, especially how we define exemplary. So out of necessity, we kind of just found whatever code base we could find that was about a hundred lines of code. And in one of those sessions, Dan said, this method sucks. How would we write it? And he gave us our first moment of interaction. It was the first time that we said, huh, if we were the developer who created this code base, what would we have done? And we got to interact and engage with the code base in a very different way. And so the way we interacted is by asking a couple of questions. We asked, what is the intent of this method? What is this thing actually doing? Why was it written that way? And how did it fit into the overall code base? Was there a pattern that maybe we had missed where writing the method this way made the most sense? So what we learned by him asking that question and having that opportunity to interact and explore is that it doesn't have to be exemplary. Reading that code is awesome because especially as a beginner, if you know that what you're reading isn't something that's particularly stellar, it gives you permission. It allows you to critique that code base very, very comfortably because it's not supposed to be great. And that's a really, really important skill as a novice programmer. So these rules, you kind of throw them out the window. So everything was going swimmingly. And then one day, Dan, who's just always full of questions, says, I don't think I really understand how Rack Middleware works. And we said, Dan, it's obvious. And then we realized we actually didn't know how Rack Middleware worked either. And he gave us our first knowledge gap. There was this thing that we were looking at and all of a sudden this kind of big part of how, you know, Rails specifically works, we didn't really understand. So the next code session, instead of reading code, we decided to kind of break apart. We did our research on Rack Middleware things. We sent each other blog posts and videos. We reconvened and we talked it out. And we got an opportunity to both ask questions and do a little bit of teaching. And so finding those knowledge gaps and using these sessions to fill them is a really, really important tool. Everything was going swimmingly again. And then we read the Omnioth Meetup gem. So I had to use this gem and modify it for a project that I was working on at work. And so I asked the Code Club, I said, hey, do you mind if we kind of dive into this because I need to understand it anyway? And I realized that when I was reading something that I actually had to use, it was a totally different experience. I was way more emotionally engaged in what I was learning that I would have been otherwise. So if you can find relevant code bases that you need to use for your side project or for your real job, then it really does change your experience. So then there were some unexpected benefits. We're learning code, we're all asking questions, we're having a great time, but there are a few other things that I didn't expect that were very interesting. So the first is when you read code, you get to take a look at the organization of the code, at the structure. It's not just the individual lines of code that you're looking at, but how the folders are structured, how the files are named, and all these little things that you get to pick up along the way. You get to see collaboration. When I first learned to code, everyone talked about open source and how open source was this beautiful idea where people all around the world could come together and write code together. And I didn't really get to understand what that was until I started reading code. And all of a sudden I realized that this gem was actually forked from a different gem, which was forked from another code base. And I got to see the full collaboration right there. And it was really, really beautiful. And the third thing is building your confidence. As a novice programmer, I think this is really, really important. You're so self-conscious about what you know and what you don't know as you saw the big mountain of things I didn't know. And so with every opportunity that you have to feel like you're engaged and you have opinions and you ask questions really does wonders for your confidence and your code. So after a while of doing this, I decided that I wanted to try something new. I decided that I didn't wanna just read code and I didn't wanna do it just with people that I already knew. So remember when I told you I first learned to code and I did that boot camp thing? Before that, I spent three months alone in my apartment learning to code on my own. And this is what it felt like. I was very tired and my hair was a mess. And it was just a very exhausting and kind of a painful process. I used Treehouse and Co-School and anything I could find online. And it was just a lot more lonely and sad than I thought that it was going to be. But then when I got to boot camp all of a sudden I had these wonderful people to learn with. I had these people that I could cry with when things didn't work and people I could high five and they finally made sense. But that experience cost me $11,000 and many months without a job. And not everyone can afford this opportunity. And what I realized was that the value of that boot camp wasn't just the technical foundation it was finding that community support. So I decided to start something that you mentioned which is code newbie. So I didn't like this idea that if you didn't have that money then you couldn't really find a community of people to learn with. Especially if you're not part of a tech hub like I was in New York City. And so I decided to do a Twitter chat. By show of hands how many people know what a Twitter chat is? I'm gonna drop some knowledge on you, it's gonna be great. So the way a Twitter chat works is you agree on a hashtag. Our hashtag was code newbie and for one hour every Wednesday night at 9 p.m. Eastern time we decided to convene around this hashtag. And so I would tweet out questions like what did you learn today? Did you have any speed bumps? Anything we can help you with? And people would respond and include that same hashtag. So what happens is when you search for the hashtag you end up with a stream that's really just a great conversation with people all over the world who are excited about learning to code. And so I did this and I thought it would last maybe a few weeks, a couple of months but it's been over a year and we went from being just a regular hashtag, Twitter chat to being this incredibly diverse and inclusive community of people all over the world excited about learning to code. So I said, what if I took this community and I did these code club sessions with them with people that I didn't really know personally outside of Twitter? And what if we didn't just read code but we read other things like blog posts, we watched videos like I'm not saying any of these videos. We looked at tutorials and we read a chapters from books. What happened then? And so I made a little page on our site and allowed anyone to basically post a code club session they wanted to have. And we had a bunch of different topics from JavaScript to learning go to sublime text and all kinds of things. And actually our most popular one was TDD in Rails which is really, really great. And anyone could sign up and we kept the same guidelines that we took from code club. So every session was really small was at most four people at a time. We kept it to one hour and we picked really manageable activities. And in the past few months we've had over 50 different code club sessions. And what I learned was learning to code and being a better programmer wasn't just about reading code bases. It was more about learning together and understanding the rules of learning together that can make all of us much, much stronger developers and better people. Obviously you were excited about starting your own code club, yes? Okay, that was pathetic, you guys. One more time, are you excited about starting your own code club? That's better, I'll take that. So to review the guidelines, pick a manageable activity. If you want to read code for me that means about 100 lines of code is comfortable but try your own thing too. And if you're picking a blog post something short maybe one chapter from a book maybe don't read all of pooter but maybe one chapter of pooter at a time. Understand that the learning isn't about the reading it's not about the activity it's about the conversations that happen it's about me trying something out and you saying actually let's do this a different way it's in those talks that the learning really takes place. It's a team effort make sure that everyone is engaged if you see someone being quiet prompt them to talk and participate. You have to pick a tour guide someone has to be in charge for everyone else's happiness. It's kind of a big responsibility but I think it's really, really important. Interact with the code actually try things out there were so many opportunities where I would just literally try a copy and paste the example from the tutorial and try it out and then that would lead to us trying slightly different variations of that same code sample and we learned a lot just from that. It doesn't have to be good bad code is awesome for learning and find those knowledge gaps if you see something that's kind of big that you want to pause and dive deeper that is a really great opportunity to do so and find relevant code bases find things that you're actually genuinely interested in and you'll be a lot more engaged. So how is this getting me to expert? That's kind of how we started this whole conversation, right? I'm a novice and I want to go through those stages and I want to end up as an expert. So how does this do that? I found a graphic some time ago on Twitter that I really, really like and I think it explains how I understand these code club sessions to get me to being an expert. I'd like to share that with you. So this is information. Information is just data, right? It's just stuff. It's individual stuff. There's no story. There's no connections. It's all there. Knowledge is when you connect the dots. It's when you realize that there's some pathways that you didn't see before. It's saying that I can start from, they all look like skittles to me. I don't know if they look like skittles to you, but I can start from that yellow one all the way on the left. I can go to the green one. I can go down and then I can make my way up to that red. It's being able to see these different patterns. And when we have these code club sessions and we have these conversations, what we're doing is we're making those dots and we're making those pathways. We're able to tell a story. And what's great about learning together is that I have my own set of experiences and Stephanie has hers and Dan has his and we get to come together and we get to build and leverage all that experience in one hour sessions. Now, wisdom is knowing that I don't need all those skittles. I only need those two and those two are the most important skittles there. And I don't need that long convoluted pathway. I have that one shortcut that really matters. And so I believe that by having these conversations by learning together, by using these guidelines, we can get to wisdom and wisdom is how we become experts. So that is my talk. You're welcome to learn more at code newbie.com and thank you so much for your time.