TAD: Hello and welcome to the Acima Development Podcast. My name is Tad Thorley, and I'm hosting today for the first time. We also have a whole host of guests today as well. We have David Brady.


DAVID BRADY: Howdy, howdy.


TAD: David Solano. 


DAVID SOLANO: Hello.


TAD: Eddy Lopez. 


EDDY: Howdy.


TAD: Matt Hardy. 


MATT: Hello there.


TAD: Mike Challis. 


MIKE: Hello.


TAD: And Sergio Peralta, who's also new. 


SERGIO: Yeah, I am new. Hi, guys. 


TAD: Our topic today is, how did you get up to speed when you're starting with a new codebase? Also, with that comes along the idea of working with legacy code. One thing I was thinking I'd start with is maybe focus on a Rails project because I know we all are familiar with Rails, and then maybe expand that out to just codebases in general. My first question for you guys is, when you start brand new with a new Rails codebase, what is the first file that you think you look at?


MATT: I'm going to say the gem file. 


DAVID SOLANO: Me too.


TAD: Cool. What does the gem file teach you?


MATT: By looking at the gem file, you can see some of the project's dependencies, some of which you may already be familiar with. And that can really help you learn your way around a project, just knowing the tools that are being used inside of a project. For instance, if I look at a gem file and I see Grape API in there, I know where those endpoints are going to be, and I know how they're going to be structured, right? 


TAD: Right. I think it's interesting. You can often see, like, Ruby version; sometimes people will put it in a gem file, internal gems.


DAVID BRADY: I was going to comment that I have a weird answer to the what file do you start with? And the answer is no. 


TAD: [laughs]


DAVID BRADY: My favorite place to start is by pairing up with somebody and having them show me the app so that I know what it does. And then, like, very, very quickly, somebody who will sit you down, and they'll say, "Okay, let's go here." And then they will casually mention offhand, you know, "Oh, this whole section is generated. It's just static. It's generated by Jekyll." And I'm like, ah, okay, I know where all of this section comes from. 


After I pair up with them or while I'm pairing up, I will often pull up the directory listing of the root of the project and often app models and app controllers. And I'm trying to come in very breadth-first, very top-down. So I can work on a project for a day or three without ever opening a source code file to look at it but probably because I'm a bad programmer. But I like to get the layout of the forest before I, like, take a core sample out of a tree. Does that make sense?


TAD: Sure. Yeah, [inaudible 02:57], right?


DAVID BRADY: Mm-hmm.


DAVID SOLANO: I [inaudible 02:59], David. I pretty much do the same. But if you ask me to look, like, one file kind of just to have, like, a quick look of the entire project, I will say a gem file, but I'll also take a look at the application controller. And you'll see some weird stuff happening there. 


TAD: [laughs] Yeah.


DAVID SOLANO: I'll give you an idea. Like, I remember one time I saw it, and I saw an application controller from really old code, right? Like legacy. I don't know; it was like 3,000 lines. [laughs] So it was pretty funny at that time, right?


TAD: Well, it's interesting to see some of these, like, grandpa classes that everybody's going to be inheriting from because, a lot of times, there will be behavior that's happening there, maybe like a before filter or an after something going on that is always happening, but you don't realize it because it's kind of tucked away.


MATT: Yeah, I think Dave brought up a very good point, though, if possible, the most important thing is let's look at a running version of this application and have a tour of the UI. You know, you can learn a whole lot just by seeing the UI of something. You get a feel for how it works. 


And then I also really liked how he said top down. If I'm going to get into the code and look at something, the first thing that I'm going to look at are the endpoints, right? Because that's the entry to everything. And I think if you can track down the proper endpoints, you can find your way through the entire integration of that particular feature.


TAD: No, I agree. Finding kind of the entry point into the code is really valuable. And the parts that you present to people are probably some of the more important pieces, right?


MATT: Absolutely. Any transformations that happen can be tracked down as long as you can find your entry point. I mean, with modern IDEs, it's pretty easy to navigate your way through code and kind of fumble your way through to see where things happen.


DAVID BRADY: I think it might also depend on your team style as well. Like, I will often open a project and like David was saying, drill into, like, the applications controller, but I will do it, like, dynamically. I'll just go to the project and do Rake routes and say, okay, you tell me where these things are coming from. And that'll show you things that are mounted in the app directory that aren't in the app controller. They're brought in from somewhere else, and that sort of thing. 


