How Do You Break Up a Product Request Into Work (Part 2)

About this Episode

Here's part two of how to break down product work! In the last episode, we talked about how to break down product work, and talked about the 'why' and the 'when'. Today, we tackle the 'how'!

Transcript:

DAVID: Welcome back to the Acima Development Podcast. We are doing the part two of how to break down product work. Last episode, we were going to talk about how to break down product work, and we ended up talking about why and when, and didn't get into the how very much. I'm your host, David Brady. Today we're joined on the podcast by Kyle Archer, Ramses Bateman, and Eddy Lopez. And it's exciting to see you guys. Let's jump in. So how do you break down product work?

EDDY: You know, Dave, this has been lingering for me in my back pocket since last week. But I was getting over an illness, that I wasn't very productive in our conversation. As you may know, I'm an aspiring developer. Within the next few months or so, I'm hoping to actively be getting paid to develop and write code.

DAVID: Nice.

EDDY: One of the things though...and I see this often, specifically from a QA standpoint, where a company will ask you, they're like, "Hey, we need this huge and large and pretty feature. Oh, and you got X amount of time to get it done. You look at epic, you look at the subtasks, and it's like 30. [laughs] And now it can seem a bit daunting to look at all the subtasks that you need to tackle. What's your approach when you feel overwhelmed when you look at how big a project is sometimes?

DAVID: I do not want these podcasts to turn into me holding court with you guys because I'm honestly not that smart. Let me kick that over to Kyle and Ramses. How would you guys break that down? Somebody comes in and says, "Hey, we've got this big product, and you're in charge of it. You're the lead developer." Obviously, you've got to break it down somehow because you can't work on a 30-point story. How do you break that down into something smaller?

RAMSES: I think for me, it would kind of depend on what the epic is and then looking at the stories and seeing if we could subdivide the stories if it is appropriate to put them in thirds, halves, whatever it was. And kind of give some pushback and say, "This is great. This is a lot of work. We don't have enough manpower to get this done," and express what we could accomplish in that given timeframe.

DAVID: Yeah, I like that. In the last episode, [chuckles] I came up with a horrible metaphor. And it was because I was in the wrong aisle of the bakery. In my head, I was thinking it's like a loaf of bread. You've got to start at one end of the loaf and get to the other end of the loaf. And this was a terrible metaphor. And I apologize to everybody [laughs] who waited through that last line. Turn the loaf of bread sideways or on its end and imagine it's a layer cake. That's the metaphor that I should have gone for in the last episode.

For me, when I need to break product work down, especially if it's a big thing, you know, every business, not every business, but a lot of a lot of businesses, there's a central object that is like a document or a record of something. And it is the central artifact of business that your company works with, so with Acima, it's a lease. At CoverMyMeds, when I was working there, it was a prior authorization request, like somebody wanted to get a drug approved. These documents are at the center of everything.

New customers coming in they get attached to this document, or they're applying to get into one of these documents. And then they get approved, and they're now in this document. And then they're transacting the business of working through the contract of that document, and all the way until it's all paid off. And then it goes into history. And so there are all these events.

Let's say you're at a business, and you've got some central document like this. Let's say you're at a legal firm, and it's a contract. We have people coming in, and they want to get a contract. They need to create the contract, join, da da da. Okay, that's fine. And you got all these servers, and they're running software, and they're prosecuting the business. Prosecuting is a terrible pun. Sorry, it was not intentional, but I am proud of it. Transacting all the business of processing this contract, right?

Product comes to you and says, "Hey, we need a separate logging service. Anytime something happens to a contract, we need you to go to the master contract server and pull down the main copy, like, the original copy of the contract. We need you to amend the event, attach the event to it, and then store it back into the system. And we need you to do it in a separate service." And so you're going to talk to the contract server. You're going to get this thing. You're going to add these events to it, and then you're going to push these events back up into some other service to record them. This is pretty straightforward.

