Hello, everyone, and welcome to this episode of Developer Tea. My name is Jonathan Cottrell, and today we're going to be talking about flexibility. This episode is going to be dedicated to the idea that flexibility is a good thing. Why is flexibility a good thing? Well, let's be honest, being flexible means being more free, right? It gives you the ability to do what you want to do when you want to do it. Now, this isn't going to be an episode where we talk about how to make passive income. There's plenty of other podcasts where you might learn how to make passive income. That's not the kind of flexibility I'm referring to. I'm actually referring to both a coding style that increases the flexibility of the work that you're doing, as well as a workflow style that will help increase flexibility. Now, I want to talk about flexibility in terms of how you can keep up with the challenges you're facing in your day-to-day life as it relates to being a developer. If you didn't notice at the beginning of this episode, I didn't tell you what number this episode was. This was intentional. It wasn't a mistake. It was intentional. Now, why would I choose not to tell you what number the episode was? Well, to be honest, it became a problem to have to keep track of when these episodes would go live. And quite honestly, I want the flexibility to choose when the episode goes live and not have to record those in order and not make that choice at the moment that I record them. Why does that matter? Well, inspiration might hit and I might have a certain rant. In particular, flexibility is a rant that I have today. And I wanted to go ahead and record it before I even know exactly when I'm going to release it. So the fact of the matter is you can look at your phone and very easily determine which episode you're listening to. So with this simple change in the way that I'm recording the episode, I have the increased flexibility with the scheduling of the episodes and choosing even to just totally skip or scrap an episode entirely. Now, obviously, I could go back and re-edit the beginning and the end. But when I'm releasing this many episodes, when I'm releasing three episodes of this show a week, that's a lot of overhead. That would be a lot of time, especially if I had to go back and re-edit three or four or five episodes and make sure that all of the episode number mentions are correct. So honestly, I decided to do this because it makes sense. I'm not going to do it again. I'm going to do it again. I'm going to do it again. I'm going to do it again. I'm going to do it again. I'm going to do it again. I'm going to do it again. It makes very little impact on you as the listener, but it makes a massive positive impact for me as I'm creating these episodes, which ends up being a positive impact for you as well. So I'm going to tell you about three ways that you might increase flexibility in your day-to-day work. And some of them will kind of call back to what I was just now talking about, about the simple change in the way I'm recording these episodes. The first one is to eliminate linear dependencies. So what this means is, for instance, my episodes, when I was recording them by saying the number at the beginning, I have a linear dependency based on, you know, let's say I recorded episodes one, two, three, and four, but I decided that I wanted to insert something between episodes one and two. Well, I could either choose to do something really awkward, like do an episode 1.5, or if I had chose to record them in this new flexible way from the beginning, then I could just simply record a new episode and drop it straight in. And the only thing I would have to change is the show notes. So eliminating linear dependencies basically means that everything that you do has its own kind of platform. It stands on its own. And as much as possible, you can plug and play. You can put things in their place. So I'm going to show you how to do that. So I'm going to show you how to do a good code example of this would be to develop classes in such a way that they don't depend on other classes, that instead you pass instances of other classes into like an instantiator or something like that. Now, there's a lot of information on this concept, particularly um, Sandy Metz has some really good content on single responsibility, principle, and lots of things, uh, lots of wisdom about how to structure your code in a way, um, that reduces linear dependencies. So the second, uh, the second thing that you can do to increase flexibility in your day-to-day work is to eliminate unnecessary boundaries. So I had created the boundary, uh, when I was recording these podcasts, I created a boundary for myself by simply saying the episode number and I recognized it. And I realized how unnecessary it was for me to say that number. You could easily look at your phone or you could look at the show notes, uh, and find out what number you're on. But what's even more important is that the episode number doesn't even matter that much anyway, right? Like it doesn't have much to do with the content. And ultimately, uh, it's there to kind of give you a progress, um, but it, it being in the recording, there wasn't much value there. And so eliminating that unnecessary boundary helped me to create a more flexible environment, uh, to record this podcast. Now let's take it to code. Uh, how might you eliminate an unnecessary boundary? Um, let's say you're using a particular library, um, that, that generates code for you. Maybe you generate HTML with it and you're using a particular library, um, that, that generates code for you. Um, and you're using a particular library, um, that, that generates code for you. Maybe you aren't using a lot of that library. Well, it could be that you are, uh, creating a situation where you can't deploy that code, um, to a particular server because you're relying on that library. When, if you were to remove that library entirely, you could increase the flexibility of that particular project massively. Now I know that's a contrived example, but if you can start thinking about boundaries that you have, then you can do a lot of work. So, uh, you can start thinking about boundaries that you have in your projects that are unnecessary. Removing them gives you a massive amount of value and, uh, it doesn't really cost you a lot. In fact, sometimes, um, in these particular types of situations, it doesn't cost you anything. The last recommendation in order to increase flexibility in your day-to-day development workflow is to take advantage of time-shifted workflows. Now, what are time-shifted workflows? Well, essentially, uh, it's, uh, it's, uh, it's, uh, it's, uh, it's, uh, it's, uh, it's, uh, it's, uh, it's work that you do, uh, asynchronously from your team or from, um, its actual publish date. In other words, um, for this show, I publish these episodes. I, I publish them at a time different than I upload them. So I can write the show notes and I can schedule for these shows to actually go live at a particular point in time. Now, this is pretty common. You've probably heard of these scheduling types of things. What can you do to increase flexibility in your day-to-day development? What can you do with your development workflow to take advantage of the fact that computers don't really care what time you do things? So, for example, let's say that you have a distributed team of developers across the world. Well, does it really matter that you are all working at the same time? Of course, this is a larger conversation about development, uh, culture at your particular job. But, uh, a lot of the time, you're not really doing a lot of the work that you're doing. You're not really doing a lot of the work that you're doing. So, um, you can get as much work done by simply working at different times. You, you might get more work done. So let's say that you work really well if you work from 7 p.m. until, I don't know, 2 o'clock in the morning. Those are your peak hours. Okay. That, that probably isn't true for everyone on your team. It certainly isn't true for me. But if you work best at those hours, then work best at those hours. You should be able to work during those hours in such a way that actually still stays in sync with your team. And there's so many tools out there to help you accomplish this. Simple things like GitHub, uh, and, I mean, even email, um, these kinds of communication tools allow you to do development work at different times from each other, right? Just simply doing it at different times from each other that you can accomplish this. So, um, I think that's a really, really important thing to do. It used to be a very difficult task, but now that we have the powerful internet on our side, we can take advantage of these time-shifted workflows and do work at asynchronous times from each other. Zach Holman has a fantastic presentation where he talks about, uh, about some of the work that he's done at GitHub that I'll put in the show notes. And he talks a little bit about this particular idea of asynchronous workflow. Thanks so much for listening to this episode of Developer Tea. If you have any thoughts, any feedback on this episode or the show in general, or if you just want to talk, you can reach me on Twitter at developertea, or you can email me at developertea at gmail.com. You can also reach me on developertea.com. Uh, there's a contact link in the header. If you're enjoying the show, be sure to leave, a review in iTunes. That's the best way to help other developers just like you find the show. Thanks so much. And until next time, enjoy your tea.