00:00:16.800
Hello, my name is Saron. Thank you so much for coming to my talk. I'm really excited to be here, and as you can tell from the title of this talk, grammar is very important to me.
00:00:25.160
Before we begin, I want to start off by telling you a story. A year ago today, I was not a programmer. This is a really big confession that I'm sharing with you.
00:00:31.719
A year ago today, I was this chick who worked at tech startups. I did business development, sales, marketing—pretty much all those non-technical roles, and I loved it. If you've ever worked at a tech startup, the best part is telling others that you work at a tech startup because they instantly think you're awesome and cool, which you are.
00:00:45.239
However, I realized over time, after that honeymoon phase was over, that my biggest skill—the best thing I had to offer my company—was being able to talk. That didn’t seem very valuable, and I was always surrounded by programmers, by these tech people who could build beautiful, powerful things.
00:01:02.160
I found myself always creeping on them, looking at what they did, and feeling that what they did was so much cooler and more interesting than anything I could ever do. So, I quit my job, started learning how to code, and got accepted to the Flatiron School, which is a three-month programming boot camp.
00:01:19.360
When I graduated, I was so excited. I could finally build stuff! I could make stuff! I was valuable, and I could be a contributing member to society, as my mother tells me. However, one thing they don’t tell you when you graduate from a programming boot camp is that you have to click your heels and hold up a keyboard to make it official.
00:01:44.600
So, I was so proud; I learned a lot and worked really hard. I was apparently standing on a rock of code stuff that I conquered, but I was also painfully aware of all the other things left to learn. There was stuff that I didn’t know, stuff I didn’t know I didn’t know, and stuff that I thought I knew but forgot, although I didn’t know I had forgotten it yet. That's going to be a nice surprise in the future.
00:02:07.799
And by the way, everything changes all the time. So welcome to programming! I was painfully aware of how much of a novice I was, and this is the novice track. Hopefully, this applies to you too. This actually describes Dreyfus’s model of skill acquisition which states that when you start a new skill, you begin at the novice level and move up over time to advanced beginner, competent, proficient, and hopefully an expert.
00:02:30.599
I don't want to be a novice; I don't think anyone here wants to be a novice. That’s not fun! I want to be an expert, and I want that cape— that's who I want to be! So, I started asking people and did some research on how to become an expert. How do I go from this poor novice who kind of knows what she's doing to that cap-wearing expert?
00:02:52.519
The most popular answer I got was to read code, which is both helpful and not very helpful because that leads to other questions, like what code do I read? How often do I read it? The best way to start an adventure is to start it with friends. These are my friends—some of my programming buddies from Flatiron School.
00:03:16.480
I got them together and said, 'Yo, if you get programming people together to start a code reading club, you have to start the conversation with “Yo,” otherwise it just won’t work.' So I said, 'Yo, we should read code together.' We decided to dedicate one hour every single Sunday at 11:00 a.m. This is a huge deal for me because I don’t wake up before 2 p.m. on a weekend! I was already winning just by declaring that this might happen.
00:03:52.959
So, we made this a regular thing and decided to call it the Code Club because we are creative geniuses. The first question was: what code should we read? We did some research and asked mentors and senior developers the best starting point for a novice to start reading code.
00:04:43.600
They said, 'You should read anything,' but this was not helpful! Please do not answer this way if someone asks you where to start. So, we came up with our own rules. We decided the point of our code reading was to find exemplary code that we thought was inspirational.
00:05:06.600
We defined exemplary as having four attributes: first, it had to be somewhat popular—something well-used and endorsed by the developer community. Second, it should hopefully be well-documented, so if we got stuck, we had somewhere to go. Third, it should be well-written, and fourth, it should be well-maintained.
00:05:38.320
We thought that if we did this and studied our exemplary codes every Sunday, we would go from novice programmers to badass experts. One suggestion I got from a senior person was, 'Why don't you start with Sinatra? You've done Sinatra; you're kind of familiar with it.' So we agreed to start with the GET method, which is something I never really understood.
00:06:12.680
We gathered on Google Hangout and said we're going to get through the GET method in one hour—totally doable! If you've seen the GET method in Sinatra, it’s like seven lines of code, which sounds perfectly doable. No! This is a trick; it’s a huge lie!
00:06:33.360
Every single line is completely abstracted code, and you have to go through all these other files to find out what they're doing. Then they have more abstracted code and you have to go through even more files. It became one rabbit hole after another, and we found we really got nowhere with it, transitioning from being really excited to completely overwhelmed.
00:07:01.840
I'm a big believer in retrospectives; I like to take the opportunity to reflect on what I just did, especially if it's something I'm doing for the very first time. At the end of our first code club session, we paused and asked how was this experience on an individual level? What did we learn, and how can we improve?
00:07:34.800
The idea was to keep this going every week, so what can we do to ensure that next time we learn a ton? The first and most important part about the code reading experience is picking a manageable codebase. It was disappointing and a huge hit to our egos to know we couldn’t even figure out a GET method that started out looking like only seven lines of code.
00:08:08.340
Choosing something that is manageable, digestible, and understandable is incredibly important. This is the first guideline for having your own code club, and definitely the most crucial. So, for us, we decided that 100 lines of code was a great limit.
00:08:29.679
It's a pretty arbitrary number, but it ended up being perfect because in those 100 lines of code, you have just enough to complete a full gem or library. It’s a significant accomplishment to say, 'Hey, I read through this whole thing and finished it,' even if you don’t understand it. You feel good about yourself.
00:09:05.960
Secondly, it gives you the flexibility to stop and comfortably ask questions. If there’s something you haven’t seen before, you can say, 'Hey, can we slow down? I don’t really get this; can someone explain it to me?' And you don’t feel like you’re slowing anyone else down.
00:09:32.360
You also have the opportunity to try things. One of my favorite parts about reading code is finding new methods that I haven’t seen before or maybe ones I hadn’t seen in a long time. Being able to pause the session and say, 'Can we open up IRB and just play with this and see how it works?' was really valuable.
00:09:52.640
The third thing was researching topics. There are always patterns that we’ve seen that look familiar, that we’ve encountered before. Being able to pause and look things up on Stack Overflow or just Google was an excellent opportunity.
00:10:11.440
So with that limited codebase, we were able to do all these things while simultaneously getting through code. This brings me to the second really important part about reading code: it’s not only about reading the code. Reading the code is just the starting point.
00:10:30.360
All those other things I mentioned, the parts where you may get off track and digress and have conversations, matter a lot. The learning happens in those digressions and conversations. I'm very sensitive to getting off track and making sure everything is very focused, but over time, I began to see a lot of value in it.
00:10:53.559
The third thing is that it should be a team effort—do not go at this alone! It will be very painful, and you will not have a good time. Knowing I had other people who were about my same level made it much easier to start this journey and to keep going. It’s important to ensure everyone feels comfortable raising their hand and saying, 'Can we stop here?' or 'Can you say that a different way because it didn’t make sense to me the first time?'
00:11:13.520
It’s essential to have an environment where everyone is comfortable and engaged. We find it very helpful to have a tour guide. Each week, we trade off and have one person lead the conversation. This person just ensures everyone is engaged and excited.
00:11:35.919
We found quickly that finding exemplary code that’s only 100 lines can be very challenging. I think we ran out after a couple of weeks. Out of necessity, we had to lower our standards and say that the most important part is really finishing the code base.
00:12:14.880
We decided we're going to focus on finding any code that’s around 100 lines. This ended up being a great idea! In our first week where we decided to lower our standards, we looked at a method that wasn’t well written, and Dan said, 'This method sucks. How would we write it?'
00:12:39.039
This led to our very first point of interaction, which is the fifth guideline: find opportunities to interact with the code. When Dan asked that question, it led to discussions about what the intent was, what the method was supposed to do, why it was written a certain way, and how it fit into the overall design and architecture of the entire codebase.
00:13:07.160
These questions were valuable because it allowed us to not just read code but to go on an adventure where we pretended to be the developers building the code—connecting our own knowledge with this specific situation.
00:13:22.280
This leads to the sixth point: it doesn't have to be exemplary! Reading bad code is great because as a novice, you get to say, 'This is bad code,' and you can have an opinion on someone else's work. It makes you feel a lot more adequate. So, bad code can be exceptionally instructive.
00:13:43.599
Things were going well until we encountered a gem that discussed Rack Middleware. In that conversation, Dan said, 'Guys, I don’t think I really understand how Rack Middleware works.' We initially thought, 'This is obvious! It’s straightforward,' only to realize that none of us truly understood how it worked.
00:14:08.960
This discovery exposed a knowledge gap—we thought we understood but had forgotten. Instead of our regular code review the following week, we took a break and researched what Rack Middleware was, how it worked, and what to do with it.
00:14:31.480
We watched a few RailsCast videos and checked out some blog posts. The week after, we shared that knowledge together and had a much more informed conversation. This emphasizes that it's not really about reading code; it's about using reading as a launching point for deeper discussions.
00:14:50.740
The sixth thing is that you need to keep at it. I’ve never told my code club this, but I thought it was a bit of a chore at first. It wasn’t that exciting. It was something I felt I had to do. I don't like waking up on Sunday mornings!
00:15:09.440
However, over time, I saw the value— I began looking forward to that first code reading session each week. I felt like I was getting 10 steps closer to being an expert. But the transformation wasn’t as visible and tangible as I had expected.
00:15:35.400
I thought a lot about how, if I can’t feel the change in a tangible way, how do I know I'm becoming an expert? I found a great infographic on Twitter that illustrates the process. Information looks like Skittles: all these little data points that seem isolated but relate by being in the same bucket.
00:15:58.360
Eventually, you connect these dots to form knowledge. Knowledge is telling a story, such as: 'I can start from that yellow Skittle and create a path to the green one, then to the orange, ultimately arriving at the red one.'
00:16:30.640
Thus, wisdom means knowing I don’t need to go through all those Skittles—you can take your own path and even if it’s not straight, it’s still valid. This symbolizes the journey of reading code together, where the information from various code bases helps us forge connections, gaining wisdom incrementally.
00:16:54.840
These connections help us in our work. Whenever I'm using a gem at my job, I can think: 'Hey, I’ve seen this before!' It allows that shared knowledge to form connections that are otherwise difficult to find.
00:17:16.720
Lastly, as we read through the noise of code—patterns, designs, lines of code—the essentials that matter pop out repeatedly. Eventually, we gain wisdom and progress toward being experts.
00:17:41.679
Here are some code bases we've read. If you're interested, many are about 100 lines long. Take a look, and I’d love to hear your stories, too. My website, blogytunes.com, has a page with links to these gems and more.
00:19:09.120
That’s my handle, where I mostly tweet about programming and cake—you’ve been warned! So, that’s pretty much it. Any questions?