But it'll also show you in a hurry if the team cares about what the Rake routes thing returns, right? If you get 700 lines of RESTful routes and it's just create-update-edit, create-update-edit, you know, da, da, da, you know, over and over, no, no, you're just like, uuh, okay, all right, [inaudible 05:50] [laughs] to do this. But if the team does care about it, if it's, like, maintained and very, very careful...which actually dovetails on to the next idea, which is the next place that I will check is I'll try to run the spec suite. 


And you very quickly find out if the team is writing specs, like, after they write the code, if they just try to bolt down the edges of their features, or if they started with the specs first and said the app should do this. And now when you open up the spec file, it says, oh yeah, the app does this, and it does this, and it does this. And you drill under that [inaudible 06:19], and it does this way, this way, and this way. And you could really see that. It's almost like recognizing handwriting in the code. 


And that goes into, like, gathering the lay of the land on a project. You very quickly pick up, okay, that developer is very terse and very direct. And this developer is very verbose and nuanced. And it changes how you pick up their code and how you follow their breadcrumbs.


TAD: Right. I still remember I was on a team, and one of my co-workers asked me, "So, what does this feature do?" And I said, "Oh, well, I wrote a bunch of tests." I told them where the tests were. And he's like, "No, I don't care about the test. Just tell me what it does." 


And I was kind of dumbfounded because, for me, the tests are telling me what it does, right? Like, that was the obvious place to learn what something does is by going and looking at the tests, but his approach was a little different, I guess. And it sounds like you're kind of the same way, Dave, where you would love to see some good tests to really get a grasp of what's important, what people's styles are, what it does, right?


DAVID BRADY: Mm-hmm. Absolutely. At risk of ending up on a soapbox about specs—and some of you have been to conferences where I've really gotten on my soapbox—there are multiple audiences for testing. And a lot of people don't care about the first two audiences. And that ends up creating low-value tests, which is sad because the reason they don't care about those first two audiences is because they've been brutalized by low-value tests, and it's a vicious cycle. You write them bad; you get them bad.


But the first two audiences of a spec file is, if I pull down the app and run, you know, migrations and boot everything up, I want to run the spec suite. And I don't want to have a conversation. I just want a green dot or a green okay. Does the app work? Does it take over? After that, the next bit of audience is, if I'm coming into a piece of code that I have to maintain, I will go to the spec suite and say, can you tell me the story of this? What does this code do? What is its responsibility? What's it [inaudible 08:20] Don't tell me how it's doing it, just tell me what it's trying to do. 


And then do I care about drilling in to say, you know what? How does the API work? How does the code work, and what are the implementation details? And if you care about those first two audiences and getting those things airtight, the spec suite will get your back later on. And, yeah, when you come into a team if...and this harks back to what I just said about, you know, the team style. If the entire team doesn't care about the test suite, the specs won't get your back, right? They'll be very sparse, and there'll be lots of gaps. And, you know, you come behind and do your best to preach in the wilderness, you know, to repent and write better specs.


TAD: To further your point, Dave, you'll know which flags they use when they run their tests even? 


DAVID BRADY: Yes, right?


MATT: Thanks for saying that, Dave. Because I think something that really helps define how I would look into an unknown codebase is team culture. Any of us who have been in this industry for a length of time we've worked in codebases where there aren't any tests, where that culture isn't there that people want to help you out. 


If I walk into a great culture like we have here at Acima, the first thing I'm doing is I'm pairing with someone. And they're going to walk me through the code, and they're going to lend me some assistance. And they're going to explain how things are tested, and why we test, you know, and the importance of those things. And I think culture has a really big role to play in this.


DAVID BRADY: 1000% to that. I moved last year from the Atlas Team over to the Data Services Team because I really wanted to get into big data. And one of the things that surprised me is that our process over on data services is a little bit old school. It's a little bit enterprise. It was where software development was in, like, 2005, like, pre-agile. And I'm not saying that to criticize the team. It's just that's just, like, the way the culture here works. So we don't use tests. 


Developers work alone. They want a quiet office so that they can think and get really, really deep in the code. That creates some artifacts, right? There are files in the codebase that have been abandoned for three years. And you have to know when you get into a file, oh, I need to go check git. This is not even, like, an indictment of my current team, and I don't mean it that way at all. 