Anybody that's worked in kind of a service-oriented architecture has been given product work where it's, hey, talk to this server, and that server, and that server, and do something that those servers can't do on their own because they can't see each other. They don't know what the other server knows. So your little job here is to talk to all three to have the knowledge that comes from all three of those things and do something with it. This is pretty straightforward.

The metaphor of a layer cake for me comes about because instead of just looking at the top layer of the cake and saying I'm going to build the top layer of the cake, the very top layer of the cake, is we're going to build the thing that downloads the contract from the main contract server. And we're going to build that piece of software, and we're going to build it complete. We're going to get every single field. We're going to get every translation bit. We're going to decode the thing. It's encrypted, so we're going to put an encryption key. And all of this is put on there.

But you don't go to the second layer of the cake until the top layer is completely finished. And so you end up with building this thing that can handle everything about understanding this contract that you've downloaded and how to get it from this main server. But the things that you need underneath, just one layer down, don't exist yet. And so you don't have a cake. You don't have anything that you can serve on a plate and eat.

This is how we did software in the '90s. You hear people talking about waterfall where you design everything, then you write it, then you debug it. You don't write code while you're debugging that kind of thing. The layer cake idea is if you want to take a piece of cake and serve it, you want to serve up a slice of cake as quickly as possible. And that means you've got to write just enough of that top layer to connect to the next layer down, and you got to write just enough of that to connect.

So you might sit down and go, okay, I'm going to connect to the main contract server, and I'm going to download the contract. The contract is encrypted. I don't care. I just want bits off of that server. If I can prove that those bits did not come from my server and they came from that server, that's good enough. So we pull this thing down.

There's some piece of the contract that's going to be unencrypted, like the ID number or something like this. If I can get the ID off of this thing, great, I'm in business. We go down to the next layer. The next layer is something that's going to decode or actually just parse the stupid document. So we're not even going to worry about the encryption piece. We're just going to decode can we find the ID field in this document? And then we go down to the next layer, and the next layer, and the next layer.

And eventually, you've got this super, super thin, tiny little application. It's not even an MVP, minimum viable product. It's so much less than an MVP, but it goes full stack from the top to the end, from one end of the cake to the other, or from the top of the cake to the bottom. It connects to the main server. It downloads the contract. It parses out the ID field.

It figures out, oh, I want to attach an event to this. It gins up an event, which just has an ID and a created at, like, there's no event information. It's just the minimum. What's the smallest event that we can create? It's just got an ID and a timestamp. That's an event that exists but has no other useful data. And then, we upload that event to another server.

And for this minimal piece, we're just going to connect to the event server. We're not even going to shove up the event that we created. We're just going to shove up an event with an ID of 42 and a created timestamp of now, and that's it. That's your entire slice. And I've got a really, really dangerous question for you guys, which is, why is that insanely useful? Or, if you prefer, tell me what goes wrong in building that? What problems are you going to have to solve in order to get that entire piece of cake put together?

I worry that I've told the story carefully enough that you guys might feel like there's one right answer or one wrong answer, and there isn't. Have any of you guys done software where you take this vertical slice like this, and if so, was there something really surprising that wasn't in your master ticket, you know, the epic story that you have to break down that you found out by building this thing?

KYLE: I think what I've seen when I've kind of approached it like this is it can be both beneficial and, I guess...harmful is not the word. But I'm trying to think of the word I'm wanting here, but detrimental, there we go. In the sense that when I'm doing a vertical like that, I see stories that are both missing and are both unneeded as I'm going along that route. So I think that's kind of the danger of doing it that way for me.

DAVID: Talk to me more about this because I'm literally sitting here bouncing up and down on my chair, going it's not the defect. This is the feature of this approach. Talk to me about running into these missing and needed stories. What does that look like? How does that feel? And how do you deal with it?

KYLE: I'm trying to think of how to respond to that. It's just...because you're going along and you just realize that...I'm trying to think of an example right now. But it's not going to quite work the way that you're wanting to. Maybe there's a faster protocol that you can use, so that's adding something, right?

DAVID: Mm-hmm.

