Hey everyone, welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we're talking about language barriers. When I say language barriers, I'm not talking about different spoken languages like English versus Spanish and I'm also not talking about programming languages themselves. What I'm actually talking about is a vocabulary difference, a problem with vocabulary. And I can guarantee that every single person who's listening to this episode has actually experienced a language barrier similar to what I'm talking about today because you learned whatever language you speak. You had to learn what those things meant at some point. In other words, the actual word that you use for, let's say, a coffee cup or a tea cup, the actual word that you use didn't mean anything to you until you learned what that word actually meant. Now with that specific example, it's very likely that you learned what the word team meant first and then you also learned what the word cup meant separately. And then you combine those words and used some pretty powerful deductive reasoning actually to figure out that a tea cup is a cup that is made specifically for tea. Now why am I talking about tea cups? Well, this is Developer Tea, but beyond that, what we're really talking about here is understanding how we acquire language and how we acquire a vocabulary. Let's use a different word. Let's use the word refactor. Well, what does refactor actually mean? You can look at its separate parts, re and factor, the idea that you're factoring again, but what if you're not really sure exactly what that means either? This is where you'll hit a language barrier. Now you may go out and figure out how to implement different patterns of refactors. You may go out and read a book about refactoring. And these may be ways that you acquire the information, the language that you need to describe that piece of your vocabulary. So the next time you hear the word refactor, it sticks a little bit better. You understand a little bit more about what that word means. By the way, this episode is inspired by Khalid Azad. He was on this show a few episodes back. Khalid talks about learning the idea's true name in his most recent blog post. We'll post a link for that in the show notes at spec.fm, or you can go over to Khalid site, betterexplained.com. Again, the episode with Khalid was fantastic, but he talks about this idea of finding an idea's true name. One of the examples he uses is positive and negative numbers. I'm not going to ruin the punch line. The article is definitely worth reading. But if you have trouble understanding the concept of negative and positive numbers, for example, that is a language barrier. And the truth is, you may be using the wrong name altogether. Or maybe the name is somehow not correctly sitting in your mind. You may have other definitions for those words that are colliding with the newfound definition. And for you, you may need a new word to describe a particular idea. After a quick sponsor break, we're going to come back and talk about how to expand your vocabulary properly so you can get past these language barriers. I'm going to give you a few tips on how you can practice finding better articulations to the fundamental ideas that you're trying to explain. Today's episode is sponsored by Linode. As you all know, Linode has been a sponsor of Developer Tea for quite a while. And we're very thankful for Linode, not just because they are a sponsor, but because they create a great product. Linode has eight data centers and their plans started just $10 a month. And they're offering you $20 for free by signing up at our special link that's spec'd out of them slash Linode. If you're a programmer and you don't have a remote Linux server, then you're probably going to want one very soon. Linode is a fantastic option for both the hobbyist programmer, the brand new person to the field and also the advanced developers who are working on scale projects together in collaboration. And that's because Linode is built on top of the incredibly powerful Linux platform. On top of all that, Linode is hourly billing for all of their services, including long view and node balancing. Go and check it out spec.fm slash Linode. And as of this year, Linode is offering two gigabytes for their minimum. That's the minimum server has two gigabytes. So for that $10 a month tier. And again, don't forget, Linode is offering you $20 worth of credit when you sign up at our special link spec.fm slash Linode. Thank you again to Linode for sponsoring Developer Tea. So we're talking about finding better names for your ideas, getting past your language barriers. Again, some some credit goes to Khaled Zad for inspiring this episode with his fantastic article on this on a very similar subject. But I have three specific tips for programmers when it comes to language barriers, three specific tips. Number one, explain the problem or explain the idea in the plainest language that you can. We're talking not even pseudo code. We're talking about talking to someone across the table from you, explain the idea, explain the problem that you're having, explain whatever it is that you're trying to articulate to that person in the plainest language that you can. What you'll find is that there's going to be a few sticky words that come out of that conversation. For example, if you had to explain to a non programmer, what concatenation meant, string concatenation specifically. Well, you would start by saying, well, strings are essentially words or they are a list of characters that are put together. And an example may be a word. And then the next thing you may say is concatenation is when you add one string to another or when you add a list of characters to another. Now, what you've done is you've come across a new way of explaining concatenation. You're adding lists together. Another word may be merging lists together. And ultimately, this is actually another way that you can perform concatenation. If you have two arrays, you can merge those arrays together. In most languages, you can add one array to another through some kind of merging process. And the result is quite similar to concatenation. You see how when you break down something into plain language, you start seeing how these ideas can relate to one another and how you may be able to use the information that you're gaining from one method whenever you come across a different problem in the other method. So the first step, the first tip that I have for you when you're trying to get past a language barrier is in this may this may feel somewhat intuitive to you, but explain it in the plainest language that you can use. My second tip for you today is to use what I believe to be one of the most powerful tools in the Developer Tool belt. And that is a metaphor using a metaphor to explain your idea or your problem. Before we go any further, let me back up for a second and say these problems that I'm talking about. This is not the kind of problem where you're chasing a bug down. Maybe there's a library on your computer that you're building something on top of a different library. And the internal library is somehow not working with a version that you're using something like that. That's not the type of problem we're talking about with language barriers. Really in those situations, what you're trying to do is basically follow the line of logic to figure out what pieces broken or what thing needs to be updated. And you're going to end up doing quite a lot of Google searching. That's a little bit less about a language barrier and more about figuring out the most important thing to look for finding the most important part of that stack trace, for example. We may talk about how to find those most important messages in the stack trace in another episode. But for today's episode, the types of problems that we're talking about are design problems, ways of organizing your code as you are designing it, not after you've already designed it, encountering a problem that you're trying to fix. So in that way, we aren't really talking about bugs as much as we're talking about design problems. So my second tip, explaining it with a metaphor. Metaphors are very good for breaking down language barriers because they give your brain a model to think about relationships that doesn't necessarily have to jump the hurdles of understanding the code. In other words, you can tell a metaphor to a non-programmer and they can understand some of the fundamental relationships between the different moving pieces if the metaphor is tight enough. When I say tight enough, I mean, if those different moving pieces are actually representative in some relatively accurate way in the actual code. In fact, you can see a lot of algorithms, for example, being named after something that describes them metaphorically. An example is bubble sort. Another example is random walk. These algorithms are described with these metaphors because they can effectively simulate the properties of the metaphor itself. So I want you to spend some time with that next problem or idea that you're trying to describe and can't quite put words to it. I want you to spend some time and find an effective metaphor. This may feel a little bit laborious and you may find a metaphor that kind of half fits, but I want you to dedicate yourself to figuring out how to explain your problem or your idea with a strong metaphor. The reason that you need to practice this is because metaphors are such a powerful tool in your tool belt. We've talked about them on the show before. Again, of course, you can find that episode at spec.fm. So tip one, explain it in as plain language as you can. Tip number two, explain it with a metaphor. And finally, tip number three, explain it visually. Explain it visually. If you can draw some kind of visual representation of your idea, you don't have to use a formal diagramming method in order to accomplish this. If you can simply draw out some kind of explanation, some kind of flow for your idea and show the different moving pieces and parts, a lot of times you'll find that the piece that you were missing or perhaps the piece that you were trying to name will kind of stick out like a sore thumb. Now, the interesting thing is that you can combine all three of these tips together and really effectively wrap your mind around an idea, wrap your mind around a problem without really needing to know exactly what the name of that problem or idea is. Once again, explain it in the plainest language that you can. Secondly, explain it with a metaphor and finally, explain it visually. If you can visualize a metaphor that is arrived at by using plain language, then your mind is going to wrap around your problem or your idea much, much easier. Thank you so much for listening to today's episode. Thank you again to Collid for writing such a fantastic article over at BetterExplain.com. Thank you so much again, of course, to our wonderful sponsor, Linode. On Linode, you can get $20 of free credit by simply going to spec.fm slash Linode when you sign up today. Go and check it out. Spec.fm slash Linode. Thank you again for listening to today's episode. If you don't want to miss out on future episodes, and I guarantee you that you don't, we've got some really good content coming up, in the very near future. Take a moment to go and subscribe in whatever podcasting app you use. Thank you so much for listening to today's episode, and until next time, enjoy your tea.