You have to come to the team from their culture, right? You can come into a piece of code and go, this makes no sense. How does this ever...oh, wait a minute, git log. Oh, this was last tested in 2017. This is probably not current code, okay, cool, fine. And then, you can pick it up and move to the next piece. And you run into a piece of code, and you're like, how the heck does this work? And you have to, instead of saying, well, the Atlas team, I would expect a very shallow cut, a very quick test, a very high-level, you know, break this down just this one piece, [inaudible 11:14] detach this and run it.


But on data services, I expect a data warehouse to be present. I expect a lot of, like, very expensive dependencies to be present. I expect to lean on those very, very heavily. And so, I'm not expecting a small cut. I'm expecting to pick up this entire ETL file that transforms the data out of the merchant portal database and moves it into our data warehouse. I expect to pick up that entire chain and hold it all in my head because, remember, we are working...we're not pairing. 


We're not doing any high-bandwidth communication. We're doing slow, deep thinking about how we work with the things, and that really, really dramatically affects, you know, what direction the code is going to be in. I'm not going to go look for a test. I'm going to dig into this file, this file, and this file because we have a working template of how these three files always fit together. 


TAD: Yeah. We've heard from probably, I'd say, some more of the senior folks on what they look for and what they do. I'd like to also hear from our newer folks. Eddy, when you get a new codebase or you're exploring, what's your approach?


EDDY: To give you a bit of perspective, I want to premise saying that I only got about a year and a half of experience total, and I probably went on it the wrong way. I didn't ask the right questions. I was just too eager to pick up, like, tech debt tickets. And so, I got familiarized with the code by picking up work that didn't have as much attention. And I slowly trickled my way through the whole codebase based on my necessities. 


In hindsight, that's probably, like, the wrong way to do things, at least to me with having a bit more wisdom, not a lot but having a little bit more. Seeing other people's approaches to tackling new codebases is amazing. Like, you, for instance, made a comment about I like to look at the biggest file. Like, so if you look in the app directory for models, for example, the biggest contender for that was lease. And you're like, huh, Acima does leases. 


And I think, for me, that would have been something to truly understand before I even picked up any changes because, in order for the changes that I'm implementing to be efficient, I also need to understand at the core what the app is doing. And that was my biggest fault when I first started. 


So I would say grasping the fundamental core of what the actual app that you're developing for does. And one thing that really solidified that for me was running the app as an end user. So I played around with it, played around with the functions. What am I able to do? But you mentioned something really important that I've done without even realizing is ask for help, right?


TAD: Nice.


EDDY: Asking my peers what their experience is like with the code changes that I'm supposed to be making and have them just take time to really drill that in my head. I think that's really helped me out a lot.


DAVID BRADY: I just want to back you up, Eddy. I don't think you were wrong with your initial approach, like, jumping in, grabbing, like, a corner case ticket or a weird, you know, bit of abandoned work. First of all, that's proactive. You're not on your back foot waiting for your manager to just throw stuff at you. You're actually, like, going in and saying, "What can I go get?" And that changes your attitude. 


And then the other thing is you would pick something up and try to figure it out. And one of the most powerful things you can do is just grab one piece of data and follow it completely through the system. Like, from the moment a user typed it in on the web page to when it ends up in the accountant's reporting spreadsheet, how did that get through the system? And knowing all of those pieces. You have to string all of the beads onto the string that represent the app. And that is super powerful. It gives you a ton of context.


DAVID SOLANO: It's also [inaudible 15:07], for example, so you receive, like, some ticket with a new implementation. But maybe no one knows how to get that calculation right. But you know that your PM or someone else knows that that's reflected somewhere in the UI. And you know that if you go to that specific part of the UI, and you find that number and say, oh, hmm, here it is. Now you follow back to the code, to the back end. And then you know, oh, this is how the way it works. And if you're able to follow that approach also, that's a good way to do your work, to come to the idea on how to solve this because you already...you were able to follow it through the UI and through the end code.


TAD: I think it's interesting that there's different approaches. And I don't know that certain approaches are necessarily better than others. And sometimes it's just, like, the approach that works for you given your current familiarity, experience level, that kind of thing. Sergio, I'd like to hear from you because you've recently joined the team. And you've had to do this where you came in, and we said, "Here's a codebase. Figure it out and go." What did you do, and what was your experience?


SERGIO: Yeah, yeah, I have a nice history behind this. Like, I don't have a very big experience with Ruby on Rails. I am coming from another stack. And I am facing two different things; one is lacking the knowledge of Ruby on Rails in some things, and also the lack of the knowledge of the business rules behind, and the legacy code, and the [inaudible 16:43] of code. 