KYLE: Or maybe you're realizing that you can't transfer as big of a file as you wanted, you know, there's a technical hurdle.

DAVID: Bingo.

KYLE: There's a legal hurdle. There's a security hurdle, you know, different things can get in the way. But as you're going along, you're learning, and you're also realizing what would make the feature or the system better so you can see where adding a story would be beneficial.

DAVID: That is exactly, exactly it. When we look at these layers in our head, or we think about these layers, we often think about, okay, inside this layer, I got to do this, do that, do that. And then you go to the next layer, and you think about what's going to be in that. And you don't stop to think about, wait a minute, how is this layer going to talk to the next layer or the one above? What are the implications of this?

And when you take a slice vertically through the entire problem space, those things jump right out at you. Right off the tip of the bat, you find out that, oh, you can't connect to the main contract server without a username, password, and encryption key. You don't have one of those. You've got to go to IT and get an encryption key. Like, oh, we don't have a story for that. But we've got this other story buried way, way down off the side. That's the entire communication between the contract server, and your service, and the service, and the eventing service, all have to be secured with encryption. Okay, fine.

And we've got this big sub-epic kind of an epic of itself which is to dig into the encryption and figure out how we're going to encrypt all these packets back and forth. And as you're struggling with this, you go to lunch with somebody from IT. And you're telling them about the headache that you're having with this.

And the person from IT looks at you, kind of cocks their head a little bit, and goes, "Why are you doing that? You know that this server is on a backplane all by itself. It's inside a LAN. I mean, literally, there's a physical wire dedicated to the communication between this server and that server. And everything that goes on that wire is encrypted at the hardware level, like, we built it that way. We built it that way for you. Why aren't you using this?"

And you realize, oh, the application encryption it's done. This entire story is wasted heat for us trying to encrypt packets that are going on an encrypted transport protocol. I, four or five years ago, worked on...and don't quote me on this, guys, because I'm not a security guy. [chuckles] But we had a whole bunch of services that needed to talk to each other, and we needed encryption over them.

And then we stepped back and realized we're doing all of this over HTTPS. And we're like, wait a minute, does this secure everything that we need? And we went back and like, why do we want this encryption? And we're like, somebody eavesdropping here. Oh, yeah, that's hardened, that's encrypted. Anybody eavesdropping on that wire is going to get encrypted packets, to begin with. It doesn't mean you're safe. You never think that with encryption or security. But to whatever degree of safe enough, we were already done, and we were just wasting time.

The opposite end is you come across stories that don't exist that you need. You need the encryption key to talk to the server, or you need an account on that server to download the contract. Or you run into a fun thing where your service talks to the main contract server. How does it know which contract to update? Well, it goes to the database, and it looks for things that have changed; okay, that's fine.

But unbeknownst to us, the eventing server, every time it gets a new event, it updates the timestamp on the contract to say you've been updated. Now what's going to happen the first time you try to tag an update and attach it to a contract? I'm grinning my evil grin. What's going to go wrong here?

KYLE: You create an endless loop.

DAVID: Exactly. You come in in the morning, and the server room is 140 degrees. And all the servers are spun up CPU bound. And they're literally, oh, I got a new event; I better attach a new event. Oh, I got a new event; I better attach a new event. Oh, I got a new event; I better...right? And they're just going, and going, and going. You don't have a story for this. And you're like, oh, how did we write it? We haven't even written the software. How do we already have a bug? [laughs] This is a bug that is in code that doesn't even exist yet.

It's because you sketched out how the thing was going to come together. You overlooked the fact that when we push this event on, it's going to update the contract. So, oh, okay, it turns out that we misunderstood the problem, and we're going to have to address that somehow. And you find that out when you take that little vertical slice. You serve up the thinnest slice of cake that you can. It doesn't do anything useful except it connects all of the pieces together, and that's immensely, immensely useful.

KYLE: And based on your example, it sounds like we got a decent load test on the server to know whether or not it'll stay up.

