00:00:00.420
Hi everybody! Can you hear me? How are you guys doing? I'm so excited to be here! This is my first time in Australia. I flew from New York City to be here, and the only thing they told me about Australia in the U.S. was that you guys had kangaroos, maybe. I'm really hoping to meet one. I don't know where to find them, but yesterday during the opening party, someone told me where I can find a kangaroo burger, which I guess is close enough.
00:00:20.580
My favorite part about coming here has been stepping outside, stepping onto the street, and smelling the flowers. That is amazing! Has anyone visited New York City? We have different flavors of pee! That's what we have, so you all are totally winning. I'm really looking forward to after the conference when I get to take beach selfies and tweet them to everyone in New York, making them really angry because that's what Twitter is for.
00:00:39.000
But before we do that, we're going to talk about Code Club. Years ago, I was this chick who worked at startups. I did non-technical things like business development, sales, and some design. I worked alongside developers and next to the technical folks, but I wasn't really one of them, and I really wanted to be. I found myself always peeping over at what they did, feeling that what they did was much cooler than what I could do. I wanted to be part of that group and make an impact at the company I worked at.
00:00:59.039
So, I decided to learn to code. I taught myself how to code for a couple of months and did Treehouse Code School. One of my favorite resources was Chris Pine's learning program, which is still one of my favorites. I dedicated 12 hours a day to learning, and finally decided to attend a boot camp. I applied, got accepted, and when I graduated, I was so proud of all the awesome coding that I had conquered. But then I got a job, and that's when I realized there was so much code stuff I didn't know—things I was unaware of, and everything changes all the time. So welcome to programming!
00:01:43.020
Has anyone heard of the Dreyfus model of skill acquisition? This model explains that when I try to acquire new skills, I have to go through five phases: novice, advanced beginner, competent, proficient, and finally, expert. When I started working, I painfully realized how much of a novice I truly was. I'm sure nobody here wants to be a novice, right? We all want to be experts—the people with the badass glasses and the capes! That's what I wanted to be, so I asked the TAs, senior developers, and those who knew how to code, 'How can I go from novice to expert as quickly as possible?' They advised me to read code. How many of you have received this advice before?
00:02:35.819
I gathered my developer friends and said, 'Hey, we're going to read some code together!' For one hour every Sunday at 11 A.M. Eastern Time, we met up to read code in hopes of going from novices to experts. The first step in gathering a team of developers is to pick a group name, so we decided to call ourselves Code Club—because we're creative geniuses! Next, we had to decide what to read, so I went back to those experts and said, 'We've got the group name and we're ready to go, but what should we read?' They said, 'Anything that's not helpful!'
00:03:07.560
They advised against saying to someone, 'You can start anywhere.' That's not good advice! So, we decided to establish some guidelines. The codebase we chose needed to be exemplary. By exemplary, we meant it had to be popular—some good stars on GitHub would be nice. It also needed to be well documented. This was especially important for us as novices because we were worried we wouldn't be able to understand the code. Furthermore, we wanted it to be well-written, and we included this guideline though we weren’t sure how we’d recognize well-written code. Lastly, it should be well-maintained—something that's updated and current.
00:03:54.060
We believed that if we studied exemplary code for one hour each week, we would transition from novices to badass experts quickly. We started with Sinatra, which was the first framework we learned about. It’s a DSL for quickly creating web applications in Ruby with minimal effort. We knew how to use it, but we didn't fully understand how it worked, so we decided to start with the GET method. We got together on Hangouts, excited and saying, 'In one hour, we can understand what this method does and how it works!' However, reading it took us from one method to another, to another, and we ended up feeling overwhelmed.
00:04:43.920
We decided to hold a retrospective, which I enjoy doing every Friday with my husband. After that hour, we asked how the experience went, what we learned as a group, and how we could improve for the next week. We had some takeaways: first, it was vital to pick a manageable codebase. Looking at Sinatra was a bit too big to dissect in one hour. Thus, we decided that the next codebase we read would be no bigger than 100 lines of code, which allowed us to ask questions without feeling bad about stopping and having a conversation.
00:05:13.019
This arbitrary number ended up being beneficial because it meant we had time to experiment and try things out. Oftentimes, we would download the code locally, open up IRB, try out the methods, and see how things worked—making it an interactive experience. Additionally, having manageable lines of code allowed us to research topics on methods or libraries we didn’t recognize. We discovered that the real value of the exercise was not just the reading of the code, but the digressions we took during our sessions. I used to think that meetings needed agendas and we had to get through them quickly, but I began to appreciate these distractions.
00:05:54.600
We realized that everyone had to participate to make this a team effort. As we moved forward, we decided to switch the role of tour guide each week. The tour guide isn't the expert—just the person ensuring that everyone is on track and happy. They check in with individuals who seem quiet, like Dan, and ask if he understands and if he has any questions. The first few weeks were awesome, but eventually, we ran out of exemplary code. Hence, we had to read some bad code out of necessity.
00:06:47.760
One day, Dan said, 'This method sucks! How would we write it?' This question opened up our interaction with the code base and allowed us to step into the developer's shoes. We began to ask crucial questions: What's the intent of this method? Why was it written this way? How does it fit into the larger design of the code base? This moment taught us that it doesn't have to be exemplary to be good. Bad code can be enlightening to learn from. When reading bad code, we give ourselves permission to critique it. It's intimidating to critique code written by a renowned developer, but if it’s written by a peer, we can engage with it on a different level.
00:08:22.440
We threw out our initial plan of reading exemplary code! Everything was great again until one day when we were reading some code involving Rack. Dan said, 'Guys, I don't think I really understand how Rack middleware works,' and we thought, 'No problem, we’ll explain it to you!' But then we realized we didn’t understand it either. Dan's question exposed a knowledge gap, so the next week, instead of reading code, we decided to do research on Rack and shared videos and blog posts with each other, allowing our group to learn together.
00:09:06.900
Everything went well for some time, until we encountered the Omnios Meetup gem, which I used for work on a project. The documentation was okay, but I wanted to understand how it worked and what it did. So, I suggested we read through it together. This significantly changed the experience for me because I had a relevant code base I was excited about since it applied to my job. From that point on, we sought out code bases that related to our work and projects—found ones about topics we were passionate about. This shift made our sessions much more engaging.
00:10:02.160
Throughout this journey, we developed a set of guidelines. It was crucial to pick a manageable code base; for us, that was about 100 lines of code, but for you, it could be something bigger or smaller. The learning occurs during the digressions—conversations to embrace, not run away from. It’s a group effort, and it's crucial that everyone feels included, even the quieter individuals. I will not let anyone lurk in my Code Club! Additionally, having rotating roles for a tour guide is important. Interacting with the code is an integral part of the learning process, and it doesn't necessarily have to be good; bad code can serve as a fantastic learning opportunity.
00:10:49.500
Finding relevant code bases can significantly enhance the experience. So we practiced this for a while when I decided to switch things up. I didn’t just want to read code—I also wanted to learn with people I didn’t know. Back when I first started coding, it was a tiring and lonely experience. It was 12 hours of just me and the computer, and the computer is always right. However, once I got to boot camp, I finally had friends—a community of people who understood exactly what I was going through. They celebrated victories with me when things worked and empathized when they didn’t. That sense of community changed everything.
00:11:36.240
But that experience came at a significant cost for me—$11,000 and several months without a salary. I didn’t like that you had to pay this amount to find your community, so I started a Twitter chat called #CodeNewbie. Does anyone know what that is? Show of hands! Okay, let me tell you about it. A Twitter chat is when you pick a hashtag—in our case, #CodeNewbie—and set a specific time, which for us is 9 P.M. Eastern Time on Wednesday. I tweet out questions, such as 'What are you learning this week?' or 'What are you stuck on?' It became an excuse for people to converse, and I thought I’d do it for a couple of weeks, but today marks our two-year anniversary.
00:12:39.480
We’ve completed over a hundred Twitter chats at this point. What I've gained from this? An incredibly inclusive and welcoming community of people all over the world, learning to code and passionately helping each other. We expanded beyond just a chat to an online forum, which has almost 3,000 members now, along with a weekly podcast totaling 74 episodes, and a couple of in-person meetups. But I wanted to do something more that would directly impact people's learning. So, I wondered what would happen if I merged Code Club and #CodeNewbie.
00:13:43.560
What if we didn’t just read code but also explored blog posts, tutorials, videos, and chapters from books? We could use various resources to learn! I developed a project online where anyone could kick off a session—that is, anyone could start a one-hour online meeting with a specific activity and goal. In a matter of months, we held over 50 Code Club sessions. I was now on the outside, unsure if they were effective or if people were actually learning. I conducted many customer interviews, talking to nearly every single person who had participated in these sessions to find out what they thought.
00:14:39.240
From those interviews, I gathered several takeaways. First, having a manageable activity is crucial. About half the groups completed their activities, while the others didn’t quite finish. Those who completed their tasks felt fulfilled and excited, while those who didn’t complete theirs felt less so. Second, calling people out effectively engaged participants. I would send an email to session leaders reminding them to engage people and pull the quieter members in. Surprisingly, many participants appreciated this approach as it encouraged them to speak up instead of sitting back and observing.
00:15:12.960
The most interesting takeaway was that broken activities turned out to be an excellent learning experience. Many of the activities we tried had missing links or outdated steps, which initially worried me. However, it forced members to fill in these gaps on their own. They learned to find those broken links and fix them, making them more active participants in their own learning process.
00:15:56.640
These lessons were familiar: having manageable activities was similar to our earlier guidelines about codebases, highlighting the significance of having a tour guide while being part of a team. Overall, interacting with the code is a crucial element of learning, and even broken activities can work. However, I found the role of the tour guide posed a significant problem. When I asked if survivors of the sessions would consider starting their own, almost everyone said no; they were afraid of being seen as the expert.
00:16:33.560
To address this, we tried a different format. I chose a consistent tour guide who showed up weekly. Anyone could join or drop in whenever they wanted. We implemented this model across various languages: Ruby, JavaScript, Python, AI, and even Clojure for our most recent session. We had online sections led by tour guides whom I had selected. They were community-oriented and skilled at drawing people in, leading two-hour sessions weekly.
00:16:55.040
This model entailed notable differences. There was unpredictability in attendance, with some sessions having many participants while others drew just one or two. Additionally, each of these Code Clubs undertook long-term projects. Rather than one-off hour-long activities, they focused on a single codebase over time, meeting each week to review pull requests, debug, and tackle features.
00:17:35.640
We practiced Code Club in three different formats: one with my small developer circle meeting weekly, another where any user could start or join a session, and lastly, one led by a tour guide with drop-in access. Despite these variations, the eight guidelines I outlined previously persisted in their importance.
00:18:09.840
What I learned is that these rules apply regardless of the format. The guidelines serve a greater purpose for social learning—anytime we unite to learn from each other, following these rules enhances the experience, aiding all of us in our journey. When we speak about Code Club and the work at Code Newbie, people often equate it with education. They think, 'Oh, you’re in edtech.' But it’s beyond that; we aren’t solving an education problem or even a tech one—we're addressing an age-old human issue: the fear of being alone.
00:18:40.680
I’m sure all of you have felt this fear during your coding journeys, where you look up at this mountain and doubt your ability to conquer it. You've seen others succeed in reaching the summit; you’ve watched their videos, read their books, and used their code, but you still doubt your own capability. These demons of doubt can stem from various backgrounds and experiences, but regardless, they loom large, and often, having someone to accompany you would make all the difference.
00:19:38.760
I’m grateful for the many incredible people who have supported me along the way—many of whom are in this room, who cared enough to lend a hand and recognized my passion for coding and community. I hope you all do the same for the aspiring coders climbing behind you. Thank you!
