As the year comes to a close, many are thinking about their resolutions. In today's episode, we'll discuss one thing that I hope makes it into your resolution-making efforts.
In today's episode, I hope to challenge you to reconsider how you label your world.
Â
Thank you to  New Relic for sponsoring today's episode!
Make managing and analysis of complex digital architectures work for you. Check them out at  NewRelic.com to become a full access user with 100GB per month totally free.
Â
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.
We're coming up on the end of 2020. It's been a long year for pretty much everybody that I've been in touch with and I imagine it's been a long year for you, the listeners of this show. And as you move from one year into another, as we talked about, basically every year the show has been around, we start thinking back on the year and we think forward on the year to come. Now, there's nothing particularly special about going into a new year. There's no switch that we can flip that suddenly makes 2021 better or even worse than 2020. But our brains do have some understanding of transition, of marking time. We do care about this as human beings. And so as much as we'd like to imagine that January 1st is just another day, just like December 31st was or some random day in July, our brains actually do mark that time and we do care. And so for that reason, we talk about resolutions on this show every year. And I am hoping to inspire you with a couple of episodes about things that you may make it onto your resolution list. All right. These are things that could very likely help engineers who are listening to this show and can help people in general, even if you're not an engineer. My name is Jonathan Cutrell, 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. And on today's episode, this series, I guess, we can kind of start a series of episodes here about resolution worthy topics, resolution worthy topics. Today's episode, we're going to talk about labels. Why is it so important? The labels that we use are intentionally chosen. Why is that so important? Well, first of all, it should be obvious to anyone who listens to the show, but language matters. Language matters quite a bit. In fact, this podcast wouldn't exist if it didn't matter because the way that we use language, the way that we form the words that we use to understand a topic is the perception that we shape for ourselves. Language matters. And labels are all about language. And so when we use a label, not only are we expressing our own perception, but we're also creating our perception. We're shaping our own understanding by putting a label on something. And of course, if that label is something that we've shared in some way, we've communicated it to other people, we are somehow shaping their perception as well. So what happens when our labels shape our perception? Well, what can often happen is we end up using labels that are reductive, that are not complete, that are taking shortcuts in some way. In today's episode, I want to challenge you to reimagine your labels. This is a resolution-worthy topic because if you challenge the way you think about labeling, if you challenge the way you think about defining those labels, you are fundamentally working on your perception. This is important because our perception shapes so much of our actions. This is why one of the main things we want to do on the show is to help you gain perspective, perspective and perception are very tightly interlinked. So what I want to do in this episode is give you a couple of examples of labels that might be reductive. And reductive isn't always a bad thing necessarily. In fact, our brains require reducing, right? Dimensionality reduction is an important topic. It's an important skill to be able to master because we can't always think about every single facet of every single topic that we ever encounter. But when we need to think about those things, we should be able to recognize when the reduction is harmful. So we're going to talk about a few labels that are likely reductive. And then later on in the episode, we'll talk about ways that you can get out of labeling things in potentially harmful ways. Or perhaps a better way to put it is ways that you can put new labels or find new labels for what you're talking about. But first I want to talk about the kinds of labels that we want to inspect a little bit more. So we'll start out with something that's very much not obvious. And if you're following along at home, if you want to do a little bit of homework, I encourage you to pause this and pull out your resume. If you don't have one, then pause it for a little bit longer and go and make one. All right. And most resumes they have a section called skills. And what ends up happening is we put into our skills our own self perception of what our skills are. And very often a skill might be phrase something like this. Jonathan is an excellent presenter. This is something that you might see in a testimonial maybe from someone. And so you might put presenting or public presentation on your skill list on your resume. Now, there's nothing necessarily wrong or inaccurate about this, right? This is why it's so sneaky and why it's worth talking about that our skills are necessarily in some cases specific and reductive. But let's think for a moment about how this matters to someone who's listening or reading, who's listening to that person talk about us and provide our credentials or who's reading our resume. This label of excellent presenter, what else can we pull out of this? All right. This is reductive because it doesn't talk about what it means to be an excellent presenter. How is that valuable outside of the context of presenting? We're going to talk about how you might change that label later on in the episode. Another label is something like a catch all, all right? This is trying to jump around the real complexity of an issue and compress it into a singular concept. So for example, we might say that 2020 was not a good year because of the pandemic. This presupposes a bunch of things. And here's all the problems with what I just said, okay? This presupposes a lot of things. One that a given year should be or can be evaluated on a scale from terrible to wonderful. Certainly, a year is a long thing to judge. And each individual circumstance might change the answer for this. By reducing an entire year down to a couple of words or trying to put it on some kind of linear scale from bad to good, we often remove or compress a lot of information out of that experience. We compress a lot of information out of the label. And this can be harmful, especially if that information is particularly relevant. Let's imagine that you had three wonderful days and four terrible days. Well, if we average those out, then the week that you had on those seven days was bad. But that totally compresses out the variability in that week. Now it wouldn't be the right thing to turn around and say, oh, well, anytime there's a good day in the year or anytime there's a good day in the week, then we should say it's a good week. That's the same kind of problem in the opposite direction. You're still compressing out a lot of information. And so it makes sense to pay attention to when we are compressing things, compressing critical information, especially by applying a label. The next kind of label that we should pay a lot of attention to is when we present a contextual situation as a factual truth. The contextual situation is a factual truth. So let's imagine that there's a book that you want to buy and this book is going to help you in your career. What do you think to yourself? Well, I just don't have the money to buy this book. Very often this is the kind of labeling that we would put on the situation. It's not a single word. It's not an adjective. Instead it is an understanding or a frame, a lens that we're putting on the situation. This is just as much of a label as anything else would be. And so we're taking this label of not having enough money to buy the book and applying it to the situation, but that may not necessarily be true. We may be preloading that lens or preloading that kind of framing with a lot of implicit context. For example, do you actually not have that much money or is that money allocated towards something else already in your pre-determined budget? These are two different sets of context, but they both have completely different implications. This one most often shows up in our lives as not having or imagining labeling as if we don't have enough time to do XY or Z. Now, we're going to talk about all of these labeling techniques and how we can kind of exit or inspect at the very least our labeling and hopefully improve our labeling right after we talk about today's sponsor, New Relic. And speaking of labeling and seeing things from multiple perspectives, New Relic wants to help you see your application from all of the relevant angles. New Relic is observability made simple, after all. And monitoring a complex digital architecture typically takes a bunch of different tools. It's not just down to one tool. It takes a lot of different things coming together to make it all work. And this has meant troubleshooting by jumping between a bunch of different products, a bunch of different dashboards and data. You might have to remember 17 different logins to know what's going on with your application and New Relic wants to change that. You've designed everything you need in three products, not 17. First is a telemetry data platform which creates a fully manageable, schemalous time series database of all of your data from any source. The second is full stack observability for analyzing, visualizing and troubleshooting your whole stack. And finally, applied intelligence with all of that data, of course, we can use AI and ML to automate anomaly detection and incidence intelligence correlation. And best of all, you can get access to these things, these three services for free. There's no host space pricing, no concept upsell for more functionality. You get 100 gigabytes a month to one full access user no strings attached. Head over to new relic.com to check it out today. New Relic is observability made simple. So I want to talk about a few techniques that you can use that will help you create better labels, right? Better labels. And you can substitute perceptions or lenses for labels here. But labels tend to be a very important key to understanding this because typically we think about labels or we think about concept subjects in terms of almost a key value in our minds. When you think about a particular subject, there's likely a label that jumps to mind, right? And in our previous example of not having enough money for a book, you might immediately think of a label like unreachable or not available, right? These are labels that we use. So I want you to think about your labels more in the upcoming year. And one way to do this is to inspect or interrogate our own labels. And I'm going to give you a couple of ways that you can do that on this episode. The first way is to imagine the exact opposite. Imagine the exact opposite of whatever your label suggests. So in our book example, let's imagine that the exact opposite is I do have enough money to buy this book. Now is either one of these falsifiable? In other words, can we prove without any kind of flexibility or contact shifting that either of these statements is true or false? And once we can recognize that, for example, in this case, if the context was implicit, right? If the context was implicit, then we can change the context to make the opposite true. In other words, if you came in to believing that you don't have enough money for a book, because you have an implied context that says that your money has to go towards some bill, for example, or that you're already spending your money on some other thing. If you change that statement and you say, okay, how can I make it true that I do have enough money for this book? Well, I can change the context. I can change my budget in some way, right? I can, instead of buying that other thing that I don't need, I can buy the book. And so I do have enough money for the book. And the outcome here should be, I do have enough money for the book, but I have chosen to spend it in another place. And what ends up happening when we do these opposites, right? When we kind of invert our statements, is we recognize what things were implied in our original statements. So what this requires you to do is become incredibly aware of the things that you otherwise were ignoring. And instead of making everything implied, it makes certain that you're creating a habit of making things more explicit. And so what this will help you do in addition to making things more explicit is identify areas that require change, right? Or that might require some shift in context or shift in understanding. And so you may want to buy the book, but you've chosen to spend your money elsewhere in order to buy the book. You need to change your decision about how to spend the money. If we apply this to spending our time, you can say, okay, well, I didn't have enough time to do that thing. Maybe you did have enough time, but instead you chose to spend that time, I don't know, listening to this podcast, right? You chose to spend that time in some other way. And if you know that you've chosen to spend your time in some other way, then you can start to inspect your choices a little more clearly. And this is why we've kind of expounded out now in this concept of adding labels. This is why inspecting our labels matters so much. If we say, well, I didn't have time to do it, then we allow ourselves to believe that that's unequivocally true because the label says it's true rather than interrogating that label. Is it actually true that I didn't have the time? I'm going to share with you two more techniques to refactor your labels, right? The second technique is to imagine what else must be true. This is an abstraction technique where you can think about this as a zoom-up technique. In our very first example of outlining our skills on our resume, if we are a good presenter, if we have the skill of being a good presenter, then what else must be true? Well, we probably need to have some understanding for communication skills. We probably need to have some understanding for how a good presentation should be structured, and so maybe we have some design skill. We probably need to be able to educate other people. Perhaps we even have some teaching skills. There's some abstract skills that all are necessary to be a good presenter. These abstract skills are likely to be more portable. This is the key that I want you to focus on when you're zooming out of a label. Looking out of a label in order to make whatever it is that you're talking about, make sense in more than one place. Make it portable. The information that you have, understand it in a way that you can compare it to another situation, where you can port it into another situation. Why is this helpful? Well, if you can compare your situation to something else, then you're creating a model. When we talk about this on the show, you've probably heard other podcasts that talk about mental models all of the time. This is how we extract models out of our daily lives. We take these labels and we go up above the label and we ask the question, what else must be true? When we ask this question and we zoom up out, now we can say, okay, I have communication skills. What other things can communication skills apply to? This is particularly important, for example, for your resume, because if you can talk about portable skills, rather than atomic skills like being a presenter, having a portable skill like being a good communicator, now applies in many other situations rather than just when there's a presentation to give. So we talked about two techniques. The first is to think about the exact opposite. Invert whatever it is that you, whatever that label was. The second technique is to zoom up out or ask the question, what else must be true, but the goal of finding something that is portable from one situation, one domain to another domain. The final kind of way of thinking or refactoring technique for your labels is to zoom in, to zoom in. What do we mean by this? Well, a lot of our labels are fundamentally about collecting a lot of complex information and reducing it down to much less complex information. This is the definition of heuristics. Heuristics are a way of thinking that takes out a lot of the complexity of what you're thinking about. But sometimes the things that get compressed out are really important, like we talked about in our example about washing the entire year of 2020 as bad. This compresses a lot of information and there are a lot of other more harmful kind of labels that we can apply that are equally damaging and compressing very important information as well. For example, what is a good developer? This is very reductive. It requires us to create on a singular scale what it means to be a good developer. This can be instructive in some ways because there are some things that most good developers share. But if we were to imagine that there's only one prescription for being a good developer, then we've created this very restrictive environment where multiple skill sets and multiple perspectives are kind of eradicated in favor of a more reductive one. So the technique here is to imagine that you couldn't have that broad label. Imagine that you had to describe a software engineer without using the term software engineer. Now you have to go down to a more component level. If you can think about composition in software engineering, you can probably think about composition as it relates to your labels. Think about the things that make up this particular person. What is it that we appreciate about the work that they do rather than trying to say that the work that they do is what makes a good engineer. So in this example about washing the entire year as good or bad, we might instead say there are parts of this year that were difficult. This is a much richer statement. There are parts of this year. The pandemic was by and large difficult for me. That might be a richer statement than saying, well, 2020 was a terrible year. And this also allows for the good to come back through. To be able to say, oh, but there was a wonderful experience that I had in some month of this year. Despite the fact that it was happening in parallel to this other not so great situation. So it's important to be able to do this because what you're doing is you're allowing the granularity of a given situation to shine through rather than trying to collapse at all into a singular statement, a singular label. Hopefully, this is a challenging way for you to think about the words that you use, the concepts that you use to wrap up your life because we do this in all aspects of our lives. We imagine things through as reductive of a lens as possible, not because we're malicious or because we're short-sighted, but because this is what makes our brains work efficiently. This is important for our brains to be able to do, but it's also necessary for us as thinking human beings to request from our brain to think a little bit more sometimes, to find out in what situations are those labels actually not helping us achieve what we care about achieving. Thanks so much for listening to this episode. Thank you to today's sponsor, New Relic. We wouldn't be able to do this show without two things. One, you listening and two are sponsors. New Relic is observability made simple. Head over to newrelic.com to get started with one full-axis user, a hundred gigabytes a month, all for free. If you enjoyed this episode and you think someone else you know might enjoy it as well, please share the episode with that person. As it turns out, this is the best way to help this show continue to grow and reach new engineers. Thank you.