DAVID: [laughs] Yep. Yeah, yeah. If you come in and the server room was ice cold because the hard drives all gave out six hours ago and they've all powered down, we've just discovered a hardware condition that we might want to deal with at some point, yeah.

KYLE: Yeah, not production ready at all.

DAVID: Mm-hmm. I worked at a shop years and years ago that Amazon was...they call it something else now. But at the time, they had a product called RightScale. And this is at the beginning when EC2 and cloud computing was brand new. And what RightScale was was this ability that if you gave them a manifest like a Docker container...this is before Docker existed. But you gave them some way to define a new server. At boot-up, it would connect to a load balancer. Okay, that's great.

Now when your web server gets overloaded or starts running at 80%, 90%, 95% CPU, Amazon takes the template for that web server, spins up a new one, boots it up, connects it into the web load balancer, and now you've got another web server. And if those servers go up to 80%, 90%, 95%, it would spin up another one, and another one, and another one. And it was fantastic.

And this is back in the beta of EC2 when you could only have 100 instances total. That's the dark ages. Now if you don't have 1,000 servers in the cloud, you're not a real company. But we set this all up. We went home. Literally, it was like a Wednesday, and we went home. And we came in on Thursday, and the CEO is pacing back and forth, and he's like, "All of the servers are spun up. What the hell is going on?"

We go upstairs and we log into the console. And sure enough, we're getting errors from EC2 saying all your servers are spun up. They're all at 95%. And we're like, oh crap, oh crap. What do we do? What do we do? So we start diving into them. And we log in, and they're getting traffic. They're getting real traffic. We're like, what the hell? We needed two web servers yesterday, and now we need 100. What's going on? I mean, they got to be talking to each other or sending a loop to each other like the contract thing. What is this? What is this?

It was one of those perfect timing moments because we're pacing back and forth, and the CIO shows up at like 8:30, walks in the front door, and he's like, "Hey, did you guys see the bid on Oprah?" The company had literally been on The Oprah Winfrey Show the night before. And our servers had been getting pounded all night with real traffic. And the CEO went, "Wait a minute, this is all making us money? Heck yeah." It was fantastic. So yeah, occasionally, you hook something up, and it works correctly. And that's even more terrifying [laughs] than having it go wildly wrong.

EDDY: I'm just curious, have you ever found yourself in a situation where you felt you needed to push back when the breakdown of the work that was given to you was unachievable for the deadline that they're giving you? Because that kind of goes back to the whole how do you manage the workload? And so, in the event that is unachievable in your career, have you ever pushed back and said, "No, this can't be done?"

DAVID: I'll tweak the question a little tiny bit. What happens when the workload is just shaped wrong, when it's too big for the calendar, or they pulled half your team off to go work on Project X, which is the secret initiative down on the other department, but your workload in your calendar hasn't shifted? How do you deal with that?

KYLE: So I've been at a few companies, and they've all practiced their own...I feel like Agile and Scrum are used as buzzwords, and they're all practiced a little bit differently, regardless of where you're at. But one thing that I've seen that's kind of been common is everybody sizes. Everybody sizes things based upon your team's efficiency. And some teams use points; some teams use shirts. I had a team that used is this a pebble, or is this a galaxy?

And it was one of those things where during planning or after investigation, it was one where we'd go back and say, "Hey, this is no longer a pebble after researching it. This is a moon. This is going to take us much longer. We're not a moon team, you know; we're a mountain team. We can't get a full moon done in one sprint." And you'd have to go back and give pushback on that. And I just think that that sizing situation gave them a better understanding.

Because the people asking for the work generally are product managers or whoever it might be. And they're like, "Oh, this is just an easy feature." "This is just putting a new button on the webpage," or "This won't be that bad." And they don't understand the scope of the work. So that's kind of what I'm saying there is like, once you're able to put it in terms they understand as well, it's a little bit easier to push back too.