So my approach right now is, yeah, seeing that unit testing, getting a know of how the application works. I've talked with other people about if they have this kind of issue before and also with most experienced people about how to do some specific things. So, yeah, what I can tell is, like, I am the kind of people that like to learn myself is, like, trying to figure it out by myself. 


If I don't spend enough time to try to figure it out by myself, I guess I don't move in the right path. It is like having someone else telling you how to do it step by step is good. But, at least for me, I need the time to process myself and figure it out myself and struggle with some stuff, then continue with the role. That's what I do usually. But it is, like, the way I learn. So that's the thing I can say.


TAD: I think that's a fair point because definitely, the code I've thought about and struggled with is the code I remember best, right?


EDDY: I want to really fixate on what you just said, Tad. Holy cow that resonated with me deep down. The tickets that I particularly struggle with the most are the ones that not only grow my skill as the developer but also, like, really drill down [laughs], you know, for my fundamental understanding of that particular code change that I'm making. I also want to say thank you, Dave, for reaffirming my path initially for merchant portal's codebase.


DAVID SOLANO: Hey, guys, I don't know this...this is out of topic. But right now, I am using this ChatGPT tool in some cases where, hey, what if we can improve this code? At least for me, I don't have the sense that the code is wrong. But I just paste the code, check what ChatGPT is thinking, and just let's compare it with my notes and see if the things are good or not. 


Yeah, sometimes, yeah, I got nice answers, sometimes not, even the code doesn't run. But I like it. It's a tool that is helping me in some stuff, maybe when I feel stuck with something. But, yeah, just to mention. I don't know if it's out of the pocket but yeah.


DAVID BRADY: I've played with ChatGPT as well. And the thing I love about asking it to write your code for you is not that it's going to write the code but that it will say, "Okay, well, here's a block of code." And then, in plain English underneath the code, it starts breaking down the code that it just gave you, and it says, "Okay when I do this, it's setting up this kind of a thing. And then I'm going to do a double dispatch into that. And then I'm going to do this, which is going to set..." And it walks you through how the entire thing...


I asked it to write a really weird SQL query. And it gave me a SQL query and then broke it down and said, "When I use this window function, I'm going to get this, and then when I do this, I'm going to do a subquery." I'm like, holy crap, that's awesome. Yeah, I like the explanations that it gives.


[crosstalk 19:58] 


TAD: It seems like pure programming but just with a bot instead of a person, right? 


DAVID BRADY: Yeah, yeah.


EDDY: I've had ChatGPT breakdown code in certain aspects. And I'm like, huh, I don't really understand what this method is actually doing. So, like, I've copied and pasted in ChatGPT. I'm like, can you break down in layman's terms what exactly this is doing? And it kind of follows the same thing that Dave said where, like, it adds comments, you know, to each line of code and tells you, oh, this is what this does. This is what this does. This is what...I was just like, oh, interesting. I did not know Ruby was capable of such things.


DAVID BRADY: I had a fun...it's a little bit off-topic, but it gets more into the ChatGPT thing. The other thing I like about it is it really does act like a pair. I asked it to write a bit of code, like, a Bash prompt for colorizing some things. Who keeps ANSI color codes memorized, right? And it came back, and it said, "Well, you can do this." And it gave me the ANSI color codes for the thing that I wanted. And then it said, "That works because this, this, and this." And it was wrong, the explanation. I mean, the code was right, but the explanation was wrong. 


And ChatGPT it's read-only in terms of the big brain. Like, when you finish a conversation, nobody can use the contents of your conversation. It's not modifying and updating the AI. But in the context of the conversation, it will act like a pair programmer. So I actually...I went, "Close, that's very good, but this is wrong." And I told the bot, "This is wrong. This piece actually means this, and this other piece means this thing." 


And then, because it's a bot and because it's AI, I said, "Would you try to explain it again?" And it gave me the code and the explanation again, and this time it was perfect. It said back in its own words what I had just told it about the code. I thought that was mind-blowing. Really great. And a good way to think, again, like a pair programming partner. 


TAD: Well, I thought it was interesting, Dave, that you pointed out that maybe step zero is not even read the code; get someone to guide you through the code. And it sounds like ChatGPT can kind of do that, right? Like, it can serve as a sort of guide as you're trying to understand a new codebase.


