In the last episode, we discussed the importance of becoming a communications expert. In this episode, I want to lay out what that communications model or really the summation of multiple communication models want to give you some tools for thinking about your communication. And then we're going to talk about how to apply that as we're writing code, as we're writing emails. How can we apply this theory in a way that is actually meaningful? My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on this show is to help you become a better developer. I do that by asking you questions and helping you kind of kickstart that thinking process and encouraging you to learn. I share my opinions and I encourage you to develop your own opinions. Becoming a great developer is not just about following a bunch of rules or guidelines. It's not about following step by step everything I say, even though we developed a step by step guide, the developer career roadmap. This is something that I do recommend, but just because I have this step by step guide, doesn't mean that's the only pathway to becoming a great developer. Instead, this is about that mental process and embodying really this challenge, right? This challenge to constantly be bettering yourself. There's so many ways that you can do that. Approaching the concept of communications and studying it, listening to this episode and then going and finding more information for yourself. That is one pathway that's going to help you become a better developer. It'll help you in every area of your life, really, but especially in your career, communications is key. If you haven't listened to that previous episode about why communications is so important, I highly recommend you go and listen to that. I want you to take a second and maybe this is something you pause the episode to do or maybe you just take a few minutes or a few seconds while I'm talking through this to think about it. What are the components of a communicated message? What are the components of a communicated message? If you like me study communications formally in school, then you may have a more formulated answer to this question, but a lot of people haven't really been taught this at a meta level. In other words, we kind of grew up learning how to talk to other people. We learned a language and then we used that language to communicate intent. We used that language to communicate emotion and frustration. We used it to communicate all kinds of things. Beyond that language that we learned, we also learned the customs, the ways that we use particular words. Maybe we learned accents. Maybe we learned ways of enunciating particular things in particular ways that were specific to our family, specific to our friend group, maybe specific to our city or region or state. We kind of simultaneously learned how to decode those same things when other people are talking to us. We also, we can't just know how to speak, but we also must know how to listen and the same applies to reading and writing. We can't only know how to write, we must also know how to read. And of course, talking to a very young child versus talking to a 20 or 30 year old person is a very different process, a very different experience because a lot of communication skill has built up and a lot of extra layers of meaning have been built up over the years. So communications is not a simple subject. Understanding how communication happens is not a simple subject, but there are ways to go about wrapping your mind around how this works. So I want to give you this model and I want to kind of point you in the right direction so that you can go and do an even deeper dive beyond this kind of deeper dive. So I want you to kind of take on that responsibility of becoming that expert for yourself. Take the time to do a little bit more research, understand a little bit more about the differences of these models, maybe the history of communications research in pretty much every fundamental communications model, not all of them, but most of them. There is a sender or something that emits a message, right? In this, in a scenario where you're talking one on one with another person, then you might be that emitter, right? So you're going to send a message. There is a medium. So the thing that the message kind of transfers over in this case air is technically the medium, but you could also say that the medium is sound waves. And of course, there is the receiver, the thing that is going to take that message, right? On top of that, there's going to be, and not every, again, not every communications model falls exactly this setup, but then there's going to be feedback, right? We've talked about this same model before in previous episodes, but feedback from the listener back to the sender. And finally, there's going to be the concept of noise. Now, this, this, a very early model was based on how telephones work. Right? So you have a collar, you have a receiver, you have the medium in that case a wire, right? And then actually kind of transferring and switching mediums from the air to the wire and then back from the wire to the air by having the earpiece, right? And then, of course, you have noise, you have static, actual static that interferes in that medium space. And for a given message, you may have feedback from the other person to you, you know, responding to that message or letting you know that they had received it. And it's perfectly fine if you hear that and you think, Oh, that's, that's another message, right? That is absolutely fine. If you're talking in person, then you may have multiple messages sending over multiple media. And I bring this up because the feedback in a person to person communication scenario is very often visual, right? So the media that I'm using to communicate to you is through the air. So you hear me speaking. And I can watch you as you hear my message. Right? As you receive my message, you respond, perhaps by nodding your head or some even involuntary body language, let's me know that you are hearing what I'm saying. So that's kind of the, you know, outside looking in perspective of a communications model. But that's not all there is to the story. And we're going to talk more about how you can understand communications models right after we talk about today's sponsor, role bar. With role bar, you can see what errors lurk in your code. We're talking about communications. We're talking about, you know, how communications can become really difficult, especially when you're dealing with communications through code. This is a difficult medium to communicate through because it's not really natural. It doesn't come normal to us. So what that means is we're going to have a lot of bugs in our code. The computer may not agree with what I said in my code, right? So that's going to have bugs. There's going to be bugs in the code. So this is tough because, you know, when you have errors in your code, a lot of times they go unseen until a user gets really upset and they reach out and tell you about that bug. Maybe they had it multiple times. Maybe you're losing users before you ever even hear from them. In role bar is going to tell you the very first time that error is encountered. You don't have to dig through logs. You don't have to rely on users to report it. Role bar works with all of your major languages and frameworks. And you can start tracking production errors in just minutes. I know because I use role bar. It's very easy to set up. You can also integrate it into pretty much everything you already use. Of course, all of your messaging applications like Slack or HipChat. You can link your source code and GitHub, Bitbucket GitLab, all of those remote repository systems. They support role bars. Well, you can turn errors into issues in your issue tracker. So, Gira Pivotal Tracker in my favorite Trello. Customers of role bar include Heroku, Twilio, Kayak, InstaCart, Zendesk Twitch. I used InstaCart yesterday, by the way. So, these are things that are really, really big systems. And they're relying on role bar. And I can guarantee you role bar will work for you. Go and check out what role bar has to offer. Specifically, they're going to give Developer Tealisteners the boot strap plan. That's free for 90 days. Role bar.com slash Developer Tea. Role bar.com slash Developer Tea. That'll get you the boot strap plan for free for 90 days. Thank you again to Role bar for sponsoring today's episode of Developer Tea. So, we're talking about communications models. We already set up this idea of the sender, the receiver, the media, the feedback. And finally, the noise. But there's more to the story than this. And that's because we're kind of looking at this from the outside perspective. If you take yourself into this model and you become the sender, you become the receiver, then you can recognize that there's more to the story. So, the first thing that I want to identify is the expanded concept of noise. We talked about noise being kind of an interference in the medium. So, for example, static or, you know, if I can't hear you speaking very well, then that can be a problem. This is particularly true over a digital media kind of device. If I had poor audio quality, then you would have difficulty hearing this message. But there are other types of noise as well. For example, if you were distracted, let's say you're trying to listen to this podcast and you're trying to code at the same time. This is something that I don't recommend, by the way. If you found a way to make it work, then good for you. But most people have difficulty actually focusing on what I'm saying and on the code that they are writing. If you had to recall the last 30 seconds worth of what I just said and you're coding right now, you probably wouldn't be able to do it. And that's an example of noise. Another example of noise might be the semantic noise. In other words, if I use really difficult to understand words or if my enunciation is strange or maybe you aren't used to, you know, my particular accent or my choice of words, then those differences can act as noise as well. There's other noise. For example, if you're hungry or if you have a bias towards or against the sender, this is something that can go undetected. You may not even know that you have a bias towards or against a particular person. Maybe you identify with them because you know that they come from the same place that you were born or maybe they look like somebody that you had an interpersonal conflict with in the past. And so you're using that unconsciously using and drawing on that experience to have a negative bias towards that message sender. So we aren't commenting on whether or not this is a good thing or how to eliminate those biases, but rather that they exist and that it's important to understand that those kinds of things exist. All of this is examples. More graduated examples of noise in a communication model. Now the final concept that I want to call out in today's episode and once again, this doesn't cover, you know, all of the bases of communication models, of communication theories. You know, there's tons of research that has been done, especially in the last 100 years or so. And I recommend that you go and at least peruse over some of that research. But for the sake of today's episode, I want to call out, you know, two more concepts and really they're the same concept. But it's the concept of encoding and decoding that message. So I may have a message that I want to send to you that I want to communicate to you. And in my mind, I have some kind of meaning that I want to convey. There's multiple ways that I can communicate with the people who listen to Developer Tea. Obviously, the most obvious one is the one that you're listening to right now. This medium of me recording an episode and then, you know, a week or two weeks later, you hearing that episode. And so there is an element of time shifting that exists here. But this encoding is not we're talking about, you know, audio encoding here. We're talking about me taking these ideas and translating them from something that exists inside of my head, all of my memories and all of the learning that I've done, all the associative things that I have in my mind. I take all of that and I create a message that I convey to you through spoken word. And this is not a trivial part of communication. And in fact, this is probably the part that requires the most practice. Because the way that you encode a message has a profound impact on the substance of that message. Let me say that again. The way that you encode a message effectively creates the content of a message. If you take from your brain, something that you understand and try to convey it in a way that is confusing. Or if you convey it in the wrong language, for example, right? If you speak a different language than me and I encode my message to you and spoken word in the wrong language, that's the most obvious example of encoding and decoding not really matching up. But the process of encoding, if you want to be a communications expert, when you send a message, when you formulate a message to be decoded by another person, a receiver, it's important that you think for a moment about how they will decode that message. This is why understanding another person's motivations, like for example, understanding the clients' motivations or understanding your boss's motivations. You know, we've said this multiple times on the show. People ask all the time, you know, how can I get a raise? This is a very common question. How can I approach the conversation of getting a raise? How can I get hired? How can I get someone to believe in me enough to pay me or to increase my pay? This is a very common question. And the most important answer that I can give you is to understand your boss. Understand the motivations, the goals of your boss. And if you can find a way to communicate your alignment with those goals. And what that means is, formulating a message, the internal message to you maybe I want to communicate my alignment with my boss's goals, or with my potential employer's goals. Formulating that message internally and then encoding it in a way that the boss or the potential employer is going to understand and ultimately act on. And that's really kind of the measurement of your communication effectiveness. Can I communicate an idea well enough to persuade someone to act in a particular way, to make a particular decision? Not in a manipulative way. That's not what we're talking about. If you use these tools of understanding communication in order to manipulate other people in sinister or otherwise self-interested ways, then that's not what we're proposing here. I'm not a proponent of doing that. And eventually, that's going to come around and bite you. Somebody's going to recognize that you are manipulative. Instead, if you use these communication tools to better empathize, to better understand other people, right? So that encoding process is not about you creating a message that you would understand. Right? That's the important thing. You already understand your own message. There's no value to be gained by you if you encode a message for someone who is like you. Instead, encoding your message should be focused on the decoder. Recognizing who your audience is is an incredibly perhaps the most important and fundamental step in bettering your communication. So encoding your message intentionally with reference to what this other person and what they're going to decode that message with. Understand their experiences, their motivations, their personality types, really getting to know the people you work with. And this is why it's so important as a developer that you don't fall prey to this idea of isolationism. It's why it's so important that you don't become cynical, that you don't shut off the other people that you work with, that you start to understand that other people who are not developers, that they affect your job too. Thank you so much for listening to today's episode of Developer Tea. I hope that I've encouraged and inspired you to start thinking more about communication models to go and do your own research to actually put some time in to better your communication, to become a communications expert. This is truly a trait that all great developers share. Thank you again to Rollbar for sponsoring today's episode of Developer Tea. Once again, Rollbar is going to help you uncover errors in your code before your users do. Go and check it out. Rollbar.com-sized-Developer Tea. You're going to get 90 days for free on the Bootstrap plan. Thank you again for listening. If you don't want to miss out on future episodes, including more traits of a great developer, part of the Developer Career Roadmap series, go and subscribe and whatever podcasting app you're using. That's the thing that's playing your podcast right now. Go and subscribe and that thing. Thank you so much for listening and until next time, bye.