In the last episode, we talked about building for change. The fact that change is indeed inevitable in this episode. I'm going to give you some specific ways of thinking to help you build for change, to help you be prepared to build for change. My name is Jonathan Cottrell. You're listening to Developer Team. When we talk about things changing, perhaps the meaning of this change will be different for each person listening. And so I want to go over some of the different ways that things change. Specifically, it's likely. This is a very common way that software engineers specifically imagine that their work will change. We imagine scale. This is the most common trap that engineers face. We imagine scale. We imagine that either or both, that we will scale on the number of users or demand or some kind of external input into our software, and that we will scale our team size more people. We imagine that the product itself will grow. Whatever it is that we're building, it's going to become more complicated. There's more features involved. There's more complicated use cases involved. And so this is scale on essentially all axes. We imagine that the scale will inevitably, inevitably, require scaling our team. It will require dealing with more input, dealing with more traffic, more usage. And it will require providing more features, providing more actual kind of functionality in our software. So this is what we tend to imagine when somebody says prepare for change. We imagine being ready for scale. And this intuitive model does kind of make sense to our brains, makes sense why we would think this way, that by default, as there are more customers, there's going to be more input. As there's more customers, there is more demand for new things, new features. Maybe there are new use cases we haven't covered yet, you know, in an early version of the software. And as we get more customers, we're going to have to cover those use cases. And in order to, to respond to this demand, in order to build for these use cases, we'll have to grow our team. So this all kind of tracks with what we imagine to be the natural progression of a company. The truth is this is only one model and the scales that we provide there are not inextricably connected. In other words, it's very possible that you might scale on one of these axes and not all three. But I want to help you kind of shift your mental model of what you think is the most important thing in your business. So I want you to think of when somebody says prepare for change, instead of kind of implicitly replacing that in your brain, when you hear change, replacing that with scale or growth, instead of imagining that as kind of one in the same thing, when you hear future change, when you hear staying flexible for future change, I want you to equate it to two concepts, two concepts. One is adjustment. The second, is maintenance, adjustment and maintenance. These two concepts, these two categories of change cover essentially all cases that you will have to deal with. If you can answer these two fundamental questions, how do I plan for future adjustments and how do I plan for maintenance, future adjustments and maintenance? And here's why I'm choosing these specific words rather than thinking of scale. Scale. Scale is a very specific type of adjustment. Scale doesn't give you a sense for when, for example, your product needs to pivot, or maybe you need to cut out features in order to serve your customers better. Maybe you cut down on your feature functionality in order to scale up on the number of people that you can serve. Adjustment happens in response to all kinds of inputs. Whether that is a change in your team, a change in the market, something that you can't predict. Maybe it's a change in your mission, your vision, the company. There's so many things that you may need to adjust to. The second type of change, maintenance, is critically important. And it's very often the one that is left by the wayside. We imagine that scale and maintenance mean the same thing. If we, if we scale, then we must necessarily create maintainable paths. And in some ways, once again, the logic makes sense. We can't really effectively scale our companies without creating maintainable systems, creating maintainable software. But I want you to explicitly think about maintenance as a category of change. Particularly, I want you to think about maintenance in a totally different way. We'll probably do another episode on that. We'll probably do another episode on maintenance in the future. The vast majority of the time that you spend on a given project, the vast majority is maintenance time. Now, this doesn't necessarily mean that you're going to spend more hours working, you know, trying to debug something or trying to fix a, you know, a version or something like that. More time doing those kinds of tasks rather than building new features. That's not the point that I'm trying to make. Instead, the phase that your software is in, uh, once you launch, right? Let's imagine that you had three people building that software and your company succeeds. Those three people building that software of the course of, let's say, I don't know, six months. Let's imagine you grow to, for the, for the sake of easy math, 36 people, 36 people. That means that in a given, in a given month, you're spending twice the amount of total human time in a maintenance phase than you did in those initial six months. Now, to be clear, that's not calendar time. That's just human time. Uh, 36 people times one month is 36 human months. We're just kind of creating our own, uh, our own unit of time here versus three people times six months is 18, uh, human months. And so, uh, uh, uh, uh, uh, uh, the point that we're making here is that the vast majority of your time in your software is going to be spent post build. It's going to be spent maintaining, dealing with change over time in a maintenance phase. For this reason, it makes sense in those early, uh, those early decisions to try to calibrate, calibrate your tooling, calibrate your kind of design philosophies, specifically, imagining how does this translate into maintenance? Now, this doesn't mean that you have to over specify. We're not saying that you have to design every little piece of your software before you build it, but instead have an eye towards what happens when this goes post build. What happens when we hand this off to our future selves? Are we going to be able to know what were we trying to do in this code? Are we going to be able to run, run tests? Are we, are we going to be able to know why we made decisions the way we did along the way? All of these are investments in productive maintenance. Thanks so much for listening to today's episode, a deeper dive on change, the kind of change that you should be prepared for, not just scaling up, but adjustment and maintenance in the future. Thanks so much for listening. Uh, if you enjoyed this episode, I encourage you to subscribe and whatever podcasting app, your current, currently using number one, uh, number two, go and join the developer T discord. That's at developer T.com slash discord. And finally, if you want to give back to the show, if anything that we've ever said on the show has been useful to you in your career, I'll give you a simple mental exercise. Try to imagine just how valuable that thing was, whatever it is that you heard on the show. What kind of value did that produce in your career? If you can put a dollar number to it, imagine, is it $5? $100? $100? $100,000? Whatever it is. If it's zero, then I hope that you find a better way to use your time. Hopefully you're only listening to this podcast. If it's actually valuable to you, if it's not zero, then I'd like to ask you to consider taking the time, uh, to go and leave a review in iTunes. This is the most important thing for the longevity of this show is to have reviews first in iTunes and second in every other platform. If you leave those reviews, it helps other engineers find the show. And of course it provides a little nudging to the algorithms that suggest the show. Thanks so much for listening and until next time, enjoy your tea.