DAVID BRADY: Yeah, it's going to give you what we're trying to accomplish along with the how we accomplish it. Yeah, it breaks it down at both levels. It's really neat.


EDDY: Not to mention that ChatGPT is almost always available for you to pair versus asking someone else on the team who might be busy.


TAD: Do you think we'll see more tools like that integrated in the future? I mean, we already have some pretty powerful plugins and IDE support and things like that for understanding the codebase. Do you think we'll get kind of cyborg-guided things as well?


DAVID BRADY: I think it's inevitable, yeah. 


MATT: Yeah, I think -- 


DAVID BRADY: Everyone's afraid that, oh, the bots are going to take over my job. No, they're not going to take over your job. But your job in five years is not going to be to punch in all of the codes to create a Rails route in a back-end controller. In five years, the most effective programmers are the ones that tell their IDE, which is backed by AI, and say, "Give me this resource controller [inaudible 23:08] connected to that." And the AI goes da, da, da. "On this one connection, did you mean this or that?" "I want it that way." "Okay, cool." And it'll spit it all out. 


The people who can operate the high-level machines the best are the people that, you know, will have the best jobs in five years. And it's exactly the same way as we are. You go back 25 years; people were running...well, 35 years, people were writing code with text editors, with dumb text editors. And then IDEs came about, and our job now is to know how to run more and more sophisticated IDEs. I think that's inevitable, yeah.


TAD: So your argument would probably be, when you first start, like, you were talking about meeting with somebody who could give you a tour of the overarching ideas, point out the different pieces from kind of the higher level thing. And it sounds like you're saying that's probably not going to go away, that you're still going to need to have someone that has an understanding of what needs to happen, what all the pieces are, and that kind of thing. But those pieces are maybe going to be, you know, bot-augmented, rather than you hand-code all of them. 


DAVID BRADY: Yeah, 100%. There's always going to be a market for somebody thinking. There is a fantastic quote that I saw about 25 years ago. I can't remember who said it, but the way they phrased it was no amount of best practices, industry-sophisticated tooling, or agile, or otherwise processes can take the place of knowing how to program a stupid computer. And I think that will continue to be true where the term program a computer is slowly turning... it's no longer dropping, you know, bit one, bit zero, bit one, bit zero into the CPU. Now it's more and more tell me how you feel, and I'll write an app.


TAD: So one of the interesting things that was mentioned is, as you look through the code, you can kind of see people's signatures, so to speak, on different parts of the code. Does that become more consistent? And if the code becomes more consistent being generated by a tool, does that make it easier for a tool to then understand the code?


DAVID BRADY: Ooh. I think the second half of that is going to be really hard because I think the first half of the question of does it become more consistent? I would say it depends on your team. If you're doing very high-bandwidth, high-pairing, lots of retrospectives, lots of communication, then, yes, the code is going to homogenize as everybody cross-pollinates, you know, best practices, you know, between each other. 


Where the team that I'm on, which is involving a lot of really, really deep thought, I have found really clever tricks that my co-workers have done in the code, but they're down in the code, and they're undocumented. And when I go into that person's piece of code, I will copy that trick for the next piece because it's consistent with their style. 


But when I then move from that person's code to another person's code who doesn't, it's clear from the context of the code that this person's skill set is way, way powerful somewhere else in the code. I try to copy that, but they don't understand that trick that that first developer was doing. I won't copy that in because that second developer is probably going to come back to this piece of code and maintain it. And I don't want to trip them up. 


So maybe, you know, maybe in, you know, 5 or 10 years, the bot can basically step in and say, "Okay, yeah, this team has a highly fractionated, you know, highly speciated personalities in the code." I've had long conversations with my boss about "I got some code, and I think it was written by this guy, Zack; just look at the file anyway." "Yep, that's him." And, you know, and we had a laugh about that person's style. 


And I think early cuts of the AI are going to make the mistake of thinking that there is THE way to do it. And later, more and more sophisticated versions are going to recognize that, oh no, there's a bunch of different ways to do it, and some of them are more appropriate to the given situation. 


EDDY: I kind of want to add to that if that's okay. The skills that I've learned so far have been with me stumbling upon the answer, right? Reading up on documentation about someone who ran into this problem once before and explaining the solution to how they got there. The reasons why I was able to remember those solutions so well was because I landed on that after probably half a day or a day, you know, for a solution that was so simple. 


