First time I came across annotated source code through the underscore J's codebase, it'll be not just the code, not just a code with comments, but pretty much line by line or method by method breakdowns of what's going on, kind of the thought process behind everything. And I think rather than just understanding what the code does, seeing a lot more of that intent behind it, really just, again, it gives your brain something to hang on to. 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 Baldebos. 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, everybody. This is Bob Baldebos. Welcome to the Pivots podcast. And today I'm here with a very special guest, AJ Kerrigan. AJ, welcome to the show. Hey, Bob, thanks for having me on. Yeah, super excited to have you. I mean, you have been with pivots for a very long time in our community, so, yeah, it was about time to get you on the podcast. Like, I think for years, right, that you have been around the community. Yeah, for sure. It's been a. It's been a great time being there, too. I'm happy. Nice to hear. Yeah. So maybe for starters, maybe you can introduce yourself to our audience, what you do on a day to day. Sure. Yeah. So for my professional life, I don't know, the past 20 years or so, I've been what I think of as developer ish or a developer adjacent. Started as sort of a. In that technical support or systems administrator type space, and then always working in a bit more code over time. And the focus was always less on making and building things and more about understanding how the things are working, helping them work for people to solve problems. And that's gone through pretty much my whole career into. I started in a larger insurance company, and I've sort of, as I've been going on with the career, I get into smaller and smaller companies over time and where the place I work now is called Stacklet. It's a startup in the cloud governance space, and we're built on top of an open source tool called Cloud custodian that's written in Python. Now I get to work on some open source, and I get to help people use tools, and that's where I am. That sounds like a really nice job, open source python. And, yeah, going to smaller companies over time right. Uh, yeah. Different dynamic to that. Right. It's true. And when I, when I started thinking about it, it seemed like it was sort of career progression in reverse. Because you think about people who are young, they come out of college and they go into a startup, and then they move to a bigger company and a bigger company. And for me it was the complete opposite. I started at buttoned up insurance and now I'm at a startup. Nice. You're not risk averse in any sense. Oh, it took some product. Awesome. Awesome. So, yeah, today we decided that we had a very interesting topic, and we have been talking about back and forth a book I know you're a big fan of, and I recently completed, I think it's called the programmer's brain. Right. By Felin Hermans. Doctor Felina Hermans. Yeah. There's a lot of research into the programmer's brain. Right. What happens there when we program and understand code. So, yeah, maybe I can ask you, what is the book about? Right, because you have this book in high regard and, yeah, you have a lot of notes on it, so maybe you can give us a quick summary what it's about, and then we can highlight some specific things that are important for us python developers. Sure. Yes. And I do hold it in high regard. I actually, I try to avoid quoting it or bringing it up anytime it seems relevant, because in my head it's relevant all the time. And it's partially because I mentioned that bit about being sort of developer adjacent, developer ish, less formal training in the computer science and the developer world. So I'm always trying to think back and sort of backfill both technical concepts and also how my brain is working, how the code was working, how those two fit together. And that's sort of where this book. I think this book's really helpful. It's broken up into four parts, and so one's on reading code, one's on thinking about it, third part's on writing better code, and then on collaborating. And I think those are really, those are, it's a useful progression. It's four different parts. And even though it's talking about cognition, how the brain works, how the code works, and that sounds like it might be in some kind of nerdy stratosphere, I think that what it talks through is so approachable and so applicable to just daily work. That's what I like about it. Yeah, it's very readable and very relevant and very accessible because these studies can be very technical. But she definitely manages to bring it back to very concrete examples and make it very relatable. Yeah. And those four parts, indeed, I agree. Those are high level, important aspects of our developer jobs. So, yeah, maybe we can get into some nitty gritty some details like what are some of the lessons that really stood out for you? Yeah. One that comes up, and I know it was important to you too, is this whole idea of chunkability where whether you're reading code or you're writing code, your brain is always trying to look at that and group it into little chunks. Sort of like the first time I remember hearing about chunkability for your, how your brain works is with phone numbers. You typically have phone numbers that are broken up into smaller number segments. And the same sort of processing happens when you look at code, your eyes look at it and you're trying to break it up into pieces. What's a variable name, what's a method name? And what are the properties of code that help or hurt that sort of chunking process? Yeah, I think like it might be in that book or somewhere else. Right. When you just memorize a bunch of random numbers or random letters, even then it's very hard. But if you form it into a sentence, then it's very easy because that's where you chunk them into more meaningful things. And in that sense, I think she also says that learning or knowing about common design patterns is a good thing. Right. For that same reason that, yeah, it's kind of a chunk of knowledge that explains a lot of what's going on in the code base potentially, right? Yeah, for sure. There's design patterns and there are a bunch of these different, and there's the concept of beacons too, where there are little pieces, whether it's the way that a variable is named or the name of a method or a design pattern or a comment, just little pieces for your brain to latch onto to help put that little piece of code into context and help make sense of it so that it doesn't seem like a little island. I think about it almost like when you're driving around town in the times before gps, you would take a couple different routes and you would fill in that fog of war, the map around town. And over time you'd kind of piece those together and you'd see how everything knit together. And if you just lean on, say, gps and you don't think about it, then you've got some discrete pieces of knowledge, but they're not really, they're not globbing together. Awesome. I was incredible. Okay, then we move into German. German? No, German. Load german load. But what is that? And why do you think it's important? Yeah. Germaine Load, I think, is interesting. She talks about it here as the work required to encode thoughts to your long term memory. And so that's if you've ever felt, I'm sure we've all felt this feeling. You're looking at a new piece of code, you're trying to get something done, and it's like you've maxed out your brain capacity on understanding the code that you're looking at, on trying to understand the problem or solve it. And there's no brain space left to record those memories for later. So you go to look at it later and it's like all the work you did has gone. And you may notice this if you're in more of a mentorship or a teaching role, you're working with someone, trying to help them understand something, and then they come back the next day and whatever you talked about is gone. Because. And this is sort of a shout out to Kelly and Sean at teaching Python like this is not a linear progression of teaching. You're getting a bit, you lose in a bit. It's sort of an erratic journey of learning things. And that Germaine load, I thought, was an interesting way of framing that. Cool. And on that note, she talks a lot about those three components, right? The long term memory, the short term memory and the working memory, right? Oh, yeah, yeah, she does. And I never really thought about the working memory as separate so much. I mean, I think short term memory and long term memory are fairly common concepts. I think what she talks about with working memory is that processing type work, it's short term memory in context or applied to a problem. And I thought that was interesting. Awesome. Then in the notes, there's also the importance value of worked examples. What is that about? Yes, there was a really interesting study that they talked about in the book where there were. There were a couple different groups of students, and they gave the one set of students what they called a worked example. So solution certain problems and then sort of a guided tour of how you go through and solve a problem. And they help the other students understand, but they didn't really give them that work example piece. And the results of the study were that the students who got those worked examples did better, not just on the problems that they were given, but just it helped build. Build up their skills more generally so they could apply that elsewhere. And what it reminded me of on the code side is the first time I came across annotated source code through the underscore J's codebase. This was years ago. You can still see it today, though, on the web. Go look for underscore JS source code and it'll be not just the code, not just the code with comments, but pretty much line by line or method by method breakdowns of what's going on, the thought process behind everything. And I think rather than just understanding what the code does, seeing a lot more of that intent behind it really just, again, it gives your brain something to hang on to so that it just makes more sense and it's easier to connect to other thoughts later and annotated. You mean like not like type hinting, but like actual notes taken on a printed outcome? Yeah. I think if you came and looked at it today, coming from a Python context, you probably think, oh, this looks a bit like a Jupyter notebook because it kind of, it interleaves code and prose. So it's almost like how you can have code and markdown cells in a Jupyter notebook similar to that. So that's a great teaching tip then, as well. Right? Like, if you would teach somebody how to code, not just give them the code, but actually annotate it and make notes around it, can be extremely useful. Right? Yeah. And it also, it seems a little bit counterintuitive sometimes because it feels like, I think some of the objection to that sometimes is that you're providing a little bit too much or handholding too much, and if you're leading someone along, then they're not going to be developing those skills themselves. There's this sort of intuition that, no, we have to teach a person to fish and that sort of thing. And that's true, but I think showing how you've done it, even if it includes, and I think this is why twitch streams have gotten so popular. I don't watch a lot of them myself. I don't know about you, but I think what ends up being popular a lot of times is not just the straight path to some successful end, but a lot of the meandering along the way and some of the missteps that you make. Yeah, that's totally true. And I can test that from my experience. A lot of what we see on YouTube is very polished and you see only the final result, as if code was going to be written perfectly. But my code clinics are way more raw in the sense that they see my process and how I can get there. So I think they get to firsthand experience part of that chunking and how I get to that chunking ability, and that's often not shown because it has a lot of failure in it as well. Yeah, it kind of took me a while to open up and show that process, knowing that I'm making mistakes all the time. And that's fine. That's actually where that's valuable insight. Yeah. So, interesting, interesting. So, okay, moving on then there's semantic wave, another relatively technical term. But what's that about? Can you expand? Yeah. And this one is another one. It sounds semantic wave. It sounds very, it sounds very official, I think. Very technical. But the idea is that when you're teaching a concept or learning a concept, there are various levels of abstraction. So you might come in finding through real life metaphors or something where it's very abstract. You're not talking about the specific code concepts. And then at some point you learn the more concrete something that comes to mind is multi threaded code. You might think about concurrency, multithread code, something like that. And you think, oh, well, this is like waiting on a line in a shopping, in a supermarket, and there are a lot of people in the line and you add another line. And so you can spread that load across two cashiers or something like that. And that's helpful. I think it's helpful to get a handle on why you're doing something. What might help. But if you don't bring that to a more concrete level to understand actually what's going on under the hood, then it's going to totally lose you. This came up on a recent episode of, again, teaching Python. Hi. There is someone was on there talking about how he used to teach things at too high of a level of abstraction because he thought it was being beginner friendly. And then it would turn out that the students wouldn't really know. They wouldn't know the right names for concepts. They wouldn't know how to look it up. They would feel kind of lost outside. They got, once I got outside that little walled garden of knowledge. And I think the idea of a semantic wave is that you're just always going back and forth, bringing things abstract, going concrete and going back and forth to fill in your knowledge. Interesting. Yeah. So although the supermarket example makes it easy to understand multi processing, it's still far removed from the technical terminology. You will need to understand it. Right. So you kind of need to attack it from both sides. Right? Yeah. And I think the interesting piece there is that you need it from both sides and you kind of, you bounce between both yourself. And that's why that can be really frustrating if you're trying to teach somebody because you think, which level of abstraction should I be at right now? And you sort of have to feel it out for you and for the person who's learning when you're learning. Yeah. Plus you might have people in the class or in your session that have different levels. Right. And have different learning styles. So there's this whole plethora of different things to take into account. Teaching is challenging, that's for sure. Yeah. And we should all tune into teaching Python some good content there as well. Shout out. So there's no money exchange? Oh, no, no, it's all good. Cognitive dimensions of code bases and. Yeah, I think cognitive will give us a lot to talk about because, well, I'll let you lead it and I'll chime in. Sure. And the idea here, this was sort of an adaptation from an earlier concept called cognitive dimensions of notation, but it was applied to code bases. So the idea is that any code base that you're looking at has a bunch of different properties and some of them are in conflict with each other, but there's some of them just to give an idea are things like error proneness or progressive evaluation, which is the idea that you can have an idea that's not fully formed and correct, but you still get some useful feedback. And I think the thing that's interesting about this is that at some point when you're writing code, you're making trade offs. Not always consciously, but you're making trade offs on different one dimension versus another. You might say I'm doing something that needs to be, that is for quick evaluation, like you're working in a sort of like working in a replay. And in that sort of case, you want fast feedback, you want things that are, that can run without being completely perfect. And the trade off there is that some of the stuff that's coming out is not going to be perfect. And that's. I just think it made me think of a tool, a python tool I use called Visidaydata. It's a package for looking at data in a tabular format in the terminal. It is great for giving fast results, for just looking at a file, getting some quick stuff back. It lets you mess around with partial python expressions, partial stuff. It's a tinkerers fiddlers type tool, which means that it consciously says, we are not going to be perfect. We're going to hit that 80% case and do it quickly and make you happy. The idea is that we're always making these trade offs, and it's interesting to just make sure that you're doing it on purpose and in a way that fits with the expected use of your project. All right. And lastly, you had a note on practicing code reading. And we always say, like, reading a lot of code is important. You just notice your skills. Well, obviously you have to write a lot of code, but reading code, there's definitely like when I joined a bigger software team and had to read a lot of legacy code, my skills just exponentially grew fast. You pick a lot from that, but then if you're not joining a bigger team and you just want to do that in a community. The book talks about code reading clubs. So how does that work and what do you think of them? Well, I think it's a, it's a fascinating idea. So there's a website up there, Felina had a blog post about code reading. And then there's a related website, codereading club, that just tries to share some resources, talk about some of the exercises, sizes that they've found successful in the past, and just share some ideas around doing these code reading clubs. I have never done one, but I think the idea is awesome. And actually, since you mentioned reading legacy code, I'm curious from your side what sort of strategies you found useful or you developed as you were going through, what the experience was of when you were diving into legacy code and helped you here. Bye bye. I was forced to, and because up until then I was writing code for years, but it was always like this one man shop. Right. So no real review of my code. Am I doing it right? And you kind of are guessing and related back to your mentors in the forms of books. Right. And do the best you can. But yeah, once you're part of a bigger team and you have to, you know, maintain a code base and, you know, ship features, well, first bug fixes, then later bigger features, you really have to get a good understanding how it works. And, yeah, as I said that that was a big step for me. Did I have certain tips? Do I have certain tips for that other than diving in and get the thing working locally, which is always crucial to get it running in your local environment, that is instrumental, I think. Yeah, there's definitely a moment where it was very overwhelming and then with practice and again that chunking when I could chunk the things better over time, just getting, I guess, more of the code base into my, what feline calls longer term LTM. Right. As opposed to STM and constantly losing it because it goes out of your short term memory. Yeah, I don't have specific tips other than that was really pushing yourself and getting uncomfortable and doing it a lot and running the code as much lately I've been using the debugger a lot more to break into code, run it, and then inspect objects. I'm doing that way more than back in the day, for example. Do you have an answer to that yourself? I mean, apart from what you shared with the book, but maybe some practical things you do now differently after all those years. Yeah. And I think what you, it's interesting to hear you talk about it because it's been pretty similar for me. I think I would, when I try to read code, I think when I, when I started doing it, because I didn't really know where to start, I would read top to bottom. And I think what they talk about in this book is more trying to find a good entry point, which makes sense, which I think if you read enough code, you're going to sneak up on that idea organically, which is if you're looking at Python code, you're probably looking for a main method, or you're looking for some kind of a console entry point. Or if you're trying to run tests when a code base has tests, running those tests is a great idea to find things that may or may not even be documented. Looking at the test code there and breakpoints debuggers. I think similar to you, I took a while to start using a debugger, and then when I started leaning on it more, I wondered, why did I take so long to do this? Because I think early on it was intimidating. Oh, I'm going to look at the debugger. This is going to be a whole bunch of information. It said, no, just pause the thing. You don't have to have a problem. You don't have to even have a bug to be debugging. Just pause the thing and look around and see where you are. And just trying to find out where you are in time and space in your code base, I think is really helpful. Yeah, I think that's the missed notion that it's just to fix problems, but it's actually also a tool to just help you reading code even, or write my test there and for so much more. Right? Yeah, for sure. I do think that there's something with the mention earlier at some point in the book is about with flashcards and the spaced repetition idea when you're trying to remember concepts, but you can't just look things up. And this is a place where I think I was a little bit off with the book. I used to think about things like syntax, I would say, well, you don't really need to be an expert on all the syntax. You can google it. You don't really need to be an expert on all these little details. You can google it. But every time you do that as a bit of a context switch and it's working different parts of your memory and it's making something that should be unconscious more conscious. So I think feeding that, feeding that short term memory is helpful. And sometimes if you're leaning too much on a debugger and not just thinking about it, then you're not working on that recall as much. And so what I've done more a little bit lately is sort of, I think about it like debugger role playing. Like I'm looking at the code, I'm kind of playing through what I think is going to happen, and then I'm doing it in the debugger and seeing if anything, if you do that mental exercise and then you go into debugger and something is a surprise, then that's notable. You think I expected this? I got this other thing. Is my mental model wrong or is the code doing something funky? And I think that's really helpful. That's a great tip. Yeah. Awesome. Yeah. And you're right. We always say you can look everything up. There's no shame in using Google stack overflow, and that's true. But there's also definitely something to save just for the speed of how effective you are as a developer to be able to have at least memorized these common constructs. Obviously the for loop, but even certain modules that you use a lot, I would definitely think the built ins, they should just come natural. Yeah. So it shouldn't be a surprise that sorted. You have this key, optional key keyword argument that you can give a callable, that's probably stuff you don't want to look up every time. That should just become second major. And it will. That I've noticed with coding, the more you use it, that stuff does come automatic. And I like that you brought up the flashcards, the spaced repetition. I think the book also talks about it's way more valuable to repeat things over time than have those cram sessions and just try to stuff it all in a longer session. And that's, I think why the platform is working so well. Um, is that people come back and they code every day and it's kind of, you kind of get that spaced repetition, although that you do different exercises. Right. But they're doing enough. There's, there's a lot of repetition. Right. Um, just how you solve problems. Uh, and that. That really works for people. So, for sure. I. And that's. I remember when I first came across pie bites that was seeing those exercises was really helpful. And then the forums. So for anyone out there who has tried the pied bytes platform and not really dug into the forums much, I would say, go check out the forums. Yeah. It ties back to the work examples, discussion from before, because you can see not just how you solved a problem or what the official solution was, but how other folks in the community thought about it, how they attacked it, how they went, when they thought it was really helpful, something they thought would be useful, but it really took them into someplace where it was slower or didn't work for whatever reason. And I think those sorts of stories. And that ties into some of the code reading. There's this idea that there are a lot of parallels between reading code and reading text, and I would say that extends to writing code and writing text also. But when you see that code in context and you see the discussion with other folks in the community, then it's sort of, it's that campfire storytelling aspect. Right. It puts it into a story so that it sticks a little better. Yeah. Beautiful. Plus, you have spent maybe two, 3 hours on doing the exercise. So you have skin in the game, and then it kind of sticks more when you then consume the other solutions, I think. Yeah, yeah. And you see people who have different skills than yours, too, or you can sort of get people's personalities through their code or how they explain, I think, of the. From the Slack channel, the community, there's Daniel Howe is just very into the algorithms, like writing the algorithm by solving these algorithms. And I am terrible at that stuff. So it's just really cool to see those discussions. Yeah, yeah. And how they solve, like, somebody might go completely functional and another person might be doing more. Oop. And then, yeah. Daniel's is the algorithm side. It just seems like completely different code. Might not even seem like python. Yeah, that's fascinating. Cool, cool. All right, so to wrap it up, and now, thanks for sharing all these insights, everybody. Of course. Well, call to actions, I guess, is to read the book. Very highly recommended. Read more code. But what is another call to action you would have for our audience? Yeah, those are two fine ones. So, yeah, read the book. If this is at all interesting to you, read the code. I think you'll find some interesting stuff in it. Find a code base that you use, that you find a tool that you use and where you haven't looked at the code yet and just peek at it. Look at the code, see if there's anything that looks interesting in there to you. I think something important here is not to have a goal. You're not trying to fix a bug, you're not trying to solve a problem. Just try to see how something's working. And if you're curious enough, run it in a debugger, not because there's anything broken, just to watch it work. Yep. And I liked your tip about entry points. Right. Look for a main, look where the program starts and don't go read those modules from start to end. That will exhaust you pretty quickly. But just go through the code, how the functions call each other and that will be way more fun. Cool. Lastly, is there any other book you're reading or Elwin you want to share before I let you go? Yeah. So when you mentioned the books, I had a book just land in my mailbox recently and I thought, oh, this is kind of cool. Just sort of got a book. It was called an unintended voyage and by, I think it's Marshall Ryan Maraska and it's the 13th book in a series or in a world. And I think that's just really interesting to me to come into a series. Usually I would want to start at the beginning, sort of like we were talking about with code, right? You start at the beginning. Keep going. But I thought, what the heck? I'm just going to read this book. And I thought diving into a world that was so established it made me think it was almost like the fiction equivalent of reading legacy code because I'm like, oh, there's this world. It's been around forever. I was not a part of it. And now I've come in at the end and I thought because it was a sort of standalone story that I thought it was well done. Characters, plot were cool. But again, finding those little nuggets in code, there were certain ways of speaking that the main character had. It was sort of an in world slang, in world swearing. And it came up so much that it sort of kept jogging my head. This is a little bit jarring to me. And it reminded me when you're looking at code and you keep seeing things that aren't matching the idioms that you expect and think, oh, man, this is just, it's a little bit more work to keep track of than I really want. And so I was not intending to tie any of it back to code, but just because I've been thinking about this discussion in this book a lot. I think it just mapped onto code concepts really, really cleanly. Nice. That's interesting. Cool. Cool. Yeah, I'm still reading robust Python for the type ins and mastering Python second edition, which is chock full of good insights as well. Heard good things about that one. Yeah, cool. Well, AJ, anything else you want to share or. No? Just say if you're still here, if you hung with us this long. Thank you. And if you happen to be part of the pie Bytes community, thank you for being you. You folks are awesome and come say hi. Thanks so much. Yeah, thanks for all cool stuff you shared today. Very useful for all levels. And yeah, it was a great joy having you here and thanks for being part of a community and all you do there. 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 slack community of Python programmers, go to Pibytes community, that's Pibit es forward slash community. We hope to see you there and catch you in the next episode.