Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell. In today's episode we're talking about heuristics. I'm going to give you some ideas of how you can supercharge your decision making pace. As developers, we face this problem of being indecisive. We've talked about it on the show before. We're going to keep on talking about it because it still continues to be a problem. The questions that I receive on the show are about what decision should I make? Which direction should I go? Which thing should I use? What place should I work at? What type of education should I pursue? There's all these different decisions and different options that we have to make. We often can be comparalyzed by our decision making needs. By the fact that we have decisions that are very difficult to make. I want to talk to you today about something called heuristics. If you've never heard of heuristics, for the sake of today's discussion, we're going to simplify the definition to rules of thumb that produce educated guesses. Rules of thumb that produce educated guesses. You can think of these as guard rails. Your pointers towards a generally correct direction that someone else has found and they're trying to help you find. If you think about every decision that you make as a pathway or as a step on a pathway, instead of always trailblazing your own path, which can be arduous and sometimes lead you in the wrong direction, sometimes it's actually not a bad idea to follow in the footsteps of someone else. Even if that someone else is you from a previous period in your life or maybe it's you from your analysis time, your planning time, you've created some guard rails for yourself and you've created these heuristics, these rules of thumb. For example, we can use statistical likelihoods to rule out obviously bad options. These are guard rails that we can use heuristics that we can use. A simple example, if you need to get work done, let's say you have a set of things that you'd like to accomplish today, an obvious heuristic, a very clear, obvious heuristic that very few people disagree with, I think, would be to remove any distractions and apply effort towards something you know is important. Those two simple things, remove your distractions and start working. While this may not be the perfect solution to productivity, you may not get 100% productivity out of this. Maybe you need a distraction every three minutes and 45 seconds, right? Maybe you need to walk around your room every hour for 37 seconds. The reality is to determine that level of granularity, right, to determine the absolutely perfect way for you to be the most productive, that's going to be prohibitively difficult and prohibitively time consuming. You'd have to try every possible iteration of these things to know exactly what is perfect. So while removing distractions and applying effort is not necessarily going to be the absolutely optimal solution to productivity every single time, there's a high likelihood that it is at minimum an acceptable move. And that's a word that I want you to think about throughout the rest of today's episode. The decision to remove distractions, that's an acceptable decision based on really basic heuristics of productivity, right? It's likely that we have some level of research or some level of, even if it's just basic deduction skills that tell us that you need to put effort forward in order to get work done. So this is acceptable. In contrast to not doing anything at all, right? I need to get work done today. Therefore, I'm going to sleep late. Well, this is the kind of answer that is obviously wrong and it would be identified and removed quickly by an even halfway decent heuristic. I remember as a child and even into my adult years, whenever I feel physically not well, whenever I have a headache or whenever I'm, you know, I have aches and pains or something like that. I remember my father always telling me that I probably needed to rest and hydrate, rest and hydrate. And this is heuristic that he uses, rule of thumb. If you don't feel well, the first step that you take is rest and hydrate. And I've developed my own heuristics a lot of the time when I have aches and pains, I can relieve a lot of those aches and pains by resting, hydrating and exercising, right? Resting a little bit, hydrating a little bit, exercising a little bit. These are very simple heuristics that I've developed that are not necessarily directly related to the specific pains that I'm having. There are not even necessarily researched. It's anecdotal evidence. It's informed by maybe by some of the things that my dad has passed on in heuristics to me, the rules of thumb that have helped him to feel better, right? And even though a doctor didn't have to tell me that or I didn't have to go through a clinical study in order to discover those things, I have those rules of thumb to help relieve pain. So I want you to encode in your brain, encode in your brain the idea that heuristics are triggers for action. Heuristics are triggers for making decisions, right? And in this way, they're incredibly important. Heuristics allow us to make decisions. They trigger us to make decisions. So I'm going to give you four insights today about heuristics that hopefully will help you make better decisions and make quicker decisions so that you aren't in that state of constant analysis that you aren't in that state where you can't make a decision and move forward. So the first insight I want to share with you today, number one, good heuristics take advantage of well-worn paths. Good heuristics take advantage of well-worn paths. We already said this at the beginning of the episode, but heuristic in many ways is like someone who has come before you and has already developed a pathway to get to where you're trying to go, right? Even if they didn't develop the perfect pathway, even if they didn't spend the time to meticulously figure out exactly what that pathway should look like, they have come before you and therefore they've given you the hints of which direction you should go. A good heuristic is like a design pattern, right? In fact, design patterns could be considered heuristics. Heuristics that work well are going to be proven time after time. Some of my favorite programming heuristics, for example, I like to keep all of my code files, no matter what that code file is responsible for, all of them should be under 100 lines. In JavaScript, for my node files, I want those to be under about 50 lines. Their interesting heuristic is the squint test. Very simply, if you have code highlighting turned on, if you'll step back from your code and squint at it. This is specifically for code that is highlighted properly, meaning things like classes are colored differently from variables and variables are colored differently from instance variables and that kind of thing. Methods obviously would have a different coloring. As long as your code is highlighted, you take a step back, squint at your code, and if you see large changes of shape, then you're probably not handling the flow of your code correctly, right? There may be a lot of conditionals. There may be nesting. This is particularly true with JavaScript. Another thing that you're looking for in the squint test is changes in color. If you have a lot of changes in color, that may mean that you are unevenly abstracted in your code, right? You may have a reference to a class and then you have a reference to an instance variable and then a reference to a local variable. If you have a bunch of these differing types of code within a given method, then your abstraction levels may be off. This was arrived at by people who have written a lot of code, figuring out what bad code quite literally looks like in their code editor. If you can match up bad code to other bad code visually speaking, then maybe you're onto something, right? Maybe that is a path that you can trailblaze for others to go down. The squint test operates as a heuristic. Is it always going to be correct? Not necessarily. Is it always going to be insightful? Not necessarily. What it is is a well-worn path. Good heuristics are well-worn pathways. Number two, on the flip side, good heuristics can breed bad assumptions. Good heuristics can breed bad assumptions, taking that squint test from before. If you have a well-constructed file that doesn't pass the squint test, that doesn't necessarily mean that you need to refactor that, right? If it doesn't pass the squint test, there may be legitimate reasons for why it doesn't pass the squint test. If you're trying to evaluate your current set of heuristics for their validity, don't start at the heuristic itself, but instead start by identifying what assumptions you have made. For example, a heuristic that many developers have heard is to keep their code dry. This leads to the assumption sometimes that any code duplication is bad. However, this is not always true. We've done an episode about this, actually. Maintaining dry code means much more than just eliminating duplication. In fact, sometimes duplication is the best answer, or one of the best answers, to the most maintainable and clear way to accomplish a goal. Many assumptions come from heuristics, and sometimes those assumptions are good. In fact, a lot of the time those assumptions are good. It's good to avoid duplication when practical. However, if you as a developer are unaware of the source of your heuristic, right? If you're uncertain as to what the reasoning is behind something like dry code, don't repeat yourself. It's worth investigating where those assumptions and where those heuristics actually stem from. What is the history of that heuristic? Who are the people that actually pioneered that particular heuristic? What are the statistics, where the studies that make up that heuristic? This way, you can be more informed and maybe clear out some of the bad assumptions that have been derived from and otherwise good heuristic. We have two more insights to provide you today, but first I want to talk about today's sponsor, Flatiron. Flatiron is a coding boot camp that is known for launching developers. Here's the compelling thing. I'm going to go ahead and tell you because I think it's such an incredible thing that they are guaranteeing. Flatiron is guaranteeing that you will receive a job offer within 180 days or your money back. Think about that for a second. If you complete the New York or the online web developer program and you actively search for a job, you will receive a job offer within 180 days or your money back. Their independently verified jobs report proves that students get results. 98% of Flatiron grads find jobs they love within six months, including internships, apprenticeships, full-time roles with starting salaries that are competitive in any market. Flatiron is interested in you being successful. It's a give and take relationship. Any good relationship has accountability and that's how they stay accountable to you as a student. They aren't just looking to get your money and then send you back into the world not having a job. They're looking for you to get a job. It's good for them and it's good for you. You can jump start your coding journey with Flatiron schools free online resources. They have a bootcamp prep course which will help you learn a coveted spot in the most selective coding boot camps. It's a free rapid prep course that will take you from Code Noobie to technically proficient boot camp applicant with over 60 hours of curriculum. That's totally free. So Flatiron bootcamp prep.com. That's where you can go and get started. You can join the ranks of Flatiron School alumni now working at companies like Facebook, Google, IBM. Head over to Flatiron Bootcamp Prep.com and get started. You'll receive $500 off your first month of tuition if you go to their boot camp prep. That's Flatiron Bootcamp Prep.com. You can go to spec.fm slash Flatiron to get directly to that link. Now, Flatiron School is also announcing their newest program, Community Powered Bootcamp. You can learn to code online but not alone at $149 per month. You can join a thriving community of students on Flatiron School's online campus. So move at your own pace. It's the same course of study that they use in the Web Developer Program. It's a proven curriculum that gets people jobs. Flatiron Bootcamp Prep.com. That's free resources for you to get ready for this boot camp and you'll get $500 off your first month of tuition. This is such a cool thing. Boot camps are not an easy process. Getting a job in this industry is not easy. You shouldn't make it look easy. This is a difficult thing to do. Going to Flatiron, that's not going to be easy. It's called a boot camp for a reason. So, going through a boot camp that is confident in their offerings. That's the kind of boot camp that you want to look for. If you're going to go to a boot camp, go to one that is so confident in their offerings that they are willing to guarantee you a job. There's a good heuristic for you. If you're going to go to a boot camp, go to one that will guarantee you a job. We have two more insights to talk about today. The first one that we mentioned, good heuristics take advantage of well-worn paths. Good heuristics take advantage of well-worn paths. Number two, good heuristics can breed bad assumptions. You need to go through your assumptions, identify them, and determine what heuristic is that coming from. Is that heuristic good? Do I need to clear out these bad assumptions? Number three, decision paralysis often occurs when we are not willing to rely on heuristics. Let me say that again because this is one of the cardinal sins for developers. One of our worst poisons is that we're not willing to rely on heuristics. Decision paralysis often stems. It often occurs when we aren't willing to rely on heuristics. Decision paralysis might leave us optimizing the wrong thing. As developers, we have analytical minds. Most developers share that in common. We have the ability to determine which one is better, which thing is better. We A, B test. We determine for a given decision, perhaps all of the parameters of that decision and all of the possible outcomes. This overanalysis can leave us analyzing for far too long. If we're trying to optimize, for example, what job we take next. We end up spending an exorbitant amount of time trying to decide between two relatively equivalent job options, the optimization of the job itself, the details of the job, may cost us more than we really should have spent because of the time and the opportunity that we've now lost. In other words, the optimal solution isn't only dependent on the character of the outcome. I want you to think about that for a second. The optimal solution to a given problem is not only dependent on the character of the outcome or the characteristics of the outcome, but also on the process necessary to arrive at that outcome. If you spend a year deliberating between frameworks, for example, you've invested a year's worth of time in order to optimize a way and arguably negligible difference between those two frameworks or those three frameworks. If you're spending an exorbitant amount of time or an exorbitant amount of energy or an exorbitant amount of money in order to optimize your decision, you're probably not thinking about the process as a part of that decision. It's important that we as developers recognize the cost of the process of deciding. If you're not relying on heuristics and you're over-analysing, then you may end up in decision paralysis and that's incredibly costly. That's inside number three. Inside number four, when making decisions, determine what level of right you require upfront. A lot of people wrongly call this settling. At level of right, you require upfront. Some decisions absolutely do require more in-depth analysis or at least justify more in-depth analysis than a simple heuristic might provide. For example, for decisions that have a long-lasting impact and the options are wildly different, more research is generally warranted. However, this doesn't rule out the use of heuristics in that process either. For example, if you're trying to decide what kind of house you want, you may quickly narrow it down based on a few simple heuristics. I want to live somewhere in this particular area of the country. That could eliminate three-force of your options. I want to live near a city. Well, that could eliminate another three-force of your options. You're filtering down. In a lot of ways, you can think about heuristics as filters. You may also have some space or monetary goals, determining a range of boxes that you want your particular solution to check can help you be more decisive. This is a way of using heuristics as well as in-depth analysis to accomplish a decision faster. Because the idea here is to narrow down your large options set to fewer options and then evaluate each of the fewer options. The first step uses heuristics to eliminate options that are really outside of the realm of possibility or realism for you. The second step is more like an algorithm. That's really the antithesis of a heuristic. Algorithm is not a rule of thumb. Instead, it is a very specific and thorough process. The simple way to do this is to outline the characteristics of your ideal option. You may want between 1700 and 2000 square feet. You've eliminated a large number of options there. You may want to live near a downtown area and you want to spend less than $2,000 a month on mortgage or on rent. You may have eliminated a large number of options there. You like two bathrooms and wood floors and big windows. You have all these boxes that you would like to check. The next step is to determine how many of those boxes you regularly require. Once you've decided on the factors, first of all, some of those are non-negotiable, obviously. You may need to say that it's absolutely non-negotiable to spend any more than $2,000 a month on a mortgage or a rent. What many of us do at this stage is we try to make all of our requirements non-negotiable. This is what leads to a long-running process. This is what leads to over-optimization of whatever that solution is. You end up not finding a house anywhere that meets all of your requirements. Of the ones that are negotiable, once you've decided the requirements, the leftover ones are negotiable. To determine what number of them need to be met for you to be happy, for you to say yes to that option. The goal here is to allow for sub-optimal solutions, which means you can't require every box to be checked to say yes to that option. These simple steps allow you to create generalized rules of thumb and directions to get you to a smaller subset. Once you have a list of 10 houses, well, then it's probably worth your time to investigate very explicitly and step by step through that house, go through a rigorous process of looking at all 10 of those options. There's nothing wrong with an algorithmic process once you've used heuristics to eliminate options that are outside of the realm of possibility for you in the first place. Use heuristics to help you make decisions. Use them as tools and as triggers for decision-making ability. The key to being decisive is flexibility and adaptability and heuristics allow you to be flexible and adaptable. I want you to capture that thought. Heuristics allow you to be flexible and adaptable and they are triggers for action and decision. Thank you so much for listening to today's episode of Developer Tea. I hope you've enjoyed this discussion about heuristics, about decision-making. I'd love to hear your thoughts on heuristics and their place in our jobs as developers in writing code, but also making other decisions, life decisions, soft skills decisions. I've got two more quick things. First of all, I launched a brand new website that I'd love for you to go and check out softskillsweekly.com. This is going to be a digest of soft skills, articles and resources that are going to deliver on a weekly basis. Now, we're not yet launching the actual emails. We haven't created our first issue yet, but I want all of you who are listeners of Developer Teato be the first to know about soft skills weekly. You can go and sign up right now at softskillsweekly.com. All it is is a sign up form, very simple, enter your best email and you will receive, once we start rolling out those issues, you will receive only one issue per week. So thank you so much for those of you who are going to join that. I know all of us care about soft skills and that's a large part of what Developer Teahas been promoting and there are so many other resources out there that need to be known about by developers. We need to share these resources and that's why I created softskillsweekly.com. Secondly, I want to thank today's sponsor, Flatiron School. If you are looking for a job, if you're interested in getting into development and you're trying to decide between different boot camps, then what better can you look for than a guarantee that as long as you do your part, you will get hired within about half a year, 180 days to be exact. That's what Flatiron School offers. They also offer you free resources to prepare for the boot camp. Go and check it out. Spec.fm slash Flatiron. Thank you so much for listening to today's episode of Developer Tea. If you don't want to miss out on future episodes, make sure you subscribe and whatever podcasting app you use and until next time, enjoy your tea.