When making difficult decisions, whether in software or in life, it helps to have a set of principles. In today's episode, we're going to talk about some principles that you can employ to make better decisions and make better software. My name is Jonathan Cutrell you're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. And I want to give you these practical tools as often as I can. The reality is that you have to adopt your own principles. And hopefully you're using some good evidence and the principles of others to inform the ones that you feel are going to be most effective for you. And I don't want you to just take this point blank. I want you to take this and run it through its paces to see if it's going to work for you. It works for me, but it doesn't mean it's going to work for everybody. With that said, let's jump into the first principle. Saying yes to the wrong thing is almost always more costly than saying no to the right thing. Let's think about that again. Saying yes to the wrong thing is more costly is usually more costly than saying no to the right thing. Let's explore this principle a little bit deeper here. The resource that we're talking about implicitly in this principle is time. And we choose to do something when we choose to spend our time in a particular way. We are actively choosing to not spend our time in a different way. This seems obvious, but this is the crux of this principle. If you choose to do the wrong thing, right? And in this case, I want to define what I mean by wrong thing and right thing because those definitions might change the way you think about this principle. When I say wrong in this case, I mean something that doesn't come close to helping you achieve your goal. When I say right, the right thing in this case, it is something that would help you achieve your goal. I don't want to talk about rare opportunities that aren't going to come around. That's not what this principle is about. The truth of the matter is most of those opportunities are exactly what I already mentioned. They're rare. The vast majority of the opportunities that you're going to be presented are going to be one of many good options. And while you may have many good options, there is a whole ocean, usually, of bad options. And so choosing to say yes to one of those bad options, it takes the time that you could have said yes to a different right option, even if you did say no to another right option. In other words, you're removing your optionality by saying yes, which means that yes costs. Yes is expensive, whereas no is not necessarily expensive. Notice that I don't want you to ignore the opportunity costs of saying no to a good thing, but instead recognize that no to a good thing doesn't necessarily mean no to all good things. It also doesn't mean no forever. When we say yes to something and we spend time on it, that's time that we can't capture it back. And so if your yes is a large commitment, especially, it makes sense to make those decisions carefully, make those decisions deliberately. And when in doubt, you might want to bias your decisions towards a no. We're going to take a quick sponsor break, and then we're going to come back and talk about a second principle that will help you make better software design decisions. Developer Tea is proudly supported by Square. There are millions of sellers across the globe using Square to run every aspect of their business. Many are looking for customized solutions that are deeply connected and easy to use. This is where you as a developer come in. You can grow your business by extending or integrating with Square using free APIs and SDKs to build tools for sellers. Learn more by going to developer.com slash square. That's DeveloperTea.com slash square. Thanks again to Square for sponsoring today's episode of Developer Tea. Before we move forward with our second principle, I do want to clarify one part of that first principle, the idea that you should lean towards no. When I say you should lean towards no, the situation that I'm referring to is when you don't know, right, you either don't have enough information enough evidence to suspect that that direction is the right direction. Or you have any evidence to suspect that that direction is the wrong direction. Obviously if you know that you have a good direction versus a bad direction or a direction that would help you succeed if you had enough information to believe that, then that changes the picture a little bit. What we're really talking about here is making a decision under uncertainty. And there is uncertainty and you don't have a reason to believe that a particular decision is going to help you succeed. Then it makes sense to lean towards no. Of course you can't just keep saying no and doing nothing. So at some point it might make sense to look at your options, try to imagine which of these plays out the best. Let's say that all of them are equal. You might go with the simplest option, for example. And this actually plays into our second principle that will help you make better software design decisions. And that is choose designs that allow you to make the least assumptions. Choose designs, choose tools, choose paradigms, choose team constructions that allow you to make the least number of assumptions. Most of the time assumptions are masked in the form of believability. Assumptions might also be masked in the form of expectations for the future. When we make assumptions, we are stating something that we believe to be true, acting on that thing as if it were true without sufficient evidence to prove that it's true. We assume, meaning that we take on that particular concept, that fact, that assertion as if it was truth. Given two directions, given two systems, one where there is a large number of assumptions, and one where there is a very small number of assumptions that are being made, the first system is statistically more likely to have error. What does this mean? Well it doesn't necessarily mean it's going to have more bugs. But instead, the assumptions that are made carry that software in a different direction than it needs to go, and that direction is going to be costly. Making assumptions introduces the potential for error. It doesn't always mean that you're going to have error, but it introduces the potential. So if you add a bunch of assumptions to a given project, it's possible that you're right about all of them, but it's very unlikely. You're much more likely to introduce error when you create assumptions. So going back to our previous example, when we choose architectures, when we choose solutions, let's say we have solution A and solution B, solution A allows us to make fewer assumptions than solution B. All things being equal, we should likely go with solution A. Now before you get frustrated with the fact that you're pretty sure that you have these changes that are coming in a month or two and you don't want to build yourself into a corner, it's important to recognize that this works both ways. You shouldn't assume that these features are coming, but you also shouldn't assume that they're not coming. In other words, if you build your software in a way that is open to future change, it's flexible to future change, then you are limiting the number of assumptions that your software is making. You shouldn't confuse this principle with the, you aren't going to need it, principle, stagnate, stagnate. That principle combined with this one allows us to build the first layers of something, right? The first early features of something without closing the door to future expansion and future change. This means that we build flexible systems early that don't try to predict future features. Thanks so much for listening to today's episode of Developer Tea. I hope you found this episode intriguing and useful. Hopefully you can talk about these things with your team, maybe with your manager. I'd love to hear your takes on how these principles might play out in reality, in your actual jobs. If you want to talk about those things, come join us in the Developer Tea Discord, head over to developertea.com. This Discord, of course, sets 100% free for listeners of this show. Today's episode of Developer Tea was made possible by Square. Head over to developertea.com slash square. If you could start it with squares, APIs, and SDKs for software engineers like you, you can expand your business using Square Building Tools for sellers. Again, that's developertea.com slash square. Thanks so much for listening. And until next time, enjoy your tea.