DAVID: There's a great thing that you're touching on here, which is that your product owner is somebody who's looking at your backlog. And they know that you have a velocity of 27.4 fiddly bits or whatever the velocity points are. And if your backlog has 12,000 story points in it, you're not finishing that in the next two weeks or three months or whatever.

I have worked in environments years and years ago where nobody had any idea when things were going to be done. And the closer we got to a deadline, the more management would come browbeat the developers. And I kind of got in the habit of just shrugging and telling my manager, "This takes as long as it takes. I'm giving you my best possible work. But I am one person; I can't make time." And sometimes, that was a difficult conversation.

I've had people that are like, "Well, make it happen. I don't care what you have to do." And I'm like, invent time travel, I guess. If that's really your management style, then I suggest you go cut a purchase order for a time machine. I'm going to need some resource support on that. The move into agile...and I like what you said, Kyle, about Agile with a capital A and a TM at the end of it is a product that we sell to teams. And then there's this idea of lowercase agile, which is just like the concepts underneath it.

But I did a Scrum training years ago, and I'm not a super big fan of Scrum. But I did the product master or something rather exceptional or whatever. Scrum is [chuckles]...they've got a whole certificate tiering racket going on. The most useful thing I think I took away from the Scrum training was this exact question of when we groom the backlog, and we find out that we thought this was going to take six weeks, and we've groomed the backlog, and it looks like it's going to take 18 months, what do we do?

And the Scrum trainer grinned an evil little grin and said, "You don't do anything. It's not your job." Your job is, to be honest. And it's your product owner's job to figure out what to cut off, and where, and what is more important. What do you want to have first? And she said something that I have carried around with me ever since. She said, "The framework creates transparency, and transparency is a bear." I love that quote.

Because, yeah, you sit down, and you say, "There's the backlog." Somebody comes in and says, "We need this done in two weeks." You pull up the backlog, and you say, "There's the line. I can fit this much stuff in the next few weeks. What stuff do you want in that box?" "We'll take that piece out and put this piece in. And oh, this piece that I've been telling you for six months is absolutely necessary turns out it's just UI tweaking. What we actually need is the ability to bill a customer, and we don't have that yet." So the important stuff suddenly gets put into the box, which is really, really great.

So I don't want to sound like I'm smug or defiant with the product team. But I am saying that there's a boundary violation here. It's like business' job is to decide what's important and what is first. And technical people aren't allowed to make that decision. It's not our responsibility, but it's not any of our business to decide what is first. But conversely, the business folks don't have any business telling the technical people how hard it's going to be or how long it's going to take. I tell you how much it costs. You tell me if it's worth it to pay for that, to pay that cost and if it is, we work on that first.

KYLE: I was thinking, like, that's what a lot of this is when you're in planning is it's almost a haggling situation. You're sitting there trying to say, "Well, we could get this much of this feature done or this much of this epic done." And they're going, "Well, that's not enough." "Well, okay. How about this? Can we do this?" And you're kind of haggling back and forth. And while you're doing that, you're also pointing out, well, this is going to put us further into technical debt, and you're vouching for the technical debt that you want to get done.

And it's this weird situation where you get into engineering, and you don't realize that part of your job is going to be sitting there haggling with the business over what you think is important to keep the business running and what product or the business thinks is important to keep running. Because new features are fun and shiny, but you got to keep the core up. Otherwise, if the core fails, then the business fails.

DAVID: Everybody hates legacy code, not me. I love legacy code. And the reason I love legacy code is because that's the stuff that writes my paycheck. That's the stuff that's making the company the money that the company pays me with to work on the cool, new features. So I love legacy code.

KYLE: As long as it's not spaghetti.

DAVID: How do I put this? You can love someone and hate what they do. [laughs] So for me, sitting down with some code that was written...I've mentioned this on another podcast, but I literally had to maintain some code that was written to win a bet. Like, the architecture was a bet. He basically said, "I can do this with one line of code." His team partner was like, "No, you can't."