I'm afraid that if we start relying a bit more on AI services that are just spoon-feeding our answers to our questions almost immediately, I feel like that may create bad habits in a sense and, therefore, like, losing retention on that answer, right?


TAD: I think it's -- 


DAVID BRADY: There's a really fantastic book from about 20 years ago called The Pragmatic Programmer. And one of the chapters in the book is called Don't Trust Evil Wizards. And back in, like, Visual Studio around Y2K era, there were wizards that you could run. It was like a, you know when you do Rails scaffold, and it will generate the scaffolding for you. The wizard would do this. 


It would write a whole bunch of really deeply nested, complicated C++ code for you. And it would wrap it up in macros, and you never really needed to know what those macros did until you did need to know it, and then you were screwed because you had no idea how the wizard was doing it. And that's an evil wizard. 


Like, a good wizard is somebody who's going to, you know, scaffold out your code and then leave it all very clearly documented at a very high level. And then, yeah, you have to come back and follow through and understand what the wizard was doing for you. You don't want the wizard...and I realized that with AI being, you know, intelligence being the I in AI, you don't want your wizard to do your thinking for you. And that's the danger of AI is it really feels like it's doing thinking for us. 


And the first people to really leverage AI will be the ones who know how to constrain its thinking into the things that we can understand and maintain so that if we move outside the AI's, you know, knowledge or, you know, the power [inaudible 29:21] for that tool, that you're not left high and dry with wondering, well, how did it build this great, big, black box? You're like, oh no, I've got all the pieces. I can modify this from here.


EDDY: Or what happens if you get...you're so acclimated to use a service that spoon feeds you, and then, all of a sudden, that service is down because that's inevitable, right? Services go down all the time. So, what are you going to do in that point when you're in a pressing...a time constraint, and you're like, oh, I really need to get this done? And, all of a sudden, the tool that you rely on isn't available.


DAVID BRADY: Yeah, it's the 3:00 a.m. fire, right? Like, okay, it's just me, eMacs, and a server that's on fire. How are we going to get through this, right? For everyone else on the team, step one is shut down eMacs and start-up Vim. But I get it.


DAVID SOLANO: Hey, Eddy. I have my thoughts about what you mentioned of bad habits. For example, look back in the past, in the '80s, when everyone who wants to make a program have to do Assembly coding. And right now, [laughs] it's nearly impossible that some of you guys use Assembly to write a program. So, yeah, it's like the technology is changing, and we are changing with this. And probably, I don't know if in the future we will be based only on the IA, so... AI, sorry. [laughs] But yeah, that's the point. It's like everything is changing. And probably all our habits will change with the tech.


DAVID BRADY: I think so. I worry that we're getting off-topic of tearing into legacy codebases. But I realize I'm the problem as well as the [inaudible 31:02] concerned about it. But, yeah, I am the source of most of my problems. I wanted to shift a little bit to talk about a couple of resources that I have used for maintaining older code. Is now a good time to do that?


TAD: Yeah, I think that's great.


DAVID BRADY: Okay. I think most of us have heard about Working Effectively with Legacy Code. It's a book by Michael Feathers. And it's still the gold standard, in my opinion. He talks about, like, when you get a gigantic legacy codebase, what do you do? Like, when you have this big chunk of untested data with this hideous dependency, how do you dig into it? And it's a little bit like the old refactoring book where he literally gives you recipes, right? If it's this, you need to do, you know, extract static method, or you need to change the parameter of this but try to maintain the signature and that sort of thing. 


There's another book, though, that I think is this beautiful, beautiful gem. It's called Code Reading. And I'm going to mangle this guy's name, Diomidis Spinellis, I think is his name. But Code Reading is a book about reading code. He starts with the argument that every other creative endeavor that you go into, an engineering class or anything, the first thing they do is they sit you down and they make you study the masters. And, like, if you take a painting class, the first thing you do is copy different paintings in different styles to learn these artists' styles so that you can develop your own style. 


But when we teach software, we tell you plagiarism will get you expelled. Don't even look at anything outside of your paper. And that's crazy because when you get out into a career, your boss just wants the website to process a credit card. You know, she doesn't care if you wrote it all original code or if you had an AI, you know, spit something out. It doesn't matter. We just want it to work.


TAD: Or Stack Overflow, right? That's --


DAVID BRADY: Yeah, Stack Overflow. 


