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 Deflla Parti. 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, doesn't have to be a developer, maybe a coworker, that you think could use a little bit of encouragement. 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 and 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 and 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. An implicit heuristic is kind of an operational mode, something that we tend to do the same way as kind of 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 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. 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 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 tend to be a little bit messy. There's not always a perfect answer. 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 one of the brain's most powerful features. The ability to have a way of operating 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 theory for yourself. In today's episode, we're going to switch over and talk about explicit heuristics. 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 proverb or a platitude. 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, right? 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? You can see that these explicit heuristics differ from implicit heuristics and that you can call them up on purpose. You can use them as a tool, a lens to see your problems with. The new explicit heuristic that I would like to introduce today is very simple. You can use this whenever you're wondering, what's a good use of my time? How can I choose which direction is better? The explicit heuristic I want you to remember is find cheap tests. Find cheap tests. 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. When we are faced with a difficult decision, 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? How do we make the right decision? How do we identify what opportunities are a better direction for us? Let's see you have option A and option B in front of you. 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. 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. 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 practicing a particular principle, validating your direction. Validating your direction. 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 may be a large set of features that it's going to serve your users? It's going to 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? This is also a tool that you can use when you're trying to decide without knowing, right, without knowing how easy it is to test. You can ask this question, which option can we validate the easiest? Which direction could we pull the rip cord 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 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 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, right? Option A or option B. We're 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 Developer 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 Teacan be found on spec.fm. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.