He then re-architected the way the modules talk to each other so that one module cascaded into the next one so that you could just bring them up in a chain. And then you could just do objects dot map, dot inject, dot, dot, dot, dot, you know, and it was a long one-liner, but it was a one-liner. [laughs] The guy who wrote this is legitimately one of the smartest people I've ever met. He and I have had multiple conversations where he's like, "No, that one line of code was also the right line of code. It was the right way to solve it."

And my repeated concern with that claim is that that one line of code is impossible to maintain. We cannot ever change that one line of code. We will rework the entire rest of the application to support that one line of code because it's just burned deeply, deeply, deeply into the architecture. Everything is in support of that one line. I'm okay with that.

When you build a house, you've got to pick which walls are load-bearing. And that one line of code is absolutely the king truss load-bearing wall of the application. Yeah, you can get a piece of code. Anybody that worked in Ruby 10 years ago knows what it's like to have to maintain a PHP app with spaghetti code and servers that crash and don't give you error messages because you've got error reporting turned off in PHP and all of that fun stuff while working on the shiny, new Rails app that's going to replace the PHP.

And you get around the water cooler, and you're just like, oh, I hate this code. I hate this code. I hate the old codebase. I can't wait to work on the new codebase. And I've been there. I've done that. And then, a couple of years later, we were standing around the water cooler, and we were working on the 2.0 version of the Rails app. And we were just lamenting how awful the 1.0 Rails app was. And I'm like, oh, I hate working on the old code. It's not going to be like...the new code is going to be so much better. And I'm like, wait a minute, didn't we just leave this party?

So yeah, legacy code, by definition, is insufficient to the new needs because people that wrote it weren't psychic. They don't write it for future us. Anyway, I can hate the way legacy code is written and still love the fact that...I guess what I'm saying is maybe I don't love legacy code so much as I love paychecks, like a lot. I really, really like that part. I don't think I would do this job if I wasn't getting paid. [laughs]

KYLE: To kind of tangent off of what you're hitting on there, I think that's something like you said, it's water cooler talk. It's the running joke; oh, I don't want to go work on legacy code, or legacy code is so terrible. Well, the reason is because of situations like that where it's like, you've got this one line that does so much or a block of code, we'll say, file of code, doesn't matter. It does so much. And it's either so old, or there's something about it that makes it difficult.

But you telling another engineer, "This is horrible. This is going to take me forever to do," that's one thing. But somehow translating that and explaining that to product or business-like, oh no, this is going to take two to three times longer because it's a change in the old codebase, that's something that's a little bit more difficult to explain to these individuals. Because it's the same thing to them, you know, depending on the individual, but it's the same thing to them. And how do you get them to understand that situation?

DAVID: Honestly, I've had this happen a lot where you have this exact problem where it's like, oh, we can do this in four hours in the new codebase. But this is going to take us three weeks in the old codebase. And like, oh gosh, what's going on? Well, there are two big things that are going on; one is the essential amount of complexity. You're backing on to 70,000 lines of code versus backing on to 1,500 lines of code.

The 2.0 app doesn't do as much. The stuff it does do, it does beautifully, and it does elegantly, but it does it uncomplicatedly, if that's a word. It doesn't have to negotiate with all these other things. And then the other thing is there's often process that throws in. It's like; I can sit down and cut a feature on the 2.0 Rails app. And I don't have to do SOX compliance. I don't have to run this past QA. I don't have to run this through three separate code reviewers because it's this greenfield project.

There's no money depending on this. There's no auditing legislation that's going to lock us down, and you wouldn't want that. If you're cutting a new greenfield app and you're cutting that first slice of cake, you don't have the ability to pull that document down at all. Auditing for SOX compliance is a bad idea. That's going to slow you down and give you nothing in exchange.

Things like SOX compliance or other types of compliance auditing are there to keep you from breaking something valuable that exists. And when you're doing a greenfield application, there's nothing valuable that exists. You're building [inaudible 29:06]. You're just spinning code out of whole cloth. And so we often have the ability just to move faster.