TAD: [inaudible 32:48] Stack Overflow exists.


DAVID BRADY: Yeah. And so Code Reading is literally a book on how to develop the skill of reading code. He makes the pretty bold argument that open source is just a godsend for us. He's like, yeah, you probably want to learn C. Now, this book is 10 or 15 years old. But he's like, you probably want to learn C because, like, if you learn just enough C to get around, you can now read the entire codebase of Linux and all of the tools that are in Linux because the source code is in C. And holy crap, right? It's like, you want to figure something out. 


And he throws a wild curveball, like, in chapter three or four. He's like, okay, write a program to calculate the date of the next Easter. You have one hour, go. And, okay, hang on. Easter falls on the first Sunday after the first full moon after the spring equinox. Oh, good luck, right? And he walks you through how you can solve this in 15 minutes if you know that Linux has a bunch of calendaring apps. And there's a function down in there called POTM, Phase Of The Moon. [laughs] And it will let you calculate what is the next full moon going to be? And it's hyper-accurate, and it works. I mean, it's good enough for the operating system. 


And you have to be able to surf into a million-line codebase and find the piece that you need, and then read that code in high detail and go; it's this. This is the math, and then this is the offset, and this is the thing. And you're like, okay, cool, and down the road you go. And you can build it out, you know. And that, I think, was a really, really good thing because he talked about the necessary grammars and patterns that you want to develop. 


Tad, you mentioned at the start that, you know, we'd start with Rails and then back up to general, and this is a perfect example of this is that when you're in a Rails project, there's a certain directory structure that you can expect. And there's a certain way that the resources are, you know, that we expect them. There's a naming convention for how tables work in the database. And if you switch from Rails to Django, that changes, or if you switch from, like, on the team that I'm on, we're all writing in Python. And we don't use a framework. We wrote our own stuff. But it is very rigid. 


There's a very solid process that we used for, you know, the way we get data from the database is standard. The way we transform it is standardized on our team. The way we load it into the warehouse is standard. And then, we write a custom piece for each of those three steps. But those three steps are very standardized at the interface or at the behavior level. 


And coming from Rails into this team, instead of saying, "Well, I expect there to be an app directory or a models directory and a DB directory," I'm just saying, "Okay, what is the structure?" Oh, the structure is we're going to have this directory, and under this directory, we have these subfolders with these files in them. 


And you, very quickly, you learn what is the layout of the forest? And that will tell you when you look at a tree, you're like, well, where is this tree? This tree is down in the model's directory, or this tree is deep in the ACL directory for this particular vendor. I'm like, ah, okay, I know where the holes are in this. There's going to be some holes in this file that are going to be filled in by the base classes because the app structure is going to take care of it for us.


TAD: So a follow-up question that I had is, it seems like both when dealing with legacy code and just any new codebase, your ability to just read code and have experience with code goes a long way. And I like your idea that there's tons of open source out there. But the thing is, like, they're not all masterpieces, right? 


DAVID BRADY: No.


TAD: There's some really bad open-source code out there. So my follow-up question is, how do you find the masterpieces in the sea of GitHub repos?


DAVID BRADY: How does that old quote go? If you want to find a prince, you got to kiss a lot of frogs. I would actually say there's an essential code reading skill, which is the ability to, as you are reading through this piece, gets this, transforms this data, sends this message to this object. At the same time, you're doing that low-level, like, almost, like, compiling the code in your head to find out what it does. 


There's also another thread in your brain that's basically assessing the quality of the code that you're reading. Like, is this code easy to follow? And is it easy to follow because it's very clearly written? Or is it easy to follow just because it happens to be in my preferred style? And I love the moments...like, I don't know if I would recognize a masterpiece if it smacked me in the face. But I do know that I become consciously aware of the feeling of pleasure reading code; that's how I'll phrase it. 


I find myself smiling when I read code that I simultaneously realize I understand this code, and it's in a completely different style than what I'm used to, which means, in the worst possible way for this code to try to teach me, it's teaching me amazingly well. And that, I think, is...I don't know if it's a masterpiece, but it's certainly the code that makes me the happiest. I'm like; I want to write code like this person because they're communicating to a stranger very, very well what their thoughts are and how they want to accomplish the thing.


TAD: Excellent. We're at the end of our time. So I'm going to...I think we'll just end on that and just encourage all of our listeners to go out and read some code, huh? 


DAVID BRADY: Right on.