How is it possible that we miscommunicate even when we try our best? Not too. And how is it possible that a person that we know very well can communicate a message to us and somehow we don't understand it? Maybe we fundamentally don't understand it. We don't even understand what they mean. That's what we're talking about in today's episode of Developer Tea. We're discussing the theory of communication. We started talking about this in the last episode and I want to finish it up today by talking about the other four parts of the theory of communication. As a quick recap in the last episode, we discussed the human parts of communication. That is the messenger in our little story we were talking about the coder, you, the hero, the protagonist of the story who's trying to write some code and get it accepted into a code base. And you're doing this maybe based off of some kind of specification. There's been communication about the code. And then you have an audience. This is your team, your multifunctional team, all with different backgrounds and different motivations. And so they're all receiving the message differently. We have four more parts to this theory of communication that we want to discuss in today's episode. Those four parts are the medium, the message itself, feedback, and noise. In this case, code is our medium. It's kind of an interesting medium because it's separated from temporality. But don't experience it in a particular time. And many times we experience it asynchronously. We read different parts of the code and we may scan across it. Think about the medium as the physical experience of the message. We experience code in many different ways. We can read it directly. We can read it in the context of, you know, what is is changing. I'm thinking, for example, of the files changed that we see on GitHub. We can also be a part of the pairing process. So in this way, we kind of see the message being developed on the medium. The medium of code is also interesting because it doesn't take on a single form. And in many ways, it is more abstract. It's difficult to even call it visual because if you change the font between one computer and another or if you use a different editor or a different color theme, that visual experience shifts pretty dramatically. For this reason, code should be thought of more as a symbolic message. And in other episodes, we've talked briefly about the concept and the study of semiotics. The idea that we have different symbols and those symbols mean different things to humans. There's probably some piece of code that you could read that would make you nostalgic. There's probably another piece of code that you could read that might even make you a little bit anxious. Ultimately, the study of semiotics talks about how we develop meaning for symbols. And when we develop meaning for different types of code, sometimes that meaning is not connected so much to a motion as it is quite simply to memory. We can remember, for example, a particular pattern that we used in an application. And if we see that pattern again, that is a tool for communication. We can expect certain things to be true and therefore we don't have to read the whole message. If we see a common pattern, then we can kind of skip over it. But it shouldn't be glossed over that when we have a communication tool that is largely based on symbolic meaning rather than explicit meaning. Then we have to understand that our reactions to those symbols are largely conditioned. This is why when we see a lot of code with the same patterns, we have a conditioned response to those patterns. This is also a kind of justification for the concept of identifying code smells. This feeling, this intuition, that something that you're doing feels wrong, but you can't really put your finger on it. There's not really an explicit problem that you can identify. These are intuitions that you develop through some kind of conditioning. Perhaps you did something similar in the past enough times and you experienced a negative experience after that enough times that you ended up being conditioned. All of this makes code an incredibly interesting medium. It is both expressive and controlled. It's human, but it's also intended for machines. We're going to talk next about the message. And interestingly, the message is what we're going to spend probably the least amount of time on. It's not because it's unimportant, but because the discussion around messaging is a different day. The understanding of this messaging paradigm. The idea of the message is that the content and the structure of how we build our code, for example, can change the way that people see it. This seems obvious, but it turns out that because there are so many ways to solve a problem, when you try to solve it in one particular way, another way becomes apparent. You can think of this as kind of the distinction between information and raw data. Information is something that we can understand. It's something that we can parse. We can make sense of. But raw data may or may not be. If we look at raw data, we may not be able to draw conclusions from it. If you think about the message as building something for the audience, the message needs to be with intention. That's really the key for understanding this communication theory. The message is not the result of the creator, the messenger, but rather it is with intent for the audience. Those are going to be the most effective messages. The model doesn't necessarily dictate how to create a good message. It doesn't dictate whether the message should or shouldn't be heard by the audience. It simply dictates that a message is being sent. The structure of that message is important and it's encapsulated by this particular piece of the theory. It's possible that a different format, a different medium, could carry a similar message. But it's important to note that the medium has an extensive effect on the way that we perceive the message. Marshall McCleoon was famous for talking about this very subject. He said that the medium is the message. In many ways, what McCleoon was suggesting is that we often overlook the importance of the medium. The message seems like it's the meat. It seems like it's the most important piece of the puzzle, but we often experience unintended consequences as a result of the medium. This is true for developers. We may not be able to construct what we're trying to say perfectly in code, perhaps because of a restriction in the medium. Perhaps our message would be better conveyed in a speech or in some kind of visual representation, but typically we don't have access to those kinds of media in order to express what we're doing in code. This is the complicated nature of the job of being a software developer. We have to learn how to persuade with messages that are built in the medium of code. We're going to take a quick sponsor break, and then we're going to come back and talk about the other two elements of the theory of communication that is feedback and noise right after the sponsor break. Speaking of different channels of communication, it's important to understand the channels that you are using to listen to your users and their experience. Sometimes they're not going to report to you the errors that they experience. You may need a better channel. A better channel to understand the errors that are happening in your application, because the truth is if you treat your users like an offsite QA team, they're probably going to quit that job. Not only because you aren't paying them for that, but because it's really a terrible user experience to be the first to see an error. If you want to get out in front of your users experiencing errors in your application, then I encourage you to check out CENTRY. CENTRY is going to let you know, by the way, in pretty much any channel that you use, you can get alerts and Slack, for example, you're going to find out about these errors before your users do. And CENTRY also gives you all the information that you need to solve the problem that is causing the error in the first place. Not only do they give you things like the stack trace, so you can look directly in CENTRY at the error that you're seeing rather than digging through a bunch of logs. You also get linked directly to the commit to the code that is causing those errors to happen in the first place. Go ahead and check it out, CENTRY.IO. Thank you again to CENTRY for sponsoring today's episode again, CENTRY.IO. We're discussing the theory of communication in today's episode and in the previous episode of Developer Tea. And we've talked about the messenger and the audience, the human elements of communication models, and then we've talked about the medium as well as the message that is code being the medium and the code that you have written being the message. Now that message is an embodiment of some kind of idea that you've tried to express. Perhaps the code is not very good at expressing it. And so the process of writing code is often one that has a lot of feedback. Now where is this feedback coming from? And really we need to merge the discussion on feedback with noise, because often as developers, what we think is feedback is noise. Sometimes what we think is noise is actually feedback. Examples of feedback could be someone talking to us about how they believe the code should work. This is the most obvious form of feedback. It's direct feedback. It's feedback that we're looking for. We're looking for feedback on a pull request, for example. Unless obvious forms of feedback, though, can come from things like non-humans. In the same way that a speech or a written letter can be spell checked, we can gain feedback from systems that humans have created to provide automated feedback to us. So for example, our test suite failing. This is meaningful feedback. And it's not necessarily a machine that's providing it, because it's a human system, a human definition that we've created and kind of offset. We've embedded that knowledge into a test suite. And now we're checking ourselves against that embedded knowledge. This is also similar to metric systems, like performance profilers or even compilers. These systems provide us feedback on what we've created. Now sometimes this feedback is more subjective. For example, code-linting. Our code may work perfectly fine, but we use the linter often to enforce some kind of opinionated code style. But a lot of the feedback that we receive is also implicit. It is disconnected from a specific channel that we're looking for that feedback in. We can receive feedback in nonverbal cues. And we can see received delayed feedback from our actions from before, from a feature that we built three months ago. We can even receive feedback that wasn't really intended for us, because we're collaborating on a team. And perhaps we are misattributing some particular reaction to someone else's code, and that attributes to our code, right, to whatever it is that we are building. So feedback can be difficult, and it can be difficult to parse exactly where it's coming from. And sometimes that feedback is actually noise. And noise is much harder to control, and it's also hard to delineate sometimes between feedback and noise. For example, let's say that we pushed some code, and shortly thereafter we had users complaining that they don't like some particular feature. And maybe they don't like the feature that we just pushed. Now sometimes that could result in negative messages, and those negative messages may be towards the decision to write that code in that particular way. And perhaps we gather around, and we hold a retro, and we try to understand why is it that we made this decision, and users don't like it. The truth is that often we connect an outcome to a decision. We connect a result to an intention. The decision-making process should be disconnected and not judged based on the outcome, but instead judged on the quality of the decision with respect to the available information. So how does this work out? Well, essentially, if you're looking to judge a decision that you've made in code, you can go with the age old mantra of the proof is in the pudding, or look at the results of that code, kind of retrospectively, and judge whether it was a good decision based on the outcomes. You can learn from those outcomes, but often outcomes are not necessarily the direct result of whatever that communication was. And so we get noisy feedback, right? A lot of kind of randomness that gets added into our feedback systems, because we are not necessarily controlling a lot of the time, controlling how we are measuring those decisions. So it's important to understand that there's probably, first of all, probably more noise than you originally expected. Secondly, it's important to actively attempt to reduce the noisy feedback. Identify the likelihood for that noisy feedback, and especially identify places where noise is likely to show up. You do this as a team, do it regularly, and do it systematically. There are plenty of places where noise will show up. For example, your biases as a human, the bias that you have will introduce noise into the system, external voices, or perhaps market voices. Things that are not necessarily directly related to whatever the thing is that you are doing. Noise has a lot of sources, and unfortunately noise and feedback are often confused. I encourage you to explore this model of communication. Explore more about what it means to be the messenger, and especially for developers who are listening to this show, I encourage you to do everything you can. To understand your audience more thoroughly. If you understand your audience more thoroughly, then the message you create, the medium you use, even the feedback, and the noise that you experience, all of it will be put into perspective. And your entire intention as a developer will be to create that message for that audience. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Century for sponsoring today's episode. To get started with Century, head over to century.io today. Thank you so much for listening to this series on the construction of software. It's uncertain whether we will continue episodes on this. We're going to pause on this series for now, and this perhaps will be the end of the series. But if you would like to hear more episodes on this topic, then you can reach out to me at developert.gmail.com. You can also find me on Twitter and at developert. If you haven't yet subscribed to the teabrake challenge, I encourage you to head over to teabrakechallenge.com and subscribe today. This is a daily challenge that gets sent to your inbox. And by the way, one of the coolest experiences that I've had in the history of the show, the developer Mark Provin, Mark is a developer at the BBC, he created an Alexa skill for the teabrake challenge. You can go and install Developer Tea as a skill for your Alexa devices and then you can ask Alexa to ask Developer Tea to play today's teabrake challenge. So go and check that out. If you don't want to subscribe for some reason, you can get that over voice as well. Go and check it out. I really encourage you to subscribe so you get these in your inbox. It's a very easy way to start your day out with this kind of reconfiguring and thinking about these soft skills. It's a very simple challenge to take you less than five minutes. Thank you so much for listening to today's episode of developert.gmail.com. If you're enjoying these episodes, then I encourage you to subscribe in whatever podcasting app you use. The teabrake challenge, developert, all of these things are free to you as a developer. And if they provide any value at all, then the cost of subscription is so very low for you. I encourage you to subscribe so you can continue to improve as a developer. Thank you so much for listening and until next time, enjoy your tea.