And 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 Cutrell. You're listening to Developer Tea. 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. Because this is a very common way that people 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 will be trying to work on this thing. And then in response, we kind of implicitly imagine that the product itself will grow. That 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 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. Make sense why we would think this way. That by default, as there are more customers, there's going to be more input. Because there's more customers, there is more demand for new things, new features. Maybe there are new use cases we haven't covered yet. 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 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 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 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 future 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 change in your team, 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 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 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, trying to debug something or trying to fix 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 once you launch. 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, six months, let's imagine you grow to, for the sake of easy math, 36 people, 36 people. That means that in a given month, you're spending twice the amount of total human time in a maintenance phase, then you did in those initial six months. Now, to be clear, that's not calendar time, that's just human time. 36 people times one month is 36 human months, we're just kind of creating our own unit of time here, versus three people times six months is 18 human months. And so 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 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 overspecify. 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 we're trying to do in this code? Are we going to be able to run tests? 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. If you enjoyed this episode, I encourage you to subscribe in whatever podcasting app you're currently using. Number one, number two, go and join the Developer Tea Discord, that's at developertea.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? It's a $80 number to it. Imagine is it $5, $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 to go and leave a review in iTunes. This is the most important thing for the longevity of this show, is to have reviews. Just in iTunes in 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.