 to be here. Before I start my talk I'd like to get to know you a little bit better. So round of applause if you're having an awesome day. Round of applause if you're having like an okay day. It's not bad, it's not great, alright. Oh, okay, nice. Round of applause if you're having like a crappy day. Clap for crap. Anybody? No? Oh wow, this is the first talk I've given where everyone is having an amazing day. That's great. Round of applause for you guys having an amazing day. No to self don't do that while you are holding a clicker. So I am Saran and today we're going to talk about code clubs. So a little bit about me, I work in Microsoft. I do a lot of coding and also product development work. I'm part of the civic tech engagement team so we do a lot of civic tech products. Currently a lot of what I do is an education. If you want to talk more about that I'd love to tell you about some of the stuff that we're working on. But today I want to tell you a story. So two years ago I was not a developer. I didn't know much about anything about code. I was this chick. I worked at startups. I worked at tech startups. I was in the field but I did all the things that were not technical. So I've done sales. I've done business development. I did a lot of talking but I didn't really work with the product team. And I felt like I was always sitting next to the engineers and I was always looking over their shoulders and thinking man I wish I could do that. That looks so much more interesting than what I could do. I felt like the engineers and the product people were the ones with the real power. The ones who could affect how the user experienced what we did and I was really jealous of their abilities. So I decided to learn to code. And that process for me was partly self-taught and partly a boot camp. So I did a couple months. I quit my job. I did full time like 12, 14 hours a day in my apartment. Very lonely, very sad. But I did a lot of this on my own and then I eventually applied to a programming boot camp and got accepted and did a few months there. And so when I graduated from the boot camp I was so excited. I said yes finally I have those super powers that I've been looking forward to and now I can do all the things that I want. And I felt like that. I felt so cool and so badass. I conquered all the code stuff and then I got my first job. And I felt like that. I felt like there was so much code stuff that I didn't know yet. There was stuff I didn't know I didn't know. There was stuff that I thought I knew but I forgot. That's a nice surprise. And by the way all this stuff changes all the time. So welcome to programming. And to me this was just a really harsh awakening. It was very, very humbling. And this is the dravest model of skill acquisition that says that when you are learning a new skill you have to go through these phases. You start as a novice. You moved on to an advanced beginner, then competent, then proficient, and then finally expert. Which is what I think all of us want to be. And that's why I wanted to be. I wanted to be that badass expert in that cave in those awesome glasses and I wanted to know everything that I could about code. And so I asked my mentors and senior developers. I said what can I do as being a novice right now? What can I do to get to expert? What do you think they said? Practice, practice. That's a good one. Yep, code. Anything else? Read code. You knew what this talk was going to be about. So they said to read code. That was one of the most common answers that I got to that question. And so I got together, my group of friends, we all went to that boot camp together. And I said hey, let's get together for one hour every Sunday at 11 a.m., which is a big commitment for me because I'm not a morning person. Yes, 11 a.m. is still very much the morning. And I said let's get together and let's read code. And so the first thing you do when you decide to go on this adventure with your friends is you have to pick a name. What do you think we call ourselves? Code club. He said that was the right answer. So we decided to call ourselves code club. So the second thing you have to do is you have to pick something to read. And so we went back to those experts, those mentors, those senior developers, and I said okay, what should we read? We have a time. We got a name. We have a place to meet. What are we going to read? Guess what they said? You can shout it out. I won't bite. Code. You should read code. That's actually very close. They said anything. They said you should read anything. That's not helpful. If I ask you where I should start and how I should begin doing something I've never done before, don't tell me that I can start anywhere. So having said anything, we decided that we had to pick some guidelines. We put together some rules that would help us determine what to read and how to read it. So one of the things that we decided is that the code that we read should be exemplary, which is very, very subjective. So how do you define exemplary? We defined it as one being popular, something that people had heard of that was currently in use, something that was well documented. We as beginners thought this was very important because if we couldn't understand what we were reading, we wanted to have documentation, a reference to go to. We wanted it to be well written, which is kind of hard because as beginners, how do you know what is well written? But we thought it should be well written anyway. And lastly, we wanted it to be well maintained. So something that was up to date, something that was recent. These were how we defined exemplary. And we believed that if we found this good code, and we read it every week, we would go from novice programmers to badass experts. So the first thing we decided to read was we looked at Sinatra. Show of hands if you know what Sinatra is. Okay, great. So if you don't know, you can read it. DSL for quickly creating web applications in Ruby with normal effort. This is one of the first Ruby frameworks that we learned in bootcamp, but we didn't really dive into the internals. We didn't know entirely how it worked. And so we thought, hey, we've always wanted to learn a little bit more about this. Let's use this as an example to dive deep. So we started with Sinatra's get method. And we decided to gather. We used Google Hangout for this. And we were so excited when we first started. And we started with that get method. And we were following that method to a different method, to a different file, to a different directory, to another file, to another directory. And we quickly became overwhelmed and very afraid. And that one method took us a lot longer to dissect and unpack than we had time for in that one hour. So I'm a big fan of retro. I love doing something for the first time, taking a step back, going through what we did, figuring out how we could do it better. So after that first hour, we asked, how was that experience for everyone? What did we learn? And how can we improve? And the result is that we found that one of the most important things for us was picking a manageable code base. So Sinatra was a little too big. Even that one get method was a little too big for all of us to comfortably go through it. And so we decided to pick really an arbitrary number for ourselves. We said that from now on, we're going to pick code bases that are 100 lines of code. And that ended up being just the right amount of code that we could go through in an hour. And when we did that, what it meant is we actually had time. We had time to ask questions. People were comfortable asking more questions and going on tangents, because they knew that we only had a short code base to go through. It gave us the time to try things. If we saw a method we didn't quite understand. We could clone that repo and we could open up, you know, prior IRB and actually try some of the things that we saw. It was also enough time for us to research topics. If we saw a whole new thing that we didn't understand or a pattern that looked kind of familiar, or a module that we never seen before, we could actually pause, do our research, come back and talk about it. And we could do all that very, very comfortably because we picked something that was manageable. And what we learned in that first hour is that it really wasn't about reading code. That's not where the knowledge and the power came from. It was about the digressions. It was all those conversations. Reading the code was really just a launching point to do much more interesting investigating and learning together as a group. The third thing we learned is it's a team effort. We kept it at five when we started telling our friends, we had a couple people say, oh, can I join? And I was like, no, sorry, start your own thing. And that's because it was really important for us to make sure that everyone on the team was engaged and active and participating. And in order to do that, you have to have what we call a tour guide. And that was the person to say, hey, let's start on line one and go down. Hey, let's pause here and look this up. Let's open up pride and try some of these things out. And another really important role for that tour guide is to catch the people that are trying to be quiet. And to say, hey, Ian, I've noticed you haven't said anything. Are you lost? Are you confused? Do you want to take a stab at answering this question? And it was someone to really make sure that everyone was happy and engaged and we're all on the same page. The tour guide is not the expert. They're not the teacher. They're not the one with the answer. They are the host of the party making sure everyone's having a good time. So the first few weeks were awesome, but we ran out of exemplary code. And so out of necessity, we had to read bad code. And for us, that bad code was the code that didn't reach the four the four rules of exemplary code. And when we did that, Dan looked at it and looked at a particular method and he said, this method sucks. How would we write it? And this was such a crucial moment in our code club history because he gave us our first moment of interaction. He gave us the excuse to say, huh, this isn't the way that we would do it. How would we do it? And he offered us the opportunity to actually try it ourselves. And what this did is it made it made everything so much more engaging for us and so much more personal for us. And so we asked questions that said, you know, what is the intent? Why was it written that way? Is there an overall pattern that we're just completely missing? How does it fit in with the rest of this code base? And what we've learned is that code doesn't have to be exemplary. Bad code is awesome. And it's awesome, especially for beginners, because when we know that we're reading something that we don't think is very good, it gives us permission. It allows us to say, to critique it and to say, you know, this isn't quite right. How would we do it? And for us to try things. So it gave us a confidence that we would not have had if we were criticizing rails, for example. So we threw out those rules and we said, we're just going to find code. That's 100 lines of code. So everything was going great again. And then Dan says, guys, I don't think I really understand how Rack Middleware works. We were looking at some gem. I don't remember which one it was. Rack Middleware came up and he asked us that question. And we said, Dan, it's so obvious. And we tried to explain it to him. And then we realized that none of us knew how Rack Middleware worked. And in doing so, we found our first knowledge gap. And this was really exciting because what we did is next week, instead of picking a code base to read, we instead said, let's all research Rack Middleware. Let's go off. Let's find videos and blog posts and articles. Let's read it. Let's understand it. And let's see if we can try again and explain it to one another. And so again, going back to this idea of reading code as the launching off point, this was a really great tool for us to find these knowledge gaps that we wouldn't have uncovered otherwise. Everything was going great. And then came the Omnioth Meetup gem. So this is a gem that I was using at work for a social media platform that we were doing. And I didn't really understand how this gem worked. The documentation was a little shoddy, wasn't very good. And I thought this would be a nice small code base for us to read as a group. And then I can understand a little bit better and everyone can learn from it. And in doing so, we realized that finding relevant code bases were really important. All of a sudden, I was a lot more passionate and excited and really intent on understanding this than I was the previous code bases because I was personally invested in understanding this. So we realized over time, over a lot of iteration and trial and error over many weeks, if not months, that we developed a set of guidelines. So picking a manageable code base, depending on your expertise and how much time you have, it can be 100 lines of code or something more. For us, 100 lines really was the right number. Two, learning happens in the digressions. Those rabbit holes are awesome for learning. And we learned to embrace them instead of resist them. That it's a team effort, making sure that your team is relatively small and everyone is engaged and really active was important. And having a tour guide, someone to make sure that everyone's having a good time. Interacting with the code is great. I love those opportunities where we can actually try out some of the methods and figure things out. It doesn't have to be exemplary. Bad code is great. Finding those knowledge gaps and not being afraid to take a break, do a little, do a little digression and actually dive deeper into something you may not have understood. And then finding a personal connection with that code base, maybe it's a problem you're excited to solve, a gem you're using for work can really transform that experience. And then there were some unexpected benefits. One was that when you're reading code, you get to look at the organization of the code base, which is something that especially as a beginner, you don't have a lot of exposure to if you're just making stuff yourself. So you've got to see how things were named, what the folder directory structure was like. You get to see how things fit together on a higher level just in terms of the code base itself versus reading the code. You also get to see collaboration. One of my favorite things was realizing that one gem was actually a fork of a different gem. And I feel like when we learn to code, we hear about open source and that was just a very, you know, exciting thing that everyone told me about and I was going to be a part of. And when you're reading code, you get to actually see it. You get to see how different code interacts and how different contributors work together. And third, it builds your confidence. I found over time that I started relying less and less on documentation when I didn't understand something. And I have a confidence to actually just go to the code base and read it myself. And so over time, I really saw my personal confidence increase. So after a while, I wanted to try something different. I didn't want to just read code 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 a lot like this. I was tired, it was lonely, it was frustrating, it was me just kind of fighting my computer and you know the computer is always right. And then when I got to bootcamp, all of a sudden I had all these people. I had this community of people who were just as excited to learn about code as I was. We would cry together when things didn't work and we'd high five when things worked. And it was just such a different experience for me. But to get that experience for me cost $11,000 and many months without salary, which isn't exactly feasible for probably most people. And I didn't like that. I didn't like that to get that type of emotional support on people making the same journey that I was, that this was the cost that I had to pay. So I started something called code newbie. Has anyone been part of a Twitter chat before? Show of hands? Yeah, anybody know what a Twitter chat is? Show of hands? It's funny they're like less people who knew than people who participated. So a Twitter chat is when you pick a hashtag. So for us the hashtag was code newbie and you pick a time. So for us it's 9 p.m. Eastern time on every Wednesday and someone will tweet out questions using that hashtag. And so I would tweet out things like what are you learning this week? What are you really excited about? What are you building? What languages are you working on? And people would respond using that same hashtag. And so if you search for the hashtag you basically get to see this really nice stream of conversation happening around that one topic. And so I started doing that because I saw other Twitter chats happening and I thought it was a really easy low barrier way of starting conversation and starting to build a community. And I saw people get really excited about it and start to respond. I saw people from all over the country, all over the world, people who use 4 a.m. in the morning and where they were when they were responding to these tweets. And they were really excited to find and connect with people just like that. People who were excited about code and finding out about it relatively later in life than a lot of more senior developers. And so it started as a hashtag and I thought that it would last maybe a few weeks, a few months. But it's been, Jesus Christ, it's been almost two years. And now we've grown into this really, really incredible diverse community of people. And one of the Twitter chat topics that I had a few months ago was called past lives. And it was people tweeting about what they did before they learned to code. And it was fascinating. We had people who were ballet dancers, truck drivers, people who were teachers, people who were biochemistry professors, just all kinds of different walks of life. And I was really excited to see that all these different experiences and perspectives were now going to be part of our community. And so we started as a Twitter chat. But the problem with the Twitter chat is it goes away. You can storeify the tweets, you can keep them around, but they're not really a good way of archiving information. And so from there, we started an online forum where you can actually go back and collect data a little bit better. But the forum isn't a great place to dive deep into a specific topic. So as a result of that, we started the Code and to be podcast which we've been doing for the last year. And it's a weekly podcast showcasing different developers and their stories. But the problem with that is that when you focus on one story, you don't get to hear all the other incredible stories. So we have a blog where people can contribute and talk about how they learn to code, what they're struggling with, what they're learning. And so we started all these little channels and all these different little support systems for people excited about code. But that wasn't enough. These were all really great tools for people to share resources, but I wanted to create something where people could actually learn together. So what if you took this idea of Code Club that we've been talking about and you brought it together with the Code Newbie community? What would that look like? And what if instead of just reading code, we read a bunch of other things? You can learn a lot, I'm sure you all know, from blog posts and tutorials and videos and talks and book chapters and lots of other sources of information. So we created this online thing called Code Club. And it was great because anybody could start one. You start a session, it's one hour, you can have up to four people and you picked a topic or an activity you wanted to do and then you'd all meet online and you'd go through that activity together. And people would sign up and the seats would fill up very, very quickly for this and it covered all different types of topics in many different languages and frameworks. And so we ended up doing over 50 Code Club sessions and I was really excited about that. But the problem was that I was now on the outside. I didn't know how good or how bad those actual sessions were. So to figure out how to make it better, I had to go and talk to users. And I learned some interesting things. The first is that having a manageable activity is really, really crucial to people wanting to come back and to people getting the most out of these sessions. And there were so many times when the activity they had to do in an hour was just too big. It would take hours to really finish and I saw that people were pretty disappointed about that. When they did finish an activity, even if it was really small, they felt a lot more accomplished. Second is that calling people out worked. So going back to that tour guide idea of saying, you know, hey, Dan, you've been a little bit quiet. What do you think? And making sure that people are actively involved. I would similarly tell the session leaders I would say, don't be afraid to call people out. If you see someone being a little too quiet, if you see someone who isn't participating, invite them to participate. And I was a little worried about this because I didn't want to make people uncomfortable, but I wanted to offer them an opportunity to engage. And what I found was that even people who came to me and said, I'm very introverted, I'm very shy, I didn't want to talk, they still said, I'm glad that the host called me out and said, you know, what do I think and how would I solve this problem? And I got a lot more out of it than I would have if I just stay quiet. And I thought that was very interesting. The third is that broken activities still worked. So there were a couple activities that were picked where the links were broken or it was just really out of date. I think there were a couple where the tutorial just kind of stopped halfway and didn't actually finish. And even in those moments, it was still a really good session because what that did is it forced people to fill in the holes themselves. It forced people to actually look things up and do a little bit more digging and they've still got a lot out of it. So these lessons might look familiar to you. They look familiar to me anyway. So the first is it goes back to our Code Club guidelines, right? So this idea that you have a manageable code base for reading, you still need a manageable activity for a Code Club session. This idea that calling people out works, that ties into this interacting with the code, embracing digressions, and making sure that everyone on the team is involved and is excited. And that third one of broken activities working goes back to code base. Bad code bases are still really good code bases, especially for learning. But there was one pretty big problem. This idea of a tour guide was really hard to sell. When we had these sessions, they filled up pretty quickly, usually in a few hours. But getting people to start the sessions was a huge problem. I would tell people, you don't have to be an expert. You don't have to be a teacher. You're not running the class. You know, this isn't a class, first of all. It's a team project. And they just didn't believe me. They felt like they had to be that expert. They had to be that teacher. And it was a really hard assumption to shake. So we tried a different format. To solve this tour guide problem, we said, OK, what if we actually had a designated tour guide? And they would be the tour guide consistently over a number of months. And people can drop in whenever they want. And so we have three groups. I think now we have a little bit more. We had three groups running, Ruby Monday, JavaScript Tuesday, and Python Thursday. So we picked the three most popular languages in our community. And we did more than read code together. We built together. So one of the big problems that I've seen in the Code Newbie community is this huge gap between the experience you have when you're learning to code on your own using code school, treehouse, whatever the tools that you're using and the skills that you need to be a productive member of a dev team. When you're on a dev team, you generally have pull requests and code reviews. You have project management tools. You have some kind of a get workflow that you're doing. There are all these things, all these skills that make you a good member of a dev team that's very hard to get if you're learning to code on your own. So instead of reading code, we had each of these teams have a project that they worked on on the long term. And they had to use all these collaboration techniques and tools that would help them get that first dev job. So there were some pretty big differences between this model and the one we talked about previously. One is that it's pretty unpredictable attendance. There was no sign up process. It was the same time every single week. And so we didn't know if people would one show up and who would show up. Two, there was really no agenda. We used the, so it went from a one hour session to a two hour session. And in those two hours each week, what we do is we'd go through any open pull requests. We talk through anything, any features that people were stuck on. And we really used it to unpack and almost do a weekly retro. But a lot of the coding that happened on the project happened in people's free time outside of the two hour session. So each week was a different agenda. It wasn't a specific activity that they were going to do. Number three, and this to me was very interesting. We have very, very different skill levels. We have people who are on these teams who've been coding for a couple weeks. We have people on the teams who are very, very experienced. And their role is more of a mentor, someone who can come in and provide guidance. So being able to make sure that all these different people are involved and engaged on a project, regardless of their skill level, has definitely been interesting. And number four, each club had a long term project. So it wasn't this very short, very narrow, one time activity that people were doing. It was a project that generally took between two and three months to complete. And finally, probably the biggest difference is this consistent tour guy. We had one person who was in charge of making sure the project management tool was up to date, making sure that people were added to the GitHub repo so they could contribute. We had one person really in charge of making sure the team was happy and engaged. So if we look at the evolution of Code Club, we did it three ways. The first was just me, my developer friends, meeting for one hour every week, primarily reading code. The second was having anyone start and sign up for sessions, limiting it to one-off, one-hour sessions with a very specific activity. And three was having strangers dropping in on a long-term project with a guide who was going to be there for a very long time. And even with these differences, the guidelines still persisted. So these eight guidelines still carry through even to the most recent version of the Code Club. So picking a manageable activity had a slightly different meaning. It wasn't 100 lines of code. It wasn't something you can complete in one hour. A manageable activity was something that the team could finish. So for example, the JavaScript group, one is just practice, just vanilla JavaScript. And so they did a very familiar game to, I'd say, a lot of people here, Hangman. They had a very simple game that they knew they could finish. The Ruby group did a blog app, which is a pretty common thing to do using Rails. And so they picked something they understood, they knew how it should work, and it felt very doable to them. The learning happens in the digressions. We decided to focus the two-hour sessions on conversations, on reviewing pull requests, and then having that person talk through how they made those decisions. And that almost always led to people discovering new gems and new tools, new concepts, new patterns, and we really embraced those conversations. It's a team effort. One of the things that the tour guide does that I absolutely love is if they see a new person join that week, they'll say to that new person, they'll pull them aside and say, hey, notice this is your first time. What's your experience level? What kinds of things do you want to get out of it? And they'll pair them with someone on the team who's been working on the project for a longer period of time. So they really make an effort to make sure everyone is included. Having that tour guide there is incredibly, incredibly important, making sure that they embrace the code newbie spirit of being really nice and welcoming and inclusive has been really, really great for the success of this idea. And five, interacting with the code. They actually interact with the code because they're building it. They're actually building out these features and these stories. It doesn't have to be good. One of my favorite parts of watching these projects be built is when they build something that isn't quite right and then a more senior person will come in and instead of saying, that is not right, don't do that, they'll say, tell me about how you came to this decision or have you looked at this in this blog post? And we really have this culture of being really nice and being really welcoming and it feeds in during these code reviews and during these comments. Finding those knowledge gaps, so every week during those sessions we're finding those things so we don't understand and exploring them. And then finding relevant code bases. It was really important to me to make sure that every team picks their own project and everyone is emotionally invested in what they're building. One of the most recent things that I believe the JavaScript team is building is called the newbie mapper. So a lot of what we do in code newbie is online and people don't know where other people are and they want it to more easily code in real life. And so we are now building a newbie mapper that everyone's really excited about because they want to know are there any other code newbies in my area that I can pair with in real life. So what I've learned from really thinking about these guidelines is that it's not about code club. The format of code club is really just implementation details. What the dates are, what the times are, how long the sessions are, those aren't really the things that matter. The guidelines are more for social learning. When you have a group of people who are incredibly excited about code and really excited about using code to make a better life for themselves, how can you learn together in a more effective way? How do you leverage everyone's excitement and their passion and their resourcefulness to make everyone in the group really productive and better coders and better people? So when I talk about code club, people automatically think education. People think, oh, you're an ed tech, which is something people tell me all the time. And that's not really what we're doing because the problem we're solving is not an education problem. It's not a technical problem. It's not even a learn to code problem. It's something much more human and much more basic. It's the problem of feeling alone. It's that feeling that I think everyone in this room has spelled at some point in their coding journey where they have this mountain to climb and they don't think they can do it. They don't know what creatures they'll find along the way or if they're in good enough shape. They don't know if they've brought enough water. But you know that other people have done it. You've seen other people at the top. You've read their books. You've watched their talks. You've used their code. But looking at them, you don't know if you are as capable. You don't know if you're as good as them. And those demons of doubt are so loud and they're so annoying. And it sure would be nice to have someone on that climb with you. And that's what Code Club is really about. It's about finding people to climb that mountain with. I worry that as we become more experienced and as we become more knowledgeable, we'll forget what it feels like. We'll forget what it feels like to look up at that mountain and just be terrified. To open a code base for the first time and have no idea what's going on and to feel that cold panic, that shame of not knowing, which we often confuse with stupidity. And what I really love about these sessions is it's such a great reminder of what it's like to be that afraid and what it takes to climb anyway. I've got a very long way to go as a developer, but I got this far in part because of all the incredible people who've believed in me and who saw my passion for code and my passion for this community and who've helped me get there. And what I hope is that you all help some code newbies who are climbing behind you. Thank you. I guess I'm supposed to do questions now so we can do that. Anybody have any questions? I don't know. What are the age ranges of people that are in code newbies? Are there kids, young, how old do they go? I don't, I think they go pretty old. If I had to guess, maybe like fifties, but I've never asked. As far as young, I think we focus, oh, is that, oh, I'm sorry. Is that, just kidding, that's super young. This is being recorded, right? But as far as young, so we focus more on adults. Like we focus on people who are using code to transition into a new career. So a lot of people, I'd say like our average age rating is age rating just probably like late 20s, early 30s. We have had some kids join, which has been funny because they're like, do you mind if I join? I'm 13, and I'm like, ask your mom. I don't know how this works. So we've had a couple, but it's mostly adults. I was curious about consistency. Like if you've had problems with like cancellation, so when you're trying to do something weekly, like that can be pretty heavy frequency, like to do something weekly and to actually get people to show up and if they show up, have they done their homework? Like if there's homework? Yeah, that's a really good question. So we don't, there is no sign up process. So there's really no expectation that a person will be there every week. I don't, I think it's really hard to get people to show up every week, especially if it's something that's free and that's online, like that just kind of ruins your chances. So instead what we focus on is we allow, we give people things to do in their free time and that two hour weekly thing is an opportunity for them to come if they're stuck, if they want to see what other people have done, but a lot of the work can be done just throughout the week whenever you have time to work on it. I think that our participation rate is maybe, I think people come about 50% of the time because life happens and things happen and that's our expectation. So we set it up in a way that you don't have to come every week for it to be successful or for you to get a value out of it, yeah. Yeah, so this is an observation that when you started out trying to solve this problem of getting to be an expert at code and you didn't go and research how people did it, you just came up with some ideas and went through it. On the other hand with actually doing the code itself, you tried to find expert code to start with. So I'm wondering why you didn't take the same approach to code as you did to the problem, the meta problem of solving. Yeah, so I think that my research was asking people. So my research was asking more senior developers than myself and I did some research too and said, how do I get better at code? And a lot of it was as people said, practicing and actually coding a lot and the other half was reading code. Practicing coding is something that as a coder I think I do every day anyway and the reading code was this additional thing that I could do outside of my work hours that I thought would give me an edge compared to just coding all the time. So I like to think I researched both things. Any other questions? Just wondering if you could tell us a little bit about Tech Jobs Academy. Sure, so Tech Jobs Academy is one of the programs that I'm program managing at Microsoft. So it's a 16 week, four month program that we're doing in partnership with City Tech in CUNY. So one of the CUNY campuses in Brooklyn and we're doing it also with the Tectile and Pipeline which is part of the mayor's office and the small business services in New York. So I'm from New York by the way, that's a thing that is relevant to this conversation. And so we are doing a 16 week program focusing on mostly IT based skills and we're taking 25 participants and we're hoping to launch applications in the next two to three weeks. So keep an eye out for that. Anybody else? Don't be shy.