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. We're calling them razors. Razors are essentially a way to quickly make a decision. I remember it by thinking, "'Cut it out.'" 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 to make quicker decisions. My name is Jonathan Cutrelli. 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. Here's the first razor that I want to talk about. 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 working. 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. Let's imagine that you have a 95% uptime rate. This is a pretty bad uptime 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 and they both have 95%, basically you've jumped your uptime to 99.75%. And that's just with a little bit of probability math. You can kind of figure that out. And this only gets better if you improve the reliability of one of those systems or of both of those systems. Those probabilities get even better. But you don't have to improve it all the way to, let's say, 99%. You could just go to 96%. But let's think. Think about the investment necessary here. This is a classic kind of buy versus build or buy versus improve question. When 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 kind of eliminate shared variables there, you are essentially buying all of that flexibility, all of that improvement, which is a lot of flexibility. With very little risk, an almost turnkey solution, right? It's going to happen very quickly. So you're also buying time when you have a redundant system. When you try 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 ease and easily translate to having a backup. But this principle can apply in a lot of situations. And thinking this way is essentially a form of risk mitigation. What we're trying to do is limit the risk of overinvestment 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, is 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're functional, but you're not really sure how durable they are. Well, 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. 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, season down into, you know, one moment that you feel like 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's so many gems that folks can take away from this. And I think that's what we're going to talk about today. So I'm going to talk about the first episode of the 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. And during this interview, she got really kind of vulnerable with us. And it really comes through in the interview. She really misses, like really misses being an individual contributor sometimes. And 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 Compile. Wherever you find podcasts. Thank you so much for the support to Compiler. Okay, so 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, and this is particularly effective for those kind of medium-level decisions. These are things that have some relatively important impact, but it's not like changing jobs, right? This is something like choosing what to do for the next two to four weeks with your team. So 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. So what I want you to do is choose a level of perfection. So we talked about at the beginning of the episode the idea of a perfect solution. And very often, we try to trickle down to a level of perfection, and we trick ourselves into believing that we're choosing a perfect solution. And we do this implicitly. We know that this isn't true. We're choosing suboptimal 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 delude 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, perfect, and perfect, and perfect, and perfect, and perfect, and perfect, and perfect, and perfect, and perfect, and perfect, and perfect, and perfect, and perfect, and perfect, and perfect, and perfect, perfection. This is what I want you 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 this particular decision, whatever the question is at hand. 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 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 these contenders are close to that 85% mark, 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 to you, it doesn'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 at 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. So 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. Thank you.