As a software engineer, your craft is going to grow over the course of your career, and it's going to grow usually in these big spurts, leaps and bounds. And early on, especially, we see that rate go super fast, right? We learn a lot very quickly. and so we start building and if you're using ai you're building even more than uh you know many people who came before you built and you see things are working and um and we have this enormous amount that we that we output especially early in our careers and there's a lot of complexity associated with this work and what you'll notice from people who've been doing this for a long and in your own progression in your career is as you become more skilled in the craft, as you become a better coder, as you become a better architect, as you become a better tech designer overall, a better systems thinker, your systems and your code and your architectures will become simpler. It seems kind of counterintuitive on its face. You would think that as we grow, as we become more capable, more powerful, as we become better engineers, that what we can handle, the level of complexity we can wrap our minds around, gets more and more complex and therefore the things we create get more and more complex. The truth is exactly the opposite of this. Even though we could handle this complexity because we've been exposed to it, we tend to create things that are less complex. There's a bunch of reasons why this might be happening. There's not any one specific reason why this happens. It tends to be the case that complexity goes down. It's not always the case. So we're kind of talking in generalities here. But I want you to explore this idea with me because I think it's very interesting and enlightening and it will help us grow in our careers if we can emulate some of these reasons, if we can kind of wrap our our learning around why, you know, why does this complexity go down and try to drive ourselves to the core reasons why. Instead of just trying to create simpler things, if we can understand why this tends to happen, then we can shoot after those, you know, kind of core driving reasons in order to arrive at that more organically. Okay, so simplicity is not necessarily the goal. There are some good effects of simplicity. One of them is very clearly, the simpler things are easier to understand. Why is this valuable? Simpler things being easier to understand means that younger engineers who pick up your code are going to be able to work with it a little bit easier. You in the future, when you have moved on from this project and you're coming back because it needs to be maintained, you also can understand it. Being able to change things in the future, being able to change things in the near term, adapting a simple thing tends to be easier than adapting a complex thing, right? So these are kind of positive outcroppings and some of this actually tends to be part of the reason why we tend towards simplicity as we grow in our careers and in our skill sets and our craft, because we know the pain of a large refactor of a complex system. to that before. And so we naturally kind of adjust our thinking. And some of this behavior is driven by the fact that because we've had that pain, because we've been exposed to the refactors, we naturally don't want to do that anymore. And so we start making trade-offs, right? So for example, example, you know, one kind of complexity might be, and, you know, a very large number of abstractions in our code. And at some point, we may have built something that felt very, you know, elegant or complex, you know, that managed all of these different, you know, broad abstractions, and a lot of detail that gets passed through multiple classes or something like this, right? and there's some kind of, maybe early on in our careers, we feel like we've kind of mastered this design, but then if we went to change something, if we went to add something, we have to re-understand, we have to re-grok, we have to re-load all of this context into our minds. Otherwise, the abstraction ends up being so abstract that the thing that we're trying to do, way down the line in the abstraction, we can't quite understand exactly how far abstract up the chain we need to go in order to make the change that we need to make. And so very often one of the refactors you'll see a more senior engineer do is collapse abstractions, especially collapsing these long kind of vertical abstractions that only exist in one place, right? It's abstraction, but it's not being reused. It's only one line of inheritance. So that's a little more technical than we normally get on the show, but that is the kind of thing that increases complexity and doesn't necessarily, you know, the Yagni principle tends to come into play very heavily when we're talking about complexity avoidance. You aren't going to need it. And so let's not even put it in there. So this is an interesting effect because what we learn early in our careers is to try to hedge against all of these risks. As we develop in our careers, eventually we refine our risk tolerance. We learn that some risks are actually okay to accept. or we learn to allow our code to stay flexible in the future, but not try to build in a bunch of arbitrary complexity or flexibility that adds to the complexity now. So maybe we'll need an abstraction, but we don't need it now. We only have one example of this. We only have maybe two examples of this, or, you know, this, it's easier to just read all of this code in one place rather rather than in three different places and trying to kind of glue those together in my brain. And so some of this, you know, reduction of complexity is understanding when to break the supposed best practice rules. So yeah, maybe the best practice is to abstract this, but actually, it's not that hard to understand. And I know what the abstraction would give me in theory, I could probably get that by just thinking about it a little bit differently or controlling my global variables or my scope or naming things well or, you know, kind of simplifying things a little bit in a different way. Similarly, knowing when to break the rules about risk. Yeah, theoretically, that risk could occur, but the likelihood is so low. And the cost that we incur in order to hedge against that risk is just insurance. insurance. It's really expensive insurance because we're going to end up being really slow or we're not going to be able to onboard people into this product. And it's going to take us a lot longer to, you know, to do anything meaningful. And so, you know, we can either have a slightly more risky product up to some, you know, reasonable threshold. We could have a slightly riskier approach to the code base and move quickly, or we can grind to a halt, right? And because, We're going to have to only hire people who can deal with all of that complexity. There's a couple other reasons why this happens. One is that the more senior you become, the more kind of essential principles you're able to understand, right? So in other words, you know, the core of an idea, you can get to the core of the idea rather than having a bunch of scaffolding around the core of the idea that is supporting it without you really knowing where the core is, right? So in practice, what this looks like is, you know, you may have, for example, you may add a bunch of libraries in order to accomplish some kind of, let's say, a web server, right? But if you understood, you know, the core, then you could probably strip away a bunch of those libraries. You may not even be using them. They may come by by default and some kind of package that you included or whatever the thing is. And you may be able to reduce the complexity or similarly kind of flipping the script there. You may realize that, oh, you know, there's, there's, and this is a very common thing for seniors to take this, this kind of trip to initially say, oh, we don't want to use these external packages at all because we don't know what's in them or because there's a bunch of stuff in there that we don't use. And so we're going to write some things ourselves, right? And now the complexity ball grows because you are writing a lot of the stuff that is otherwise handled in these external things. And now you're having to maintain essentially like a shadow subversion of whatever that other package was anyway, right? And so, you know, a more senior your engineer might say, well, the complexity trade-off is probably worth it. It's probably worth it for us to just use this other thing. They maintain really good documentation. Maybe our delivered code size increases a little bit, but ultimately this is going to simplify our development processes significantly. Let's just adopt that thing and take some of the costs that we incur and move forward so that our code, the things that we're responsible for, get much smaller, right? And what you're probably going to notice here is a lot of this tends to be trade-offs and the more senior you become in your craft, the more your trade-offs tend to reduce the surface area, right? And this tends to have a focusing effect because now you're responsible for fewer things and the fewer things you're responsible for, the easier it is to focus and do those things very well. And that is one of the core factors. And it's not really, there's no perfect evidence for this, but it's very possible that the behaviors that allow you to focus and reduce your responsibility spread, the things that you have to maintain, reducing your maintainability spread, those behaviors may be what actually got got those people to those senior roles in the first place, right? Or it could be that they learned that by being handed more responsibility and it's kind of a chicken and egg thing. There's not really any good data to say one way or the other. What is true is that in most cases, as you grow more senior, as you develop your craft, craft, the simplicity of your work will continue to reduce the surface area that you're responsible for, allowing you to focus and really stay kind of zeroed in on the things that mostly you should be responsible for and removing the craft from those things. You know, we started to kind of talk about the idea that you understand the principles and you can imagine that, you know, what this is really talking about is instead of having, you know, individual pieces or mechanisms that accomplish something, you understand more about what is needed, you know, what you're trying to accomplish, right? You know, a good example of this in another world might be, well, you know, we have this variety of physical machinery, right? So we have a ramp and we have have a screw, and we have a rubber band, and we have a motor, all these things that we put together to make a machine. And so this machine accomplishes something, and we know about all the parts. We know how to maintain all the parts. A more senior craftsperson would say, well, this problem that this machine solves is fundamentally, at a principal's level, It's fundamentally about conservation of energy. So we might be able to use these parts, but what if we kind of reconfigured and we really only need one or two rather than seven or eight, right? And the fundamentals get solved and we can kind of avoid having to maintain those other five or six parts. What if one of those breaks or what if one of those, you know, becomes expensive? We have to teach other people all of these other moving parts and pieces. It'd be a lot easier to teach them two or three of the moving parts and pieces. And by the way, we're not really trading off a lot in terms of the effect, right? Maybe those other pieces, you know, accomplish the goal equally, maybe even slightly more efficiently, but we gain a lot more by reducing the complexity because now we're down to the fundamentals, right? So drive to the fundamentals, drive to the principles, understanding the principles of the design that you're building? What is the real economic trade-off in the design that you're kind of establishing and in the systems that you are controlling? These are the questions that a senior craftsperson is asking, and it's what leads them to create more efficient and smaller, simpler systems. Thank you so much for listening to today's episode of Developers. Hopefully this was enlightening, but also challenging in a good way, maybe motivating you to go and think about, okay, what am I responsible for that I could simplify? How can I get to the core of the thing that I'm trying to understand? Get away from the tactics or all the surface level stuff, get down to the core of it and really focus on doing the core really well. Thank you so much for listening. This episode and every other episode of the show is available as a podcast. course, we have a YouTube channel that's been up for, I'm not sure exactly, a little over a year now, I think. And this episode will be on YouTube as well. So please go and check it out there. Thank you so much for listening. And until next time, enjoy your tea.