Episode Details

So this is a little, um, analogy, metaphor. I dunno. A little thought experiment, analogy thing that I thought of recently, and it just reminded me when I was recording that, that last episode called a lovely refactor. Um, so wrapping your arms around a big tree. Okay. So like I expressed, I got a pull request that overwhelmed me and the pull requests overwhelmed me, but also my own code base overwhelmed me.

Like I hadn't touched, I hadn't. I feel like I don't know everything about the backend of Livewire right now. You know that that changes. The more you're working in a certain area, you understand a lot more. But over time, you know, it's like a sand timer thing, a code base, like you sort, you start to lose it gradually over time, and then as you work on it, you, you know, the sand fills back up and then it slowly drains out.

So this is kind of what came to me. I was thinking about, well, I don't really own this code anymore. This is, it's a, it's an unpleasant position to be in when you have to change code or work on code that you don't understand. Like there's too much stuff going on and you feel like you're wrapping your arms around a really big tree.

You want to wrap your arms, you want to touch your fingers at the other end, but you just can't, the tree is just too big. So I think this analogy works for a lot of things, like a Greenfield project, let's say. Um. It starts off as a STEM, just a tiny little sapling, and you can wrap your fingers around it on one hand and it grows and it grows as you build it, but you, you have full control over it.

You feel like, um, you know, every angle of it, all of those things. And so maybe good architecture, um, doesn't seem as important because you know, all the code. Um, and so I've seen this with even really big code bases at a company. Usually there is a, uh, a person who has been there forever. And who like wrote the thing and it's, you know, if it's a legacy 10 year old code base and they have their arms around the whole thing, I don't know how they do it.

It's a really big tree. So they must have really, really long arms, but they can make changes, you know, fast and, and um, yeah. But the changes aren't always architecturally sound and they're not necessarily thinking big picture architecture. Because they keep the whole code base. Maybe they're there, like the, the issue ticket guy, like you know, other, the, the new hires and the specialists and consultants are working on new features and other microservices.

But this guy, he's in the main code base and he's the one, you know, going through the issue tracker every day and fixing diverse parts of the code base. This is funny. I think it's, I think it's like a type, like in any longstanding code base or big or big company that's been around for a while.

There's this, this person definitely exists. Anyway, I say this to say that, um, that this person doesn't necessarily need good architecture or need as good of architecture because it's all in his head. Her, it head, um, doesn't need good architecture because it's all in their head. And, um.

Person. Now I'm hung up on the fact that I'm trying not to use the word he, because all the people I know that are like this are guys. Um, and I'm trying to use the VA when I'm saying this, but I don't know. Oh man. Oh man. Social, gender specific cities. Uh, okay. This person, this animal. Um, who is this way and wrap our arms around the code base.

Okay. So you have your Greenfield app and you have your hand around the code base. Right. And like I said, or whatever the size of the code base is, when you own it, you own it and you can wheel and deal and move code fast. But when that sand timer runs out. And you lose, like let's say your arms shrink.

So the arms shrinking, we'll be the analogy for, um, for how much, you know of the code base and the size of the trunk will be how big the code base is or how complex it