 When we think of working with code, most of the time we'll first think about the act of writing code. The reading and interpreting of code is equally important but rarely discussed. Luckily, we have Jessica Rose here today to break it down for us. By framing code bases as living texts, Jessica will explore the value of reexamining the twin skills of reading and understanding code bases. She will teach us how to apply linguistics and literacy concepts with software-specific tools and approaches to provide you with new ways to conceptualize how to read code. Enjoy. Hi, and thank you so much for having me. I'm really delighted to be coming to you all from, well, my home studio, which is a much, much shorter commute than I usually get. And hopefully, I'm speaking to all of you in a very, very comfortable space where you're based at the moment. And I'm going to be talking to you all today about code literacy, and that sounds very fancy and very highfalutin, but really what I'm excited to be talking to you all today is the value of really reading code, what we might get if we slowed down and read some more. And I'm going to cheat and give you some of my favorite concepts from linguistics and my favorite reading concepts from really basic literacy. And see if we can't have a little bit of a discussion about what we can learn together from these. So, hi to start things off, if we haven't met yet. My name is Jessica Rose. I'm the head of developer relations, the head of outreach really at Coatsy. And I did sort of add a spoiler right from the start, which is this talk is really, hopefully a conversation. So, I'm going to give you a couple of concepts that I think are really solid and say, oh, I think you can apply these right away. But my favorite concept from linguistics, and that's going to give you an idea of exactly how nerdy this talk is, my favorite concept from linguistics and reading. I'm afraid it's a bit open-ended. I haven't found a fantastic way to apply this to code yet. So, what I'm really asking, and that's terribly presumptuous, is if you have an idea, or if this inspires you and you test this out, come back and tell me. So, chat to me about it in the question and answer session if you're watching this live or come fuss at me on the internet if you're watching this in the far future. So, this talk got written. I began writing this talk. I began thinking about this talk because of the work I do over at Code See. At Code See, we build developer tools that are really focused around helping developers better read and better understand and better communicate around complex code bases. And you might be shocked that this gives me a ton of time to think about, oh, hey, as we build tooling for how to read code bases, how do we read code bases? Are we doing it well? Are we doing it enough? That's very presumptuous. Again, are we doing enough reading of code as we're immersed in code daily? And I confess I got really lucky. This rule is a perfect fit for me. Hey, Jess, do you want to sit in a comfortable room with smart people virtually connected to you and talk about reading and talk about learning and talk about code? Yeah. But before I did this and before I started thinking about reading and code, I confess I was in a slightly more stressful role. Before I moved in technology, I was a teacher, which as illustrated here, very calming, very relaxing. It's very meditative process. So, I've got some reasonably opinionated takes as teachers do. Some teacher takes around reading and understanding and how we should communicate our learnings or how we could communicate our learnings. I was a languages and linguistics teacher. So, you're going to see a lot of that during this talk. One of the first things I started thinking about is how we talk about and how we approach our work. And I confess that I was surprised when I sat down and began thinking about it. I was surprised to realize how active all of our language around programming is. We're programmers. We do the programming. We're not readers. We're not imbibing. We're not passively taking this in. We're not observers. That most of the way we talk about code and look at code and really interact with code professionally is hyper fixated around active skills, sort of hands-on keyboard skills. We want to and we're often expected to professionally fix that bug or write that feature or ship this thing right now. And some of this expectation, some of this pressure, if that's not a bit bold, I think comes from the economics behind it. Relative to some other kinds of labor, developer times reasonably expensive. But I think it might be a bit more than that. I think that culturally within technology, we have this idea of ourselves as builders, as active, as people who do have our hands on the keyboards. When we talk about open source, we have the idea of maintainers. And this feels like a really interesting transition. So these are folks who are, they're writing code, but also they're doing a lot of reading. They're doing a lot of considering and they're doing a lot of planning. And I think the concept of maintainers gives us a really great sort of walkway into and it saying a more passive way to encounter code sounds terrible, but we're going to talk about passive skills in just a minute. It's more important than it sounds. As a book nerd, I'd love to come here and say, hey, I want to sell you all. And as a former teacher, I'm a little bit tempted to just try and assign you, just try and make you say, oh, hey, you've all showed up to my class today, my talk today. Your homework is that you must, but you're adults. I mean, I can't make you do much of anything. And me saying, oh, conceptually, I love the idea of people slowing down and reading code more. That doesn't do you much good either. Like, your boss doesn't care what I conceptually think. And as a busy adult, I don't think that you care that I think reading is cool. And I want you to read more. Let's, let's step into something a bit more practical. My key argument behind this talk and one which I confess that you're going to have to hear me make several times is that reading, and I'm going to go a step further and say the type of intentional reading or the types of intentional reading that we're going to be looking at together, deep and intentional reading is necessary to build great things that these passive skills around reading and the passive absorption of code through reading is necessary to produce great code. As adults, I'm not going to tell you what to do. And I doubt very much. I mean, developers, you get, we get, you get. I don't know which perspective I've got here from the stage. As developers, one, hey, as developers, we get things sort of sold to us all the time. Try this tool, try this technique, try this new thing. And I don't think I really want to sell you much of anything. I want to present you my favorite approaches and see whether or not these feel like they might be a good fit. Oh, that's a soft sell, isn't it? That's still a sell. And you might say, Jess, Jess, Jess, that's cool. We're on a first name basis. Yeah, I'm fine with Jess. You might say, Jess, you've been talking to me about five, for about five minutes about reading, and that's cool. But I already know how to read code. So what's going on here? And I say, Hey, first name, because we're best friends now, I totally know your first name. I'm just not saying your specific first name so the rest of the audience doesn't feel bad. So, Hey, first name, I know you can read. And I know you can read code. If as a programmer, you've been doing this successfully for before you've been writing it, I know and understand and trust that you're writing code, reading code comfortably. But I want to look at approaches for these that might let you read code. More mindfully sounds very fancy, but more intentionally, which I think might be the very same thing. I promised to talk to you about passive and active skills. And I want to take you way back in time to do that. These are the skills, the four core language skills that you first learned when you learned your first human language. I know some of you are brilliant and speak two or three or dazzlingly more human languages. And you'll see this pattern repeat itself across your new languages. But when you first learn your first language. So for me, when I first learned English, these are the order in which we learn these skills, we listen, we absorb, we passively, hey, passive language skills, we passively take in language before we produce it before we speak it. That checks out. And that we're reading, we're identifying letters and we're identifying short words before producing them through writing. And what's really important here is that generally speaking, your passive skill is much more, much better developed than your active skill. And you might say, well, you know, my first language, my home language, my mother tongue, I think I speak it just as well as I listen. Or you might even say, Hey, you know what, I'm not a great listener. And yeah, of course, but I'm talking about linguistic progression. So if all of us start learning French tomorrow, you're going to be better at listening to French and understanding it than you are producing this new language. That checks out. And the same for reading. What I really want to flag is that you always use your passive skill as a base that really the foundation you build through your passive skill. Oh, wow, I'm excellent at listening to French. My French comprehension is quite good. That gives that's a lie. My French is terrible. That gives me a larger foundation, a larger base to work on my active linked skills, my speaking skills. So keep these skills in mind, we're going to come back to them at the end of the talk. But I want to talk you through my three different linguistics guided approaches to reading. Delightfully nerdy, hopefully delightfully. The first one I want to talk to you about is a lot. It is intensive reading, just like intensive reading sounds. Intensive reading is intense. Intensive reading is an approach from linguistics. And this is going to be very controversial. If any of you are linguistics nerds or literature nerds, I'm going to say the act of intensive reading is going to feel similar to close reading in literary criticism. It's not the same thing. There's not really the same purposes. But stick with me for a second. This is when you take a piece of text or a piece of code, as we'll reveal in a moment, and we're going to deeply focus on that. So close reading is when you're like, I'm going to divine the meaning of each of these words and each of these sections and really sort of dive into what I think the writer was trying to tell me. Whereas in linguistics, the approach might be, I'm going to deeply focus on the short section of text because I have something to do. And you almost always have a set task for intensive reading. So intensive reading from back when you were in school might be read this essay and answer these four questions or read this paragraph and circle all the nouns. These are going to be intensive reading tasks that might be familiar from sort of when you were much younger in school. When we're talking about extensive reading in code, intensive reading code, we've got ready examples here. I think that if you're looking to find a bug in a section of code and you're just really going through it, you're really going to get that feels like intensive reading. You are intensively reading that code to find out what exactly is wrong with it. I think similarly, if I was going to say if you're me, but if you're a bit like me, you sometimes make typos so beautiful and so unexpected that maybe your editor is not going to help you out find them. Hunting for typos in a section is going to feel a lot like intensive reading. And I also think I don't know if any of you have ever encountered a cursed section of code where when you join a team and you join the code base, they say, hey, have a great time. Poke around. By the way, this module over here or this section of code or or this bit over here where it's commented, we don't touch that because it's cursed. Every time someone changes part of this, everything breaks. So don't touch it. Of course, as soon as someone tells you not to touch a curse section of code, I mean, you got to touch it, right? But the fretting you do over that, the reading it, the sort of staring intensely at it to try and find its secrets is usually paired with a bit of touching the code. Oh, I'll try this. Oh, it all did break. I'm going to revert that. But that kind of fretting over haunted pieces of code feels a lot like intensive reading to me. Much like cursed pieces of code, intensive reading, both in linguistics and code is famously, I mean, it's intense. Intensive reading isn't joyous for most of us. If you're peering deeply into a paragraph of prose or a six line segment of your code, it's not going to feel fun. I mean, if you are the type of person that this feels fun for, come and see me after class. I demand to know your secrets. But for most of us, this is work. And it's hard work. And intensive reading is generally something we assume that learners can only happily do or effectively do for short bursts of time. Intensive reading is common, I think amongst code, but it is intense. Let me give you a real life example of an intensive reading activity I was given relatively recently. So this is from the code reading.org website. And if you are even faintly curious, feel like, oh, wow, all right, go there. I mean, not right now. Finish the talks. The talk after me is fantastic. You're gonna love it. Oh, gosh, I hear the talk before me was really good as well. I'm just, yep. So finish the conference talks you're interested in first, and then head over to code reading.org. And they're trying to answer the same question I've been working on, which is, hey, if we change how we read code, if we change how we approach it, how does that change our understanding? And how does that change our learning? So this is a piece of code that they gave out, they run a meetup series where anybody can go and get their curriculum and run their own internal meetup, if you're doing it at work, or external, if it's community facing, about code reading. And they've got the curriculum all set. I believe it's an eight meetup series. But they went ahead and gave us this as a sample and said, hey, Jess, because they're also on a first name basis with me. Here's some code from open whisper systems. And these are the people who make signal the secure messenger. And first, they said, Jess, could you go through and could you tell me what are the most important lines of code here? I said, okay. Well, I think it's where we're talking about validated phone country codes, because I think that this code is validating phone country codes. I think that's the main purpose of this. And I also think it's 15, because here I'm seeing that the phone number validator, which sounds very important, is being sort of set here. And I said, okay, Jess, can you go ahead and circle? If this code was a piece of right, can you circle what you think the main characters are? And I'm like, yeah. And phone number validator seems like our dashing hero. And is valid for registration, that seems terribly important for seeing if a phone number is valid. I think these are important as well. And really, this is a great example of here are some language tasks applied to code and in an intensive reading fashion. Intensive reading is a lot. Let's do something that feels a little easier on the brain. Skimming and scanning. So skimming and scanning are similar, little different in practice. But there when you've got a big piece of text, and these are going to be concepts that you learned maybe in elementary school, or maybe when you were younger, where you've been given a big blob of text and you need to quickly, maybe because it's the last thing on your test and you spent a lot of time on the multiple choice, but you need to go through this piece of text and get the basic understanding. You're going to quickly look over large sections of text or maybe the whole text and really what you're looking for is a general understanding. You might not and you probably shouldn't for skimming and scanning. You're probably not going to read every word. You're just going to sort of cast your eye over it and see, hey, where are these things I'm looking for? Or what's the main idea here? If we're thinking about this in the context of a code base, I think we've still got some relatively ready examples here. If you've just been given a new code base and you're taking your first look at what's going on, I think you're going to skim this. And hey, do you know what? If you're looking for a specific function or a module or a section of code, you're just going to scan and look for that. Unlike intensive reading, which is intense, skimming and scanning tend to be pretty friendly for our brains. We can happily and we can readily skimp not all day. Don't do it eight hours a day. It'll be miserable, but we can put our eyes over this pretty quickly and pretty happily. And this is the fun one. This is my favorite linguistic concept from code, extensive reading. Extensive reading is a concept from linguistics that's relatively new, which means, you know, a couple of decades old. And here you're going to read a lot, but you're not going to focus on the details. Skimming and scanning, you just put your eyes over it. Here you are going to read every word. But if you don't know a word, that's fine. We think you're going to get most of the gist. Most of your learning is going to come from the context. If you don't understand a word or you don't understand a function or a module, just keep going. It's mostly about good vibes. You know, if Crash never hears that, I don't think the gentleman who invented extensive reading or helped pioneer it, I don't think he'd like his work summed up as it's reading but vibes. But really the core focus here is on enjoyment. With extensive reading, you want to pick texts that are at your understanding level, or just a tiny bit higher. And when you're doing reading for language learning, it's reading stuff that you enjoy. So not, I'm going to sit down and read the encyclopedias don't exist anymore. I'm not going to sit down and read Wikipedia. Nice. I'm going to sit down and read some comics. I'm going to read some things I genuinely like. And the challenge behind this is, and the reason I'm giving this talk to you today is examples from code where you read a lot of code. You don't stop to puzzle things out. You just read it for fun. I couldn't think of a single one of these. I've been trying to apply extensive reading for a while. So I wanted to really set this talk up so that I could politely beg other people to tell me, hey, have you ever thought of something or have you ever done something or is there an exercise where it felt like extensive reading but with code? And this is because I think that this is sort of the holy grail, that if we can find ways to just chill and read code, maybe through a learning application, maybe through a scaffolding approach, but if we could find a way to just chill and read code for fun or in relatively enjoyable ways, I think that this would unlock the ability to learn about code in a really similar way to the way extensive reading unlocks our ability to learn languages really, really happily and really well. And we've got a couple different approaches for social interaction with code and social interaction with reading. And I wonder if this isn't the place that our future beautifully modeled extensive reading of code might live. Within programming, we've got the idea of hackathons. And if you've never heard of them, they're, I mean, back before the world was canceled, they were often in person, they're online now, don't go anywhere, don't leave your house. And where you get together and you write a bunch of code, usually around a set problem or project. And these tend to be, yeah, they tend to be Greenfield projects. There's not a big code base that exists usually. So the code you're writing doesn't tend to have a lot of reading. These are a good example of social interaction around writing. But to look at reading, we've got to jump over to literature and say, well, we've got established models here. Reading clubs, reading circles, study groups have existed far longer than any of us. And I confess far longer than computers. What would it look like with social reading and social extensive reading of code? Would it look something like a hackathon? Would it look something like a reading circle? And excitingly, the good people at codereading.org who I've already got given a little plug to, they're not focused on extensive reading the way I am. They're different kinds of nerds. But they're looking at what does it mean to socially engage with reading code? And I think if anybody's going to crack this, and it's not you, my dear conference attendee, coming to get this for us and solve extensive reading and programming, I think these folks might do it before I do. And I'm really excited about this. And I'm really focused on this because I genuinely believe that if we improve the way we read code as individuals, so if I personally or if you personally or if one personally, to take the pressure off, gets better at reading code, we're going to get better at understanding and conceptualizing code. And that's going to let us bring better understanding back into our projects and back into our teams. We talked about these four core language fields that listening leads to better speaking and better reading leads to better writing. What would this look like broken down for code? I mean, these are these are work in progress. These feel choppy. I'm going to say, well, you know what, I think the first thing you need to do the first passive skill to lay down this foundation is reading code. And to talk about reading code, that's not a surprise. And I think, well, you know what, I think the active skill that builds on that is writing code. And we're not done here. Like communicating around code is more than that. I'd go ahead and argue that passive non code communication. So when you're reading about a programming technique, or you're reading about code, or you're reading about architecture, or you're listening to someone talk about, you're listening to a conference talk about, Wolf Metta, if you're listening to a conference talk about reading code, that sounds like passive non code communication. And absorbing that kind of input means that you get better at active non code communication, sharing with your team, writing a blog post yourself, coming and giving a talk here next year. And I think that these are the four linked skills that let us continually improve our understanding around code. And that's the big secret for me. But for me, the big goal isn't, I mean, of course, I want you to do your job. And of course, I want you to fix that bug and ship that module. But what would it look like as an industry and as teams, if continuing continuous understanding was our ultimate end goal, that as an individual, I was aiming to learn and understand as I encountered new things. And I was then in turn looking to actively communicate those back to the team. Hey, I learned this. Hey, I read that. Let's add to our pool of shared understanding. Because I'm a teacher, and I can't make you do any of this. Let's talk homework. I'm not your boss or your teacher. So instead, these are gentle suggestions if you want to try to think intentionally about reading code during your daily work. Just catch yourself reading when you're reading and think about that. You may want to try identify when you're using these different skills. Oh, hey, I'm doing some intensive reading or, oh, hey, I'm just skimming this. I'm just scanning this. You may want to try one of our established reading techniques. If you're really excited, go check out one of the code reading workshops. And if you find the beautiful magical secret for, hey, this is what extensive reading of code looks like, come back and let me know. Give me any kind of feedback you have. On my side, my homework, I'm going to go ahead and continue to research this. I'm going to continue to see if I can read and understand better myself. And hopefully come back to you all when I, or much more likely someone clever, much more clever than me, has cracked the code of what does extensive reading look like in code? In the meantime, I'm going to be hanging out with the Code C team and seeing if we can't bring you a couple of new, hopefully weird, tools around how to read and understand code. If you want to yell at me about what we're building, pop me an email here, but it's pretty low pressure. That's as hard to sell it. I'm going to sell reading far more than getting in touch with me at work. Oh heck, that's twice. But really, thank you so much for joining me and thank you so much for your time. The idea that other folks want to hang out with me as I pontificate about the value of reading absolutely brightens my weird and delightful week. Thank you so much. If you want to do more reading about reading, you're super welcome to check out my sources as well. Oh, especially if you read this, how we acquire vocabulary, like we can go ahead and do a reading group around that. Thank you again.