How is it possible that we miscommunicate even when we try our best not to? 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 part 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. We don't experience it in a particular time. And many times we experience it asynchronously. We don't experience it in a particular time. We don't experience it in a particular time. We don't experience it in a particular time. We don't experience it in a particular time. We read different parts of the code and may scan across it. 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 it 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. We can also be a part of the pairing process. 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 use to help you. But if you're a computer, you could use it to help you. 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 emotion 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 the information that we have, we can expect certain things to be true. And if we 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. 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 difficult and difficult process. But it's a really 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 discussion than the understanding of this messaging paradigm. So 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 think about the message. And so 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 think about the message. Now, 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 is something that we can understand. It's something that we can parse, we can make sense of. And so if you think about the message as building something for the audience, the message needs to be with intention. And that's really the key for understanding this communication theory. That the message is not the result of the creator, the creator of the message. It's the result of the creator of the message. And so if you think about the message as building something for the audience, the message may not be the result of the creator of the message. At the same time, the message may not be the result of the creator of the message. but rather it is with intent for the audience. Those are going to be the most effective messages. Now, 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, and 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 McLuhan was famous for talking about this very subject. He said that, that the medium is the message. In many ways, what McLuhan 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. And this is true for developers. We may not be able to, for example, 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 this 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 Sentry. Sentry is going to let you know, by the way, in pretty much any channel that you use, that you're using. You can get alerts in Slack, for example. You're going to find out about these errors before your users do. And Sentry 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 Sentry at the error that you're seeing, rather than digging through a bunch of logs, you also get linked directly to the community. So you can actually commit to the code that is causing those errors to happen in the first place. Go and check it out. Sentry.io. Thank you again to Sentry for sponsoring today's episode. Again, Sentry.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, and the 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 example. It's not just an 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. Less 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. 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 something that we're trying to do. 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 non-verbal cues. And we can see... Receive 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. So, we can see that feedback is not really in our control. We can see that feedback is in our control. We can see that feedback is in our control. Because we're collaborating on a team and perhaps we're misattributing some particular reaction to someone else's code and that attributes to our code. To whatever it is that we're 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 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. 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. Or 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. And our 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't 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. We get a lot of kind of ruckus. We get 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. Voice has a lot of sources and unfortunately, Voice 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 the 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 Sentry for sponsoring today's episode. To get started with Sentry, head over to sentry.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 developertea at gmail.com. You can also find me on Twitter at developertea. If you haven't yet subscribed to the Tea Break Challenge, I encourage you to head over to teabreakchallenge.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 Provan. Mark is a developer at the BBC. He created an Alexa skill for the Tea Break 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 Tea Break 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. Should take you less than five minutes. Thank you so much for listening to today's episode of Developer Tea. If you're enjoying these episodes. Then I encourage you to subscribe in whatever podcast. You use the Tea Break Challenge. Developer Tea. 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. See you soon.