« All Episodes

The Critical Importance of Labels

Published 8/5/2020

🙏 Today's Episode is Brought To you by: Command Line Heroes

Command Line Heroes is an original podcast from Red Hat about the people who transform technology from the command line up.

A new season was released on July 14th,  in which Author Clive Thompson joins host Saron Yitbarek to share his insights from over 200 interviews with coders for his latest book.

This 3-episode mini-season will cover: the many paths to a coding career, where coders work, and what coders expect from each other.

Head on over to the podcast platform of your choice to listen and subscribe for free to Command Line Heroes.

 

📮 Ask a Question 

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. 

🧡 Leave a Review

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.

Transcript (Generated by OpenAI Whisper)
One of the hardest things you'll do in your career is name things. This has been talked about on this show and of course in plenty of literature and in the folklore of programming. So you've probably heard of this reality that naming things is one of the hardest problems in computer science. So why is that? And why are names such an important part of what we do? That's what we're talking about in today's episode. My name is Jonathan Cutrell. You're listening to Developer Tea and my goal on this show is to help driven developers like you find clarity, perspective and purpose in their careers. This podcast would not exist without labels because what exactly is a label? What exactly is a name? Well, these are simply words, right? There are words, there are some kind of utterance and in code, it's some series of symbols that represent an idea. And this is why it's so critical to think about labeling and to think about the names that we give things. This podcast wouldn't exist without these words but computer science in general wouldn't exist without labels. Because as it turns out, pretty much all of programming is about figuring out ways to arrange these words together. Now, of course, some of what we're talking about is a little bit over the top, right? We're exaggerating to make the point. Of course, there's math involved. Of course, there's logic involved but words are a fundamental part of what we do as engineers and they matter deeply. And we're going to talk about why they matter so deeply in this episode and why it makes sense to choose your names carefully. Our language shapes the way we see the world, not just in subtle ways but in entirely life changing ways in some instances. Our language is how we understand how to articulate what we feel, what we think, and perhaps most importantly, how to communicate with other human beings. And so when we have a shared understanding, when we have a definition of a given word that is shared, we can communicate a lot of information in very succinct and efficient ways, but here's the problem. Sometimes our definitions, in fact, I would argue pretty much all the time, our definitions are in exact. What one person understands as the meaning of a given word is not necessarily the same as what another person understands. Now, you can easily argue that the essence of that word, the essence of the meaning of that word, is likely the same, especially given the same language in the same cultural context and some of the same experiences in life, some of the same exposures in life, of course, this is going to help provide some basis for similarity and language. But at the extreme end, you can imagine two people who live in totally different cultures, imagine that these are, let's say, two indigenous tribes that have never been exposed to each other's languages and they've never been exposed to any kind of media. Of course, their language has zero overlap. So this is important to understand because there is a continuum. Our language is not exact. And in fact, it's easily argued that every person's meaning, their construct for a given word, is slightly different or sometimes drastically different from the next person. So it's easy to understand why we can get into debates over language. What something means to one person is not necessarily what it means to another. But this is where things get tricky and it's important to pay attention here. When we have a shared experience where we try to negotiate the meaning of a given word, where we try to come to terms with our differences about our perception about a given word, then that experience changes the meaning for both of us. As an example, we all have a new understanding, a new perception of what the word mask means. The things that come up in your mind when you hear the word mask are probably, if you're like most people, very different than what they were even just a few short months ago. And in fact, what we think about when we hear the word mask has drastically changed and the context of that word has so much more information attached to it than it did before. When you think of the term loaded, right, when you think of loaded language, this is exactly what that is referring to. This is also why, for example, a term can become more sensitive over time. It may not have been a cultural issue two years ago, for example, and it's completely valid for it to become a cultural issue as a result of new experiences that are ongoing. Because the meaning of any given word is fluid. It's changing. It's dependent, heavily dependent on its context and the experiences that shape that meaning. Now, I bet you didn't expect all of this kind of thinking to go into simply just words naming. Why does this matter in our work? That's what we're going to talk about right after we talk about today's sponsor, Command Line Heroes. Command Line Heroes comes to you from Red Hat. The brand new season was just released with author Clive Thompson joined by host Soranya Barak. This three episode many season will cover the many paths to a coding career, what coders expect from each other, and where they actually work. Past seasons have ranged from the history of open source to the origins of popular programming languages and most recently the creation of revolutionary hardware. You can head on over to the podcast platform of your choice, for example, maybe the one you're using right now to listen and subscribe to Command Line Heroes. Thanks again to Command Line Heroes and Red Hat for sponsoring today's episode of Developer Tea. So, we've gone off on a little tangent about what it means to have a dynamic meaning for a given word. Why language is so important at a broad scale? But how does this impact our code? After all, if I have a variable that's named X or a variable that's named Y, how much meaning can I really pack into a given variable name, a given function name, why does this matter to me as an engineer? Here's what's critical. Even in those scenarios where you have a variable named X or variable named Y, you're making an assumption. You're making an assumption about the future reader of this code. In particular, the use of the variable X and Y assumes that someone is familiar with the construct, with, for example, an X, Y axis, the graph where it has an X axis going left to right and a Y axis going from bottom to top, or at least familiar with the concept. And if someone isn't familiar with that, well, it turns out that those variable names, they might be familiar with them from other code, but they may not necessarily know the underlying implication there. Now this isn't a strong offender. This isn't going to cause a major issue in your code necessarily. This is something that's easy, relatively easy to teach. What about much more culturally rich naming structures? For example, let's say you have special object types and you call them something, we'll give it the name Foo, and Foo's have a lot of cultural context within the organization. There's a lot of experience and a lot of meaning when you say Foo around the people in your company. Well, Foo doesn't have any meaning to somebody who is a newcomer to the company, and just carrying over the meaning from within your company means that the connotations that may go along with that code could change the way that we treat the code. Like, give you a little bit more of a concrete example. How would you treat a variable if it was named password, and how would you treat a variable if it was named image? In the first scenario, you might be actually afraid to work with a variable named password. You don't want to accidentally reveal that password. And so in some ways, this is actually a functionally useful reality, that the words that we choose have a lot of meaning, and they can actually shape the way that we treat that code in the future. In fact, that's the whole point of choosing good names. We want someone to be careful with password. But on the other hand, if you have something named image, it may not necessarily know how to treat that, is that a file? Is it a disk image? There's a lot of ways that you can parse the word image. And so it makes sense to be more specific with our naming structures. Additionally, it makes sense to consider the extra cultural meaning that we bring to the table when we're working with our code. For example, many teams, including the team that I work on, are changing their Git branch names, their version control branch names, from master to main. This is because of the historical context of the word master. When you hear the word master, you may not bring any context to that at all. It may not be in the forefront of your mind. But it's very possible that the word master carries connotations that relate to slavery. So it's important that we recognize that these contexts are not just our own. That we should be thinking about others when we name our variables. Whether it's for very simple and practical reasons, or if it's for culturally sensitive reasons, we shouldn't assume that everyone has the same meaning for the words. That we choose to use as we do. Thanks so much for listening to today's episode of Developer Tea. Of course, a huge thank you to Red Hat and command line heroes. And whatever podcasting app of your choice, you can go and subscribe and listen to the newest season of command line heroes. This episode and every other episode of Developer Teak may be found at spec.fm. Today's episode is produced by Sarah Jackson. My name is Jonathan Cutrell, and until next time, enjoy your tea.