There is no one right way to write software. There are a lot of guiding heuristics we can use and maybe some measures that we can use, but ultimately, good software is determined by context. But in today's episode, I do want to give you a heuristic that is broadly associated with successful software. My name is Jonathan Cutrell, you're listening to Developer Tea. I create this show to help driven developers like you find clarity, perspective, and purpose in your career. We've tried to talk about the question, what does it mean to have good code? And we've provided some answers at least on this show. For example, it may mean that your code is clean. Of course, we need to dive into what it means to have a clean code. But ultimately, code that accomplishes what you want to accomplish in the context that you are operating in, that's really your goal as a software developer. Much of your discussions with your coworkers, the reviews that you get in your PRs, the kinds of discussions you'll have with your managers throughout your entire career, are going to be around how well you are able to do exactly that. But the problem is that there's no gold standard way of measuring this. How do we know exactly what level of investment is necessary for a given project? How do we know how to balance too much testing versus not enough testing? How long should we spend on trying to get that variable name just right? These are all fairly ambiguous questions, because the context is what we really are depending on. But I do believe that there is one guiding principle that all developers should be able to use as kind of a measuring stick, or at least an idealistic principle that we should all be kind of pursuing. So what exactly is that principle, that heuristic that we can use? Well, let's start by identifying why we care about the quality of our code in the first place. There is some personal gratification to having high quality code. And we shouldn't discount this because it is important to keep us motivated. If you know that your code is not high quality for whatever reason, maybe you're rushed or maybe the company that you work for just doesn't really care about enforcing standards. And so when you're collaborating with others, your code looks wildly different from theirs, and quality ends up being degraded as a result. A personal gratification is not the only reason we care about high quality code. The main reason we care about high quality code is something I'm going to call in this episode, the bug cycle. We're going to explain the bug cycle and how flexibility can keep you out of the bug cycle right after we discuss today's sponsor Git Prime. I've ever noticed that the best engineering managers are also the ones who are good at finding and fixing bugs. It's not just bugs and software. It's really a set of principles that these managers use, and they find them in Teams as well. Git Prime has written a free book that you can go and download right now at over to Gitprime.com slash 20 patterns. The book is based on data from thousands of enterprise engineering teams, and it shows 20 patterns to watch for in those engineering teams. They dig into various work patterns and team dynamics that we can all relate to with prescriptive ways to identify and improve how we build software together. It's an excellent field guide to help debug your development with data. Go to Gitprime.com slash 20 patterns. That's two zero patterns to download the book, and you can get a perni copy mail to you for free. Check it out at Gitprime.com slash 20 patterns. And again, that's two zero, the number is two zero patterns. Thanks again to Gitprime for sponsoring today's episode. So let's talk about the bug cycle. The bug cycle is simple. You start by developing some software. And initially you probably have a few bugs, but because it hasn't been released, you're able to fix those bugs and the software works. It does what it's specified to do. And so at some point you decide that things are done and you move on. You move on to another feature, or maybe you go and fix a bug somewhere else that's in a different point in the bug cycle. Now, fast forward some amount of time later, you or another developer are working on maybe a related feature, or maybe even the same one that you had finished before, and some kind of bug pops up. Maybe a regression or perhaps you've made a change that has caused a direct bug in the original code. Sometimes it's as simple as fixing that bug and continuing down the road to see that cycle, replay all over again, or sometimes when you fix the bug here, it causes a bug somewhere else. This should be pretty obvious and fairly intuitive how this happens. We continuously are changing our code. And the more we change our code, the more likely we are to introduce new bugs. Very rarely do bugs come from nowhere. Maybe once in a while we might have a bug related to an external system like, for example, dates, or maybe even your database is filling up. You have a large amount of traffic and you have some kind of memory issue on your server. But as far as code bugs are concerned, it's very unlikely that they will come out of nowhere. They usually come from change. In all of these scenarios, if we maintain flexibility with our coding decisions, we are much more likely to be able to address and avoid bugs. In its simplest form, flexibility is the ability to change. If your software is changing, if your ecosystem is changing, if the market is changing, if things are changing around your code, the more change that is happening, the more flexibility that is required. So a very important skill that you can have as a developer is understanding, predicting just how flexible this particular piece of code needs to be. How resilient to change should we make it? Generally speaking, code that is likely to change and code that is in an ecosystem that is likely to change requires the most flexibility. And so if you can learn how to write code that is highly flexible, then you are developing the skills to work in an environment where things are changing. As a general rule, most opportunities for growth will be in environments where there's a lot of change. So I encourage you to focus on this particular skill, the skill of learning how to make your code flexible. This will reduce the overall liability of your code, but it also will improve the success rate. When you're operating in a system where change is regular and you're able to respond to that change, you're much more likely to be successful in your career. Now we've applied this to code in this episode, but I want you to extend this concept, use this as a mental model for other parts of your life. Find the places where your habits are brittle, where you are creating a situation where change could cause a massive disruption for your life. This is not only for your career, it's for your personal life, for your health, this concept extends to a lot of places. I hope that you found this episode valuable. Thank you so much for listening. Thank you again to get prime for sponsoring today's episode, head over to getprime.com, slash 20 patterns. That's two zero patterns to learn about the patterns that make great engineering teams. Thank you so much for listening. If you enjoyed today's episode, I encourage you to do three things. One, share it with somebody that you think will benefit from it. Number two, go and leave a review on iTunes. This greatly affects our visibility in iTunes to other developers. And number three, subscribe and whatever podcasting app you are currently using. If you haven't already done so, this is the best way to stay up with episodes of developer TV. We are approaching 700 episodes in not too long. So we have a lot of episodes. We do three a week and it's easy to get behind. Make sure you subscribe. Thank you so much for listening. And until next time, enjoy your tea.