Hello everyone and welcome to this episode of Developer Tea. My name is Jonathan Cutrell 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. It gives you the ability to do what you want to do when you want to do it. 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 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. The fact of the matter is you can look at your phone and very easily determine which episode you're listening to. 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 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. Some of them will 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, let's say I recorded episodes 1, 2, 3, and 4, but I decided that I wanted to insert something between episodes 1 and 2. Well, I could either choose to do something really awkward, like do an episode 1.5, or if I had chosen 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 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 Sandy Metz has some really good content on single responsibility principle and lots of things, lots of wisdom about how to structure your code in a way that reduces linear dependencies. So 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 when I was recording these podcasts. I had 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 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, it's there to kind of give you a progress marker. But 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 to record this podcast. Now let's take it to code. How might you eliminate an unnecessary boundary? Let's say you're using a particular library that generates code for you. Maybe you generate HTML with it. And you aren't using a lot of that library. Well it could be that you are creating a situation where you can't deploy that code 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 in your projects that are unnecessary, removing them gives you a massive amount of value. And it doesn't really cost you a lot. In fact, sometimes 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, it's work that you do asynchronously from your team or from its actual published date. In other words, for this show, I publish these episodes. 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. This is pretty common. You've probably heard of these scheduling types of things. 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, culture at your particular job. But a lot of the time you can get as much work done by simply working at different times. You might get more work done. So let's say that you work really well if you work from 7pm until I don't know, 2 o'clock in the morning. Those are your peak hours. 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. There's so many tools out there to help you accomplish this. Simple things like GitHub and even email. These kinds of communication tools allow you to do development work at different times from each other. Just simply doing it at different times from each other that used to be a very difficult task. But now that we have the powerful internet on our side, we can take advantage of these timeshifted workflows and do work asynchronous times from each other. Back home has a fantastic presentation where he talks about some of the work that he's done at GitHub that I'll put in the show notes. 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 and feedback on this episode or the show in general, or if you just want to talk, you can reach me on Twitter at at Developer Tea or you can email me at Developer Tea at gmail.com. You can also reach me on developertea.com. There's a contact link in the header. If you're enjoying the show, be sure to leave a review and 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.