But I really think it comes down to just...it's not that legacy code is inherently terribly complex. It's just if you've got a seven-year-old app that you're building against, there are seven years of history. And it doesn't matter if that history is really, really good or really, really bad. I mean, it does, it does. I'd rather have seven years of good history code to work on than seven years of bad history. But seven years is still seven years. There's a lot of stuff to pick up and learn and hold in your head.

And it's really hard to go through that and groom it so that we have borders that when you pick up this piece of the legacy code, you don't have to think about this other piece because we've built a wall between these. There's an interface here, so now you don't have to think about this. Where previous to putting in that interface, if you picked up code on this side, you had to be thinking about code all the way around it.

In that little slice of cake, we update the contract, and that updates the contract, which causes it to show up in a loop. And now we've got a new problem. And you get these surprising things coming in out of the side. And when you've got legacy code, seven years of legacy, it's all blindsides. You can't look around without getting hit in the back of the head by a piece of unexpected code. When you're building against ten times the size of a codebase, there's 100 times the complexity.

And I guess this is the dangerous thing that I'm saying, the code that we're writing right now here today if we don't have a dramatically changed idea of how to write clean code, or maintainable code, or good code, or well-tested code if you don't have a really clear idea of that, then the only thing you know for certain is that you're writing more legacy code. Two years from now, you're going to be hating this code. And some of that is experience, and some of it is unavoidable, I think.

Because you today don't know what's coming down the pipe two years from now, and you shouldn't. The entire Agile principle of YAGNI "You aren't gonna need it." Leave things unsupported until you need them because two years from now, you're going to be going through the code, maintaining some module of code that doesn't get used, and nobody needs it. Nobody wants it, but it's in the codebase.

And you're renaming some variable, or you're changing some API, and this module uses that API. It's poorly tested, or it's not tested at all. And you get into it, and you find out that this is using the API wrong, but I have to update it to use the new API correctly, and that, yeah, it's terrible. I'll stop talking about YAGNI. YAGNI is bad. Don't do YAGNI.

EDDY: You know, David, you touched on something that I kind of want to elaborate on. And this might be a topic for another podcast. You were talking about legacy code, and it kind of sparked an interest on how do you get familiar with a company's thousands of lines of codebase without getting overwhelmed? Because that kind of touches on it also. Do you recommend to get familiar with the overall design and architecture first and then you get familiar with the specific details of the code as you progress, or? Because I feel like there are some elements to the way work is divided.

DAVID: We are getting close to the top of the hour, so I've got a short answer and a shorter answer. The shorter answer is we should do a whole podcast episode about working with legacy code. I think that would be fantastic. The short answer is two things, one; you should go get a copy of Michael Feathers' book "Working with Legacy Code." That book is like 10 or 15 years old. I haven't picked it up in about five years, but I picked it up five years ago, and none of it was out of date.

It's dramatically profound the kind of stuff that he tells you. He literally tells you how to work with code that you don't know anything about. And I've really learned how to keep my elbows in when I'm working on code, how to edit a piece of code without affecting the next file over or the next module over or altering the interfaces. And I got that from that book.

The other piece of advice is read, read, read. Go get a project, download it, and then read the architecture and go, oh, that's how you're doing that. And then put that project down, pick up another project, read it, and go, oh, wow, they're using recursion here instead of for loops. That's weird. And you go along for six months, and you start using recursion everywhere until your teammates have an intervention, and they pull you aside and say, "Dude, please just use a for loop here." And you realize, oh, there's a good place for a for loop, and there's a good place for recursion, and I'm using them everywhere.

And yeah, read as much code. Your ability to navigate an existing codebase is largely determined by how many different patterns you're familiar with. So go get a new piece of software, download it, read it, lather, rinse, repeat. And look me up in five years, and you'll be a whiz at it. You won't be a whiz at it in five months. You got to stack as many arrows in your quiver as you can.

All righty, we're at the top of the hour. Thank you, guys, for coming. I really appreciate it. Kyle, Ramses, Eddy, this was a lot of fun. Be good until next episode. We'll talk to you guys later.