The perfect solution is rarely the best solution. It's rarely the most efficient option. It's rarely desirable. When we say perfect solution in this episode, we're talking about a solution that has thought of everything that has taken into account every possible variable and is optimized for all possible outcomes. In today's episode, I'm going to provide you some very practical tools. Recalling them razors are essentially a way to quickly make a decision. I remember it by cutting through the noise. A razor is not a perfect way of making decisions, but it can often act as a very good heuristic or a set of heuristics that you can quickly tap into make quicker decisions. My name is Jonathan Cutrell, I'm listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Here's the first razor that I want to discuss today. First think redundancy. Then think robustness. First think redundancy. Then think robustness. What does this mean? Well, most of the time, the tools that we use, especially the average tool that we use, has some service level expectation. There's some point that we can push our tools to before we can expect them to start breaking. There is an enormous amount of work done to make the most modern tools highly reliable. But in the case that something does fail, we could experience significant loss. Just imagine that you have a 95% up-time rate. This is a pretty bad up-time rate. If you wanted to avoid any issues, you could imagine two possible routes. If you want to avoid that 5% of downtime, you can either try to improve that system, invest in that top 5%. Most of the time, going from, let's say, 50% to 75% is a relatively easy jump to make. It's kind of like a battery. If you're familiar with the way that rechargeable batteries work towards the top end of their charge ability, the charging slows down. As you improve the efficiency of a given machine, the very top end is going to be much more investment to improve than the mid-range or the low end. Knowing this kind of principle, you can think about investing to improve from 95% to, let's say, 98%, or you could add a redundant fallover system that is the same level of reliability. Now, if you have a 95% system and another 95% system, the likelihood of both of these going down, assuming that they have no shared factors, which is a big assumption, by the way, but let's just assume that you have two completely separate systems that both have 95%. Basically, you've jumped your up-time to 99.75%. That's just with a little bit of probability math, you can figure that out. This only gets better if you improve the reliability of one of those systems or both of those systems, those probabilities get even better. You don't have to improve it all the way to, let's say, 99%, you could just go to 96%. Let's think about the investment necessary here. This is a classic kind of bi versus build or bi versus improve question. You have redundant systems when you're buying into a redundant system. Generally speaking, especially if you have, let's say, two Amazon clusters and they're in different regions, so you're trying to eliminate shared variables there. You are essentially buying all of that flexibility, all of that improvement with very little risk and almost turn key solution. It's going to happen very quickly, so you're also buying time when you have a redundant system. When you're trying to improve a system, it's much harder to have confidence that your improvements are going to be as effective as creating a redundant system. Now, of course, it's important for us to recognize that not all systems need redundancy. In other words, failure doesn't necessarily easily translate to having a back hub, but this principle can apply in a lot of situations. Thinking this way is essentially a form of risk mitigation. What we're trying to do is limit the risk of over-investment in a single resource and improve our outcomes or improve the things that we care about with as little of an investment as possible. Another simple example of this that's not related to software engineering, imagine that you are trying to buy a set of tools and you know that there is a set of tools that will do the job that they are functional, but you're not really sure how durable they are. You could spend the time necessary to figure out what is the most durable tool. You might spend orders of magnitude more money paying for the most durable tool because it happens to also overlap with the tool with the most brand name recognition or something, or you could just buy two sets of the same tool or even better, two sets of different tools. That way if there is a particular weakness of one set, you now have the flexibility of using the second set to fill in those gaps. So most of the time, this idea of redundancy beating out robustness holds true. We're going to take a quick break and talk about today's sponsor compiler and then we'll come back and talk about the second razor. Today we are so grateful for the support from today's sponsor compiler. Compiler is a brand new podcast from Red Hat where you will get the tech industry's hardest questions answered. I had a great discussion with Brent and Angela about compiler and about their experience on it here. We discuss what they think is the most important moment in the season. If you could distill the entire season down into one moment, you feel like it was really important for listeners to hear. Do you have a moment like that? I would have to say it is our mentorship episode that's coming. A lot of folks are familiar with mentorship, may or may not have had mentors in their lives, but there are so many gems that folks can take away from this podcast. Maybe that's the one that might have the biggest takeaway. I'm sure there are going to be others, but that one kind of sticks out right now. There's this moment in our first episode and that episode centers on the question should managers code and we did an interview for that episode with a manager and she is a data scientist. During this interview, she got really kind of vulnerable with us and it really comes through in the interview. She really misses being an individual contributor sometimes. Kind of what it feels like to not currently be doing what you got in the industry to do in the first place. I encourage you if this sounds interesting. Certainly the rest of the show is that much better. Go and check out Compiler wherever you find podcasts. Thank you so much for the support to Compiler. We're going to talk about the second razor and I'm kind of cheating calling this one a razor. It's more of a process or a way of making decisions, but it turns out to act kind of like a razor which is why I chose to call it that for this episode. What I want you to do in your next decision making process, this is particularly effective for those kind of medium level decisions. These are things that have some relatively important impact but it's not changing jobs. This is something like choosing what to do for the next two to four weeks with your team. There's some level of investment, there's some level of importance for success or generating some kind of positive outcome that would be ideal and important but it's not going to break the bank if you fail. What I want you to do is choose a level of perfection. We talked about the beginning of the episode, the idea of a perfect solution and very often we try to trick ourselves into believing that we're choosing a perfect solution. We do this implicitly. We know that this isn't true. We're choosing sub optimal things all the time. We know that the thing that we're getting ready to eat for lunch may not be the perfectly healthy thing for our day but to find out what the most, you know, the healthiest possible lunch would be, we'd have to do a lot of investigation. And really, the return on investment probably isn't there. And so we make concessions but we don't often talk about what level of perfection we want out of a given decision. And so we dilute ourselves into thinking that a decision is the right decision and that any kind of failure is purely because of chance that we did everything right. But the truth is most decisions we could assign a level of acceptable perfection. This is what I wanted to do. I want you to pick something, you know, presumably above 50%. Probably somewhere around 80 or 85%. You're willing to let 15% of the value that you could possibly gain out of this decision. You're willing to let it go. And I want you to assign that to your, to this particular decision, whatever the question is at hand, you write it down even on a piece of paper. And as you review your possible solutions, here's where it becomes a really good tool for making your decision more efficient. As you're reviewing your possible decisions, try to determine if you, if you have two or three contenders, for example, which of these is closest to that 85% mark, right? Which of these comes closest to meeting that or more importantly, what makes this really effective is if any of them meet that mark or exceed that mark, right? If any of them do, then you can choose any of them. You don't have to labor over which one is 87 versus which one is 89. You can just choose one. Maybe you go with the one that you like or go with a quick vote on your team, whatever your mechanism is for quickly shuffling away the extraneous decisions that don't really matter because if all of them have the same positive outcome, all of the same upside, or if they all have sufficient upside, then the time you spend laboring, trying to decide between them is likely less valuable than something else that you could do with that same time. Thanks so much for listening to today's episode of Developer Tea. Hopefully these are useful, decision making, razors for you, for your team, for your career, maybe your personal life. These are really kind of open tools, you don't have to use them to do engineering work. You can use them to do work in your personal life, prioritization, your career, all of those things. Hopefully this was helpful. Thanks so much to today's sponsor, compiler, answering all of the web industry, the tech industry's biggest questions, most confusing questions, most nuanced questions. You can find compiler wherever you listen to podcasts. If you enjoy Developer Tea, if you enjoy the conversation that we're having here, maybe you have a thought and something that you can expound on in this episode or previous episode, maybe you have your own razor that you'd like to share. I'd like to invite you to do that in the Developer Tea Discord, head over to developertea.com slash discord to join today. Thanks so much for listening and until next time, enjoy your tea.