Welcome back to the Pibytes podcast. This is Bob Adebos, and this week with me, I have Blaise Pabon, and we're going to talk about code reading clubs. So that's a known thing. It's very useful to practice the skill of code reading. Blaise has been partaking in a group doing that for multiple sessions, learning a lot, and he brought it to the PDM code clinic this week, which was awesome. So we were going to talk about that experience, how this really helps you in your programmer journey, and I hope this chat will inspire you to partake in one of those because they are really useful. Enjoy the conversation. Hello, and welcome to the Pibytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldeboz. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Welcome back, Blaze. Good to see you again. We're going to talk today about code reading club. Yes, indeed. Code reading. Nice. And do you want to tell us what it is? Yeah, absolutely. I'd be happy to. I'm becoming a little bit of a code reading club evangelist since I discovered it about a year ago. I was invited to it by Lisa Crispin, who's a well known agile testing author and also a collaborator of mine. And she let me into this kind of exclusive members only, invite only type club, which I felt very privileged by. And it's a wonderful group of people, and they practice something called code reading, which is inspired by some cognitive science research that a professor in the Netherlands does called Felina Hermans, and she's written a book or two about the subject. The club itself is meant to be almost like a 19th century salon where people get together and they discuss the more aesthetic aspects of code, of writing code. And so, in many respects, it's an approach similar to what people might do with literature. You might remember having studied literature in high school or possibly even university, where you do exercises like make a list of the characters, figure out whether the title is literal or concrete, try to describe when it took place, whether the setting is fiction or nonfiction. If it's poetry, then you might want to look at the meter, the way that it rhymes, the way that they might use metaphors similar to what we use as variables. In a sense, variables are really just metaphors, placeholders for other things. So it's that sort of exercise. And I like to remind people that it's not a code review. To the casual observer, it might look like a code review, but in fact the activity itself is very different. And in last week's exercise, Ice and I deliberately chose a language that was not familiar to the audience so that people would not, so that it would be more difficult for people to slip into the code review habit. And how is it different? Well, code review in general is much more about the purpose of the code and how to improve it, or at the very least, how to find potential problems with it. Whereas in code review club, that way of thinking is taken off the table. This is more about a learning experience, how to read code, how to understand the syntax. Yes, in a way it's almost more like, it's almost a way of helping people to put words around the impact that the code has on them as readers. And so that's where last week's exercise we started with some of the very cut and dried concrete questions, where the variables were, the methods, et cetera. Club sessions that I've attended have been a little bit more qualitative or aesthetic, where we might want to look for evidence of the writer's intention, or possibly what the writer might have been trying to accomplish or what constraints they might have been up against. So those exercises are also very interesting, and I'm looking forward to being able to do those as well, particularly when we get into python, where people have the elements of the language, the concrete elements of the language already mastered. And so it's going to be easier then to, for example, in our group, Pibyte's group, to have opinions or speculations about the intention or the constraints or maybe the time. Right. Some python is very archaic. There are people who still write Python with kind of a two point x accent or a JavaScript accent, so we could get into that sort of archaic python, the way some people might study old French or Latin. Right. So how do you come up with a good example to use? Because we distinguish between language we're not familiar with, then it's an extra challenge to get up to speed with syntax you don't know. Then. On the other hand, if you use Python or something familiar, you run the risk of going more into code reviewing mode because you already know the syntax. This Tuesday you came up with a great one on rust, and it was more like a rest API. So a couple of rest calls to get objects, delete objects, put objects. So that was pretty doable. Yeah. How do you, I mean, if you lead the session, how do you come up with a good example? What's your criteria and maybe also, what is your. A quick summary of the structure, because you did a very good job at going step by step, layer by layer, almost. And that was really useful for the people in PDM. Yeah. So thank you. And I have to acknowledge that the code reading club, we don't really have a name for it other than code reading club, but the group that I meet with once a month, it's based in Europe. Those guys already had about a year or so of practice organizing the exercises. And so I'm standing on the shoulder of giants when it comes to summarizing the sequence and the steps of each of the exercises. They've done a great job of structuring that so that it's very coherent. And also my colleague Hais Amos, who's also Pibytes coach. Yeah, we just boarded him as a coach. That's great. That's really wonderful. Yeah, that's really great news. He suggested that particular code example in Rust. I was going to use one in Haskell, which was even more exotic, and then we decided that rust would be both appealing to the audience because it's kind of become fashionable. Haskell might be a bit too esoteric, and also the syntax of Haskell is a little bit more ceremony, and it would potentially be a distraction. So I'm glad that we went with that rust example instead. So the moderator, who is essentially the person who does the planning, selects the code sample and pretty much keeps time during the session. The moderator is free to choose any sample they like, using whatever criteria they feel is appropriate. In general, samples will be somewhere between 100 to 200 lines of code, and in general, they will be within a single file. Having said that, I recently came upon a good example, which is in fact a fast API project. It's a very minimal and at the same time, useful fast API project, where the code is distributed across five or six files, and we haven't done that before, so I'm going to give that a shot at our next meeting. One of the dimensions that is explored and taken into consideration is the dimension of working memory or cognitive load. So this particular project has the peculiarity of being spread across multiple files, but each file is very, very terse and dedicated exclusively to one particular objective. So I'm interested to see what responses people have in terms of whether it's more or less cognitive load dividing the code that way. And also, interestingly so, the example fitted on four pages, more or less. And you recommended to print them and use three colors, right? Yes, one of the exercises uses three colors and there's a difference. There are differing opinions on whether to print it on paper or to use an online annotation tool, and we've experimented with both, and they both have their pros and cons. The original exercise called for the physical experience of working with the paper and drawing on top of the code, using different colors to represent either variables or functions or classes, for instance, and then draw lines between their definitions and their instantiations. I don't know that there's necessarily any consensus on which way, whether there is in fact a way that's somehow better or worse, but I did think that it would be good to include that physical exercise as part of the very initial experience with code reading club. Again, to reiterate that it's much more of a full body sensory experience with the code rather than this abstract utilitarian analysis. Cool. And what about the group dynamic? I definitely found it a memorable experience and it was very interesting how you learn so much from each other. Like everybody had different insights and it was really enriching. So what do you feel about the group dynamic of this exercise? Yes, in fact, the group dynamic is maybe the best kept secret in the sense that it's really all about creating an environment where people feel free to face or even admit the places where they might have trouble or where they might not be confident and at the same time feel comfortable. In just twelve weeks, pyrites elevates you from Python coder to confident developer, build real world applications, enhance your portfolio, earn a professional certification showcasing tangible skills, and unlock career opportunities you might not even imagine right now. Apply now at Pibit ES PDM stating an opinion even in the presence of peers who might have a great deal more experience. And so there are some tricks that are built into the process to help make that happen. One of the tricks is that in general we do not record code reading club sessions. We made an exception last week because it was more of a demonstration, but part of the increasing psychological safety is to not record the sessions. The other part is to have a relatively stable membership if people are used to seeing the same faces and there is some consistency with attendance. Obviously we don't punish people if they can't attend, but everyone understands that the more consistent you are with attendance, the more rewarding the sessions will be for everyone. Somewhat stable membership absence of recording consistent participation, meaning people show up on time and to help the in fact, in our club we tend to spend about the first 25 to 30 minutes doing introductions, which is both a way for people to get warmed up to the idea and also a way of smoothing out any late arrivals so that by the time we're ready to begin the work, the actual collaboration, the likelihood is that everyone has already been in the room and we're not going to be interrupted by latecomers. Awesome. And people not to read the code before. Right. They should come in. Yeah, that's tricky because the code is typically handed out the day before and it's very tempting to look at it. And eventually I think it becomes easier to ignore the code until the session starts because you become more familiar with that delicious surprise. It's almost like Christmas Day. You open up a present or birthday and it's waiting for you. You know it's there, you know, it's obviously a big package wrapped up with a bow, but you're not quite sure what's inside. So we encourage people to not look too closely at the coat until the first exercise. And the first exercise is in almost all the formats that I've seen. The first exercise is that initial impression. What are the first two or three things that come to mind when you, in the first 60 seconds of looking at the code? Yeah, you would spoil it. And I think it's also good to do as you say that it's your first impression. And if you're forced to say something about the code in the first five minutes when you do that first exercise of a quick overview. Yeah. Then it wouldn't be fair if you then already would have looked an hour at it. And it's good to time box that also as a training tool to become better at quickly looking at code and get an idea of what it's about. Because if you join a big legacy project of 50 developers and tens of thousands of lines of code, you will have to learn to read code and get a sense of what's doing pretty quickly. Right. So that could be one takeaway of this. Right, I definitely saw that. But you have done a couple of those now or many sessions even. You now go to any code base. And how do you feel you have improved your code reading skills through this exercise? Do you see tangible benefits, how you can now have that transferred over to your work? Yeah, certainly. So, for instance, one. Oh, one trick that seems obvious in hindsight is to begin at the end. In other words, particularly in Python, where we often have like the main loop, if you will, is almost the very end of the code. And we often start with things that are fairly utility and almost housekeeping helper functions and things like that. And I was surprised that it wasn't until I think, probably the fourth or fifth session when I suddenly realized that that's what a particular person was doing. And it's made so much sense. The other thing that I noticed is to look at the look for things like comments and kind of metadata, because that often gives me a sense of where, or I should say, how much work is in that code versus how much work might be happening elsewhere. And it often gives me a quick sense of whether I'm looking at something that's a small piece of a big project or possibly a big piece of smaller project. The comments are curious because I can often tell, like, how, whether or not the code is meant to be read by someone else. Sometimes you can see comments that are either inconsistent or they haven't really. They almost sound like somebody mumbling to themselves under their breath. And so that can often give me a sense of what I might be up against in terms of how polished that code might be or how amenable it might be to being read. Yeah. And just to be clear, you take the raw file, right? You're not adding any comments manually for the sake of the session, right. You take the. Yeah, we do. The exact code and you don't touch it, right? Yeah, I certainly haven't, nor have I heard anyone suggest any kind of modification that might be recommended. So generally we'll take it. In some cases, there are pieces. Most of this code is public domain. In a handful of cases, it has not been public domain. It has been code that someone might have brought in from an old project at work, for instance, or some legacy COBOL project, for instance, that they've had contact with, for whatever reason. Many of those samples start off with a very lengthy copyright notice. And so in some cases, the first page, or at least three quarters of it, are covered with legalese and boilerplate. That has nothing to do with code, and that creates its own sense of intimidating experience. But I've not heard. I mean, even though it would have been easy to justify removing that, I think that in general, the idea is to try to experience code as it exists in the wild. Yeah, indeed. Cool. Fascinating. I think that gives a good overview why the code reading club is so useful. I definitely experienced that as well. Other things you want to share around the topic that I didn't ask you? Well, I would say that the thing that you didn't ask, which may be obvious, is that code reading club is really intended to be accessible to everyone. In other words, if there is a club that you've heard about, but you need an invitation to join, for instance. It's not because people are trying to be exclusive, it's because they're trying to create a certain sense of stability for the people who are in that club. And I encourage you to start one. I mean, if anyone has an interest in code reading and they don't have access to a club for whatever reason, they can certainly drop into the pilots forum, for instance, or, you know, approach me through any one of the other places that I hang out in, and I'm happy to help. There is a discord that sees a little bit of activity that's run by the original code reading club members. And every now and then people will show up and offer or inquire about the availability of a code reading club in their time zone. And I say time zone because these. Maybe it's a Covid thing or not, but these clubs tend to meet online. I've never been to one face to face. So, yeah, if there isn't one that's readily available to you and you'd like to start one, and if you don't know where to turn, I'm happy to answer questions, but I think the idea is that please don't feel like you have to belong to an official one before you can participate. Yeah, and I think all levels can learn, right? Like beginners, more advanced people. And that's the beauty of it, right? Beginners will learn from the advanced people. The advanced people might see things they didn't even think about. All levels are going to benefit. Exactly. When this comes out, we definitely can do a post in our circle community to drum up interest for this. Also, practically, what's the minimum amount of people and maybe also the maximum, what you would recommend for this. So that in our experience, and this may be a function of how much time we have, we set aside 2 hours a week, excuse me, 2 hours a month. So our club meets monthly and we do a two hour session. However, most of that, the first half an hour or so as introductions. So one could argue that the sessions, the meetings are 90 minutes. And so what you want to try to do is budget enough time so that you can do the exercise and have the relevant group discussions take place within about five minutes or so less than the time available. That way you have a bit of time for retrospectives and I. And wrapping up, we have three or fewer. We don't tend to have a session that's happened a couple of times. The best groups seem to be between five and eight, where I think one could easily do a group of ten, taking into consideration time constraints. And then, and I think one certainly wants at least four, because typically the moderator will already be familiar with the code example. And so you'd want to have at least three people beyond the moderator. Yeah. And if you go over ten, you do want to give everybody an opportunity to chime in on every exercise. So then it just becomes too dense, right? I think so then it becomes an exercise for the moderator in making sure that people have an opportunity to speak. So, for example, if you are pressed for time and you have a big group, another moderator trick is to, rather than go through the entire roll call asking for comments, you might select people and then have a few rotations where you try to begin with people who either have not made a comment before in the session or who might otherwise be overlooked because they're new or because they're young, whatever. Perfect. Awesome. This is really helpful. And again, I found it a very interesting exercise. And devilian Hermans, this all comes from her book, the programmers Brain. Right? The programmers brain, yes. AJ is also here on the podcast, I think, episode 84. Oh, that's right. About the book as well. Yeah. So we can also, so we can link that and a couple of more resources. But, yeah, thanks for hopping on and tell us about it. I think it's a great tool and, yeah, also a nice way to get into touch with more programmers and as a community effort. So, yeah, by all means. Awesome. Oh, thanks, Blaze. Thank you for, see you here again for some other topics, for sure. Thank you. Cheers. Take care. Bye bye. We hope you enjoyed this episode. To hear more from us, go to Pibyte friends, that is Pibit es friends, and receive a free gift just for being a friend of the show. And to join our thriving community of python programmers, go to PI Bytes community. That's Pibit es forward slash community. We hope to see you there and catch you in the next episode.