Over the past few years, I've read a lot of these awesome lists. If you're not familiar with this, there are quite a few repositories, and you can probably Google Awesome lists on GitHub and find maybe a metal list of awesome lists. There's quite a few of these lists that show really well done projects for a particular category. Recently, I stumbled on perhaps my favorite version of these awesome lists. It is the awesome falsehoods, and the awesome falsehoods repository is owned by Kevin Deldick. You can find it on GitHub. If you just Google Awesome Falsehood, you'll find this list of falsehoods that developers believe. The reason this is so interesting to me, and perhaps useful to you, is because falsehoods are a representation of our assumptions, the things that we operate with the working knowledge of these assumptions. Some of them are more egregious or more damaging than others. Some of them it is enough to know that it is a falsehood, and you don't necessarily have to do anything about it. Others are much more important to think about as a developer. I encourage you to go and look at the repo and look through some of these lists. At the very least, it'll get your mind primed to think about things less in black and white terms. Today, I want to talk through a handful of these falsehoods just to get a glimpse into the kinds of things that you might find in this list. My name is Jonathan Cutrell, and you're listening to Developer Tea. My goal on this show is to help driven developers like you connect to your career purpose and do better work so you can have a positive influence on the people around you. That goal is only going to be serviced if we can collectively seek reality together. If I continue to present to you that my hope is that you'll find your purpose and that you can do better work, and then we just kind of leave it at that. Well, we aren't really improving. One of the best ways to improve is to get a better handle on how the world works. Get a better handle on how your operation in the world can be improved and some of the things that you may be doing wrong. Not necessarily on purpose, or because you weren't trained well, but because you're human. We're going to kick things off to give you a taste of what these falsehoods might look like. We're going to kick things off by reading a few lines from the blog Calzumius. This is Patrick McKinsey's blog. This is back in 2010. June 17th of 2010, falsehoods programmers believe about names, and I'm going to give you a couple of these. People have exactly one canonical full name. People have exactly one full name, which they go by. People have at this point in time exactly one canonical full name, and people have exactly at this point in time one full name they go by. At any point during this list, you can start to see how you could reasonably assume that this is true. In many cases, these assumptions do end up being true. Most people that you encounter probably do have one canonical full name that they go by at this point in time, but this isn't an absolute. And therefore, it becomes false. Because these statements and these assumptions, they operate under the assumption that they apply universally to all people that makes them a powerful statement and more importantly a statement that we can't operate from, or at least we should be considering whether it's responsible to operate from that assumption. Another couple of examples from this same list. People's names do not contain numbers. People's names are not written in all caps. People's names are not written in all lowercase letters. Another couple examples. People's names are globally unique, or people's names are almost globally unique. Another thing you'll notice about these falsehood lists, if you go and read some of them, is that many of them will kind of devolve, become a little bit more of a point-making mechanism. As you read down the list, you start seeing that more and more extreme and meta things are listed. And as it turns out, the last item on this list, assumption number 40, or falsehood number 40, is that people have names. We're going to take a break and talk about today's sponsor. And then we're going to come back and talk about a handful of other important falsehoods. And we're going to actually comment on a few of them and expand on a few of them. But first, let's talk about today's awesome sponsor, DigitalOcean. But DigitalOcean, you are buying into the easiest cloud platform to run and scale applications. From effortless administration tools to robust compute, storage, and networking services, DigitalOcean provides an all-in-one cloud platform to help developers like you and your team save time when running and scaling your applications. Now, I said you're buying in, but actually DigitalOcean is investing back into you. They're going to give you $100 worth of free credit to get started on their platform. Basically, this is to help you understand all of the benefits that DigitalOcean has to offer. This is their way of giving you the time to see how useful their platform actually is. Go and check it out. They also offer, by the way, predictable and affordable pricing. This is a little bit different from other providers in the industry. You can leave the complex pricing structures behind because it's going to be the same every month. Go and check it out. Head over to do.co slash tea. To get started today, you're going to get that $100 worth of credit for using that special link that's do.co slash tea. Thanks again to DigitalOcean for sponsoring today's episode of Developer Tea. Now, I do want to make a quick note. I don't typically do episodes like this where I'm reading some information directly off of the screen, but I found that this information is so compelling and it's so interesting and kind of pure and useful that I want to direct you to this information and give you just some things to think about in the episode as well. Give you some commentary on a few of these falsehoods so you can kind of think or prime the way that you're thinking about falsehoods rather than just rejecting them entirely, kind of setting up the way that you can consume these ideas that it's not necessarily true that everyone has one full name, although, and let's say you're building MVP software, it's probably okay to work from that assumption, right? There may be a better way to handle those other cases, but a lot of these falsehoods are based on, you're going to hear this word so many times when you listen to the show, they're based on heuristics. These are rules of thumb. These are the things that you're most likely to encounter. So with that said, if you were to start making a lot of decisions trying to wrap your code around preventing falling victim to these falsehoods that you'll find in these lists, well, that's going to be really quite expensive, right? I'm not going to eliminate every single edge case without a really exhaustive and very costly investment in your software. So the question isn't about, can you operate in such a way that you're no longer believing these falsehoods or writing code that is representative of the falsehoods? Instead, it's about understanding that they exist, number one, and number two, finding the appropriate way to address the falsehoods in a way that doesn't cripple what you're trying to do with your software. So I'm going to read through some of the falsehoods that I found through that original GitHub link. This one comes, these are actually falsehoods, programmers believe, about job applicants, and it comes from Creatrix Tira on medium. Hopefully I got that name correct. But let's read through a couple of these. One job is associated with one company only, and one job is associated with one role only, and one supervisor only. Jobs always have supervisors or managers, and they always have a set start date and may even have a set end date. Jobs only take place during one period of time when that period is done, it's done. And again, I'm reading these directly from Creatrix, the post that Creatrix made. I'm going to scroll down and read a few of these further down. The applicant has an email address. The applicant has an address. The applicant went to a conventional school or university. The applicant's grades were scored on a GPA basis. You see how these assumptions, they seem reasonable. They're very few applicants who would apply for a programming job that don't necessarily have an email address. But if that were to occur, how are you handling it? Now this probably doesn't apply to a small company that only has a handful of applicants, but perhaps it does apply to a larger company. Let's switch tracks a little bit and talk about assumptions or falsehoods. The programmers believe about something like REST APIs. This comes from the SLink P blog, once again linked from that original GitHub post. And all of these assumptions are wrong. All right, that's the disclaimer, the top of this article, which was posted back in December of 2015. All right, here we go. Successful status is always 200. This is definitely not true, right? Sometimes you get a 201, for example. Successful status is always one of the documented statuses. Perhaps we use a special status that we've defined for ourselves. An API that is documented as returning errors in JSON format will always return a parsable JSON error response. This is a bad assumption. It would be a good idea, probably, if you're designing an API to try to do this, but it's not necessarily always going to happen. Moving down the document, this one's one of my favorites. Auth will be done, authentication will be done by some common standard, such as OAuth. If you believe this and you've ever encountered a situation where this isn't true, this can greatly affect the way that you design your software and your timeline and all of the other implications of how you would work with a given API, if it's not a standard authentication system, then you have a lot more to think about. We're going to round out the list with a couple of falsehoods about testing. This actually comes from a thread on Ministry of Testing.com. I've never actually even seen this site, but club. ministryoftesting.com. I'm going to read some of the responses here. There are best practices that apply in all situations. This is definitely not true, right? There are not best practices that will apply in all situations. There are only best practices that will apply within a given context. You can automate all of your tests. This is definitely not always true. You cannot automate any of your tests. You can test everything in your application. Tests will make your application better. All good programmers run tests. Bad programmers don't run tests. And actually at this point, I'm adding to the list myself. These past few have been my additions to the list. There are so many of these falsehoods. I want to take a broad step back and think about the structure of a falsehood and how we can think more holistically about the way that we treat these discussions. When you're making decisions based off of some effect or some assumption of effect, it makes sense to take a moment to determine how important is it that this fact is 100% true. Am I okay if the fact is actually not a complete proof? Am I okay if this is more of a heuristic? Can I still operate based on this? Because here's the reality. A lot of the time as a programmer, you're going to operate based on these heuristics because it's the only cost-effective decision to make. And it's also an intuitive decision to make. You're not going to avoid all of these all the time. The important thing is to know when are the expensive ones going to happen. For example, assuming that testing your application will inherently eliminate all bugs, this is a very expensive assumption. It's a very dangerous assumption. Because you're going to pour a lot of energy into testing, but you may also assume that your application will be bug-free and perhaps you won't take the appropriate measures to protect against scenarios where bugs actually do happen. So how can we address this better? Well just knowing about the falsehoods doesn't necessarily make you less prone to believing them. This is the same truth that you face with biases. The reality of understanding or having an academic knowledge of bias doesn't make you less prone to experiencing or participating in those biases. Instead we have to be proactive. We have to protect ourselves against falling victim to those things by being proactive. So what are some ways that we can be proactive about these falsehoods? Well there's a very simple exercise you can do when making any weighty decision, take a moment and write down the things that you are assuming. Write down the things that you know for a fact are true and then check that knowledge. Check yourself to ensure that the things that you know are true are actually true. If you do this with a team and you do it separately without seeing each other's answers, it's very likely that there will be discrepancies between your lists. Have a meeting after you come together with these lists, have a meeting and discuss the discrepancies, discuss the differences in the assumptions that are on your lists. Finally, when you do experience pain, when you experience some kind of failure, take a moment and reflect on which falsehoods may have contributed to that failure. What falsehoods did you believe in that moment? Take a moment to identify the important ones for your business. A great example of this for the people I clear bit is the assumption that a given company only has one person titled as CEO. It's very possible that in the information that we receive, we could see two, three, five people with that title next to their name. If we operate on the assumption that only one person could possibly have that title, then we're going to have frustrating experiences and unclean data for our users. And here's the important point, the reason I bring up this specific example. That specific falsehood is not necessarily going to be important to you in your business. It may be a trivial fact in your business, that falsehood. But it's important to identify the falsehoods that are not trivial to you personally and also to the company that you work in, the domain that you work in. Thank you so much for listening to today's episode of Developer Tea. Make sure you go and check out these lists of falsehoods. Really interesting topics that are brought up, interesting falsehoods that I have never really thought about until I actually saw them written out explicitly the way that they're written out in these lists. Thank you again for listening. Thank you to Digital Ocean for making today's episode possible. Go to do.co slash TEA that's DO.co slash T and get $100 worth of credit on Digital Ocean Services today. Thank you so much for listening and until next time, enjoy your tea.