In today's episode of Developer Tea, we're talking about how we operate as developers. How do you determine what tools or rules you apply to problems you're solving as a developer?
Find. Cheap. Tests.
When you face situation with infinite possibilities, it's important to break those options down into easy to digest components.
How can you better validate your direction as early as possible and cheap?
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
Hey everyone, welcome to today's episode of Developer Tea. This is going to be a short episode and I'm going to give you some inspiration, hopefully, to go and take into your week. This is a Monday episode. We don't have a sponsor for today's episode and instead of going and clicking on a sponsor link, I'd like you to do something a little bit different. I want you to think of a developer or someone that you know, it doesn't have to be a developer, maybe a coworker, that you think could use a little bit of encouragement. It doesn't have to be anything over to the top, just something that says that you are thinking of them, that you are considering them on this Monday, the beginning of this week, because there's a lot of people right now, for a lot of reasons, not just because of the pandemic, but because... Of a lot of other reasons that maybe we aren't even aware of, there's a lot of people in your life, a lot of people in my life, who can use that encouragement. Okay, let's jump into today's episode. In today's episode, I'm going to give you an explicit heuristic. I'm going to explain what that is first. I've given them on this show quite a bit in the past without really labeling them as this, the explicit heuristic. But first, I want to talk about what that means. So let's start with what an implicit heuristic is. This is what we usually use in our lives, in our day-to-day lives, these kind of rules of thumb that we've come up with accidentally. An implicit heuristic, we have so many of these, and we don't even realize that we have them. But an implicit heuristic is kind of an operational mode, something that we tend to do the same way as kind of a short term. So an implicit heuristic is a shortcut or a rule of thumb, a way of operating that allows us to not put too much energy into the thought process. A simple example of this can be seen when someone goes shopping. There are different ways of shopping for groceries. For example, you may have an implicit heuristic to look for the cheapest per ounce for a given product. You may have a list of products that you want to buy, and you buy the cheapest per ounce. You take the time to look at the price per ounce, and you don't go in and explicitly say, I'm going to find the cheapest thing per ounce. Instead, you choose that implicit heuristic by default. However, you may have a totally different heuristic. You might have some brand heuristic, something that pushes you towards brands that you recognize, or brands that you've always bought. Or maybe you buy as many things organic as possible. Or maybe your heuristic is speed or simplicity, where you buy the first of that particular item that you find. And so this is an example of an implicit heuristic because you probably never had the discussion, what is my explicit heuristic for choosing groceries? This is not something that most people sit down and define as, what is their way of choosing groceries? Instead, they define it because of some other factor. For example, you might look for the cheapest thing because you are a frugal person, or you do that when you're shopping in general, not just for groceries. Or maybe you're choosing the fastest thing because you don't like to spend time in the grocery store. What you'll notice is that these implicit heuristics, they tend to be a little bit messy. There's not always a perfect answer. So, what's the best way to choose groceries? They are rules of thumb, but rules of thumb don't always cover every scenario. For example, what if there isn't an organic version of that particular ingredient? Or what if you have that frugality heuristic and two things cost exactly the same amount? How do you choose between them? These are very useful. In fact, they are kind of one of the brain's most powerful features. The ability to have a way of operating given certain things. And given some stimulus that doesn't require a lot of extra energy. You don't have to figure out how you shop every single time you go to the grocery store. You don't have to reestablish that kind of theory for yourself. So, in today's episode, we're going to switch over and talk about explicit heuristics. And I'm going to give you one specifically that's been on my mind recently, and I think you'll find it useful. You can imagine an explicit heuristic sounding a little bit like a frugal heuristic. A little bit like a proverb or a platitude. And I'll give you an example of one of these that we've talked about so many times on this show. The heuristic of, the explicit heuristic of making things smaller. This is something that you can use as kind of a tool. It's not just a rule, but it's something that you can pull out of your tool chest and say, I wonder what would happen if I tried to make something in this particular situation that is currently bigger. It's a complex subject. What if I broke it down? If I broke it down into its smaller component parts? What would that do? So, you can see that these explicit heuristics differ from implicit heuristics in that you can kind of call them up on purpose. You can use them as a tool, a lens to see your problems with. So, the new explicit heuristic that I would like to introduce to you today is called the explicit heuristic of making things smaller. It's very simple. And you can use this whenever you're wondering, what's a good use of my time? Or how can I choose which direction is better? And the explicit heuristic I want you to remember is find cheap tests. Find cheap tests. So, let's expound on this explicit heuristic because it may not be immediately clear what exactly we mean by cheap or what exactly we mean by tests. Okay. So, when we are faced with a difficult decision or really any decision at all, we have an endless number of possibilities in almost every scenario. Even if it seems like we only have maybe two choices, we probably have an infinite number or close to an infinite number. Right? So, how do we make the right decision? And how do we identify what opportunities are a better direction for us? Well, you have option A and option B in front of you. And it's not immediately clear which of these options is going to be the most valuable. They both cost the same to implement. But option A is hard to test. It's hard to validate at an early stage whether option A is a good idea. Option B, on the other hand, there is an easy test. We can validate in the very earliest part of the effort towards option B. So, it makes sense then, if you present it this way, that anyone rational would choose option B. It seems like, with the information we have, that it's the most obvious choice. And the reason for that is because even though they cost the same amount and they have the same level of confidence, we have a faster ejection. From option B, if it doesn't work out. If the test fails. So, this heuristic is a way of kind of practicing a particular principle. Validating your direction. Validating your direction. So, what this means is, if you're headed a direction, how do you know it's the right direction? How do you know that this implementation of these large features, maybe a large set of features, that it's going to serve your users? Or it's going to kind of carry you towards the goal that you care about? Is there a way to test that? Is there a way to validate that direction as early as possible and as cheaply as possible? So, this is also a tool that you can use when you're trying to decide without knowing. Alright, without knowing how easy it is to test. You can ask this question. Which option can we validate? Which option can we validate the easiest? Which direction could we kind of pull the ripcord on the fastest? And here's the most important part of this heuristic, right? Because it allows you to make decisions more fluently, a little bit faster. It gets you out of the blocked mode. When you're trying to decide between two things, that's a completely stalled scenario. But if you can make easy decisions. In other words, if you can say, it's cheap. It is very kind of low risk to go in this direction because we know that we can test this direction very quickly. And if we decide to change direction, we can do that right away. Well, the only way you can do that is if you can find a cheap test. I want to be clear about what I mean by the word cheap. I don't always mean monetarily cheap. Usually what this means is that it's easy. It's uncomplicated to check this particular direction. And it can be cheap monetarily. Of course, we're not going to leave that out. But also, it can be quick. Time is absolutely an obvious resource. And so a test that is quickly done might be considered cheap. And if you had two tests and one took twice as long as the other, but they both cost the same amount of energy or effort or money, then you would go with the one that's the fastest. And then you would go with the one that was faster. And again, what's so critical about finding cheap tests or going directions that allow for cheap tests is that instead of thinking or trying to predict all the way through which decision is the best decision to make, option A or option B, or trying to predict the kind of end outcome of A or the end outcome of B, we can ask a different and easier question to ask. Can we check both? Can we check one and then all kind of opt for the other and make the check the simple part? Can we find a way to validate that we've made the right decision and make sure that that validation, that that check, that test is cheap? Thanks so much for listening to today's episode of Developer Tea. If you enjoyed this episode, and you want other developers to be able to find this show, the best way to help us out is to leave us a review in iTunes. Of course, if you know another engineer or maybe someone who's not even an engineer who would benefit from this episode, please share it with them as well. Thanks so much for listening to today's episode. This episode and every other episode of Developer Tea can be found on spec.fm. Today's episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea. Thank you.