How We Construct Software, Part 4b: Code and Communication
Summary
This episode continues the series on communication theory in software development, focusing on the remaining four elements of the communication model: medium, message, feedback, and noise. The host explores how code serves as a unique medium that is both expressive and controlled, human yet intended for machines, and how it operates through symbolic meaning rather than explicit communication.
The discussion examines how the medium of code affects message perception, drawing parallels to Marshall McLuhan’s concept that ‘the medium is the message.’ The host explains how code patterns create conditioned responses in developers and how this relates to concepts like code smells and developer intuition.
The episode then delves into feedback mechanisms in software development, distinguishing between direct feedback (like code reviews), automated feedback (test suites, linters), and implicit feedback from various sources. The host emphasizes the challenge of separating meaningful feedback from noise, particularly when outcomes are influenced by multiple factors beyond the original coding decisions.
Finally, the episode provides practical advice for developers to better understand their audience, reduce noisy feedback, and improve communication through code. The host encourages developers to systematically identify sources of noise and to judge decisions based on available information rather than solely on outcomes.
The episode concludes with information about the Tea Break Challenge and an Alexa skill created by a listener, Mark Provan from the BBC, demonstrating community engagement with the show’s content.
Recommendations
Concepts
- Communication Theory Model — The episode discusses a communication model with six elements: messenger, audience, medium, message, feedback, and noise. This framework helps understand how communication works in software development contexts.
- Semiotics — The study of symbols and how they create meaning. The host connects this to how developers interpret code patterns and develop conditioned responses to certain coding approaches.
- Marshall McLuhan’s ‘The Medium is the Message’ — Concept that the medium through which communication occurs shapes how the message is perceived, often more than the content itself. Applied to how the medium of code affects software communication.
Resources
- Tea Break Challenge — Daily challenge sent via email that helps developers improve their soft skills through brief, daily exercises. Also available as an Alexa skill created by listener Mark Provan.
Tools
- Sentry — Error monitoring tool that helps developers identify and fix issues before users experience them. Provides alerts through various channels like Slack and links errors directly to the problematic code commits.
Topic Timeline
- 00:00:00 — Introduction to communication problems — The episode opens by questioning why miscommunication happens even when we try our best. The host introduces the theory of communication as the day’s topic, continuing from the previous episode where they discussed the human elements (messenger and audience). Today’s focus will be on the remaining four parts: medium, message, feedback, and noise.
- 00:01:38 — Code as a communication medium — The host explores code as a unique medium that is separated from temporality and often experienced asynchronously. Code is described as symbolic rather than purely visual, with developers developing conditioned responses to patterns. This symbolic nature connects to semiotics and explains why certain code can evoke emotional or intuitive reactions.
- 00:05:52 — The message in code — Discussion of how the message in code is about intention for the audience rather than just the creator’s output. The host explains that while there are many ways to solve a problem in code, the chosen approach represents a specific message. The structure and format of code significantly affect how the message is perceived by others.
- 00:08:07 — Marshall McLuhan’s medium theory — The host references Marshall McLuhan’s famous concept that ‘the medium is the message,’ explaining how developers often overlook the importance of the coding medium itself. The medium shapes how messages are perceived and can lead to unintended consequences. This is particularly relevant for developers who must learn to persuade through the medium of code.
- 00:11:35 — Feedback in software development — Examination of feedback mechanisms, including direct feedback from team members, automated feedback from test suites and linters, and implicit feedback from various sources. The host discusses how feedback can come from both human and non-human systems, and how developers need to distinguish between meaningful feedback and noise in their work.
- 00:15:10 — Noise versus feedback — Discussion of how noise interferes with communication and how it can be difficult to distinguish from genuine feedback. The host provides examples of noisy feedback, such as user complaints that may not directly relate to coding decisions, and emphasizes the importance of not judging decisions solely based on outcomes that may be influenced by random factors.
- 00:17:56 — Practical advice for reducing noise — The host provides practical guidance for identifying and reducing noisy feedback in development work. This includes recognizing personal biases as sources of noise, systematically identifying where noise is likely to appear, and understanding that there’s probably more noise in feedback systems than developers typically expect.
- 00:18:31 — Conclusion and audience understanding — The host concludes by encouraging developers to explore the communication model further, with particular emphasis on understanding their audience more thoroughly. Better audience understanding helps shape more effective messages, appropriate medium choices, and better interpretation of feedback while filtering out noise.
Episode Info
- Podcast: Developer Tea
- Author: Jonathan Cutrell
- Category: Technology Business Careers Society & Culture
- Published: 2019-02-19T10:00:00Z
- Duration: 00:21:32
References
- URL PocketCasts: https://pocketcasts.com/podcast/developer-tea/cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263/how-we-construct-software-part-4b-code-and-communication/06295f7b-e80b-40fc-8b54-e8a4baf6c2eb
- Episode UUID: 06295f7b-e80b-40fc-8b54-e8a4baf6c2eb
Podcast Info
- Name: Developer Tea
- Type: episodic
- Site: http://www.developertea.com
- UUID: cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263
Transcript
[00:00:00] How is it possible that we miscommunicate even when we try our best not to?
[00:00:10] And how is it possible that a person that we know very well can communicate a message to us
[00:00:19] and somehow we don’t understand it?
[00:00:23] Maybe we fundamentally don’t understand it.
[00:00:27] We don’t even understand what they mean.
[00:00:32] That’s what we’re talking about in today’s episode of Developer Tea.
[00:00:36] We’re discussing the theory of communication.
[00:00:39] We started talking about this in the last episode,
[00:00:42] and I want to finish it up today by talking about the other four parts of the theory of communication.
[00:00:48] As a quick recap, in the last episode, we discussed the human part of communication.
[00:00:54] That is the messenger.
[00:00:55] In our little story, we were talking about the coder, you, the hero, the protagonist of the story,
[00:01:04] who’s trying to write some code and get it accepted into a code base.
[00:01:07] And you’re doing this maybe based off of some kind of specification.
[00:01:12] There’s been communication about the code.
[00:01:14] And then you have an audience.
[00:01:16] This is your team, your multifunctional team, all with different backgrounds and different motivations.
[00:01:22] And so they’re all receiving the message differently.
[00:01:25] We have four more parts to this theory of communication that we want to discuss in today’s episode.
[00:01:31] Those four parts are the medium, the message itself, feedback, and noise.
[00:01:38] In this case, code is our medium.
[00:01:42] It’s kind of an interesting medium because it’s separated from temporality.
[00:01:48] We don’t experience it in a particular time.
[00:01:52] And many times we experience it asynchronously.
[00:01:54] We don’t experience it in a particular time. And many times we experience it asynchronously.
[00:01:55] We don’t experience it in a particular time. And many times we experience it asynchronously.
[00:01:55] We don’t experience it in a particular time. And many times we experience it asynchronously.
[00:01:56] We read different parts of the code, and we may scan across it.
[00:02:01] Think about the medium as the physical experience of the message.
[00:02:07] We experience code in many different ways.
[00:02:10] We can read it directly.
[00:02:12] We can read it in the context of what is changing.
[00:02:16] I’m thinking, for example, of the files changed that we see on GitHub.
[00:02:21] We can also be a part of the pairing process.
[00:02:25] So, in this way, we kind of see the message being developed on the medium.
[00:02:33] The medium of code is also interesting because it doesn’t take on a single form, and in many
[00:02:39] ways it is more abstract.
[00:02:43] It’s difficult to even call it visual because if you change the font between one computer
[00:02:48] and another, or if you use a different editor or a different color theme, that visual experience shifts
[00:02:55] pretty dramatically.
[00:02:57] For this reason, code should be thought of more as a symbolic message.
[00:03:05] And in other episodes, we’ve talked briefly about the concept and the study of semiotics.
[00:03:11] The idea that we have different symbols, and those symbols mean different things to humans.
[00:03:19] There’s probably some piece of code that you could read that would make you nostalgic.
[00:03:25] There’s probably another piece of code that you could read that might even make you a little
[00:03:31] bit anxious.
[00:03:32] Ultimately, the study of semiotics talks about how we develop meaning for symbols.
[00:03:40] And when we develop meaning for different types of code, sometimes that meaning is not
[00:03:46] connected so much to emotion as it is, quite simply, to memory.
[00:03:52] We can remember, for example, a particular pattern that we can remember.
[00:03:53] For example, a particular pattern that we used in an application.
[00:03:57] And if we see that pattern again, that is a tool for communication.
[00:04:03] We can expect certain things to be true, and therefore we don’t have to read the whole message.
[00:04:10] If we see a common pattern, then we can kind of skip over it.
[00:04:14] But it shouldn’t be glossed over that when we have a communication tool that is largely
[00:04:21] based on symbolic meaning.
[00:04:23] It shouldn’t be glossed over.
[00:04:23] It shouldn’t be glossed over.
[00:04:23] It shouldn’t be glossed over.
[00:04:23] It shouldn’t be glossed over.
[00:04:23] It shouldn’t be glossed over.
[00:04:23] If we see symbolic meaning rather than explicit meaning, then we have to understand that our
[00:04:29] reactions to those symbols are largely conditioned.
[00:04:34] This is why when we see a lot of code with the same patterns, we have a conditioned response
[00:04:41] to those patterns.
[00:04:43] This is also a kind of justification for the concept of identifying code smells.
[00:04:51] This feeling, this intuition.
[00:04:53] That’s something that you’re doing feels wrong, but you can’t really put your finger
[00:04:58] on it.
[00:04:59] There’s not really an explicit problem that you can identify.
[00:05:04] These are intuitions that you develop through some kind of conditioning.
[00:05:08] Perhaps you did something similar in the past enough times, and you experienced a negative
[00:05:14] experience after that enough times that you ended up being conditioned.
[00:05:19] All of this makes code an incredibly interesting medium.
[00:05:23] It is both expressive and controlled.
[00:05:28] It’s human, but it’s also intended for machines.
[00:05:33] We’re going to talk next about the message, and interestingly, the message is what we’re
[00:05:52] going to spend.
[00:05:53] The message is what we’re going to spend the least amount of time on.
[00:05:55] It’s not because it’s unimportant, but because the discussion around messaging is a different
[00:06:02] discussion than the understanding of this messaging paradigm.
[00:06:10] The idea of the message is that the content and the structure of how we build our code,
[00:06:18] for example, can change the way that people see it.
[00:06:22] Now.
[00:06:23] It’s not obvious, but it turns out that because there are so many ways to solve a problem,
[00:06:30] when you try to solve it in one particular way, another way becomes apparent.
[00:06:37] You can think of this as kind of the distinction between information and raw data.
[00:06:44] Information is something that we can understand, it’s something that we can parse, we can make
[00:06:49] sense of.
[00:06:51] But raw data may or may not be.
[00:06:52] If we look at raw data, we may not be able to draw conclusions from it.
[00:06:59] If you think about the message as building something for the audience, the message needs
[00:07:06] to be with intention.
[00:07:10] That’s really the key for understanding this communication theory, that the message is
[00:07:17] not the result of the creator.
[00:07:19] The message is not the result of the creator.
[00:07:20] The message is not the result of the creator.
[00:07:21] The message is not the result of the creator.
[00:07:22] The message is not the result of the creator.
[00:07:23] The message is not the result of the creator.
[00:07:24] It is not a new type of messenger.
[00:07:25] But rather, it is with intent for the audience.
[00:07:27] It is not just a box of words written by the creator.
[00:07:29] It’s a booker talking with a dragon and in a mountain and creating the message from myself,
[00:07:31] not 10 times as many aye dude or talking with you on Facebook on Instagram or Facebook
[00:07:33] or Instagram but rather with intent for the audience.
[00:07:34] Those are going to be the most effective messages.
[00:07:35] Now, the model doesn’t necessarily dictate how to create a good message.
[00:07:39] It doesn’t dictate whether the message should or shouldn’t be heard by the audience.
[00:07:45] It simply dictates that a message is being sent.
[00:07:48] And the structure of that message is important.
[00:07:52] it’s encapsulated by this particular piece of the theory. It’s possible that a different format,
[00:08:00] a different medium could carry a similar message. But it’s important to note that the medium has
[00:08:07] an extensive effect on the way that we perceive the message. Marshall McLuhan was famous for
[00:08:15] talking about this very subject. He said that the medium is the message. In many ways, what
[00:08:22] McLuhan was suggesting is that we often overlook the importance of the medium. The message seems
[00:08:33] like it’s the meat. It seems like it’s the most important piece of the puzzle, but we often
[00:08:39] experience unintended consequences as a result of the medium.
[00:08:44] And this is true for developers. We may not be able to, for example, construct what we’re trying
[00:08:53] to say perfectly in code, perhaps because of a restriction in the medium. Perhaps our message
[00:09:01] would be better conveyed in a speech or in some kind of visual representation, but typically we
[00:09:09] don’t have access to those kinds of media in order to express what we’re trying to say.
[00:09:14] What we’re doing in code. This is the complicated nature of the job of being a software developer.
[00:09:23] We have to learn how to persuade with messages that are built in the medium of code.
[00:09:32] We’re going to take a quick sponsor break and then we’re going to come back and talk about
[00:09:35] the other two elements of the theory of communication. That is feedback and noise.
[00:09:44] Come on, after this sponsor break.
[00:09:50] Speaking of different channels of communication. It’s important to understand the channels that
[00:09:57] you are using to listen to your users and their experience. Sometimes they’re not going to report
[00:10:06] to you the errors that they experience. You may need a better channel. A better channel to understand
[00:10:14] The errors that are happening in your application.
[00:10:16] Because the truth is, if you treat your users like an off-site QA team,
[00:10:22] they’re probably going to quit that job.
[00:10:24] Not only because you aren’t paying them for that,
[00:10:26] but because it’s really a terrible user experience to be the first to see an error.
[00:10:33] If you want to get out in front of your users experiencing errors in your application,
[00:10:39] then I encourage you to check out Sentry.
[00:10:41] Sentry is going to let you know, by the way, in pretty much any channel that you use.
[00:10:48] You can get alerts in Slack, for example.
[00:10:51] You’re going to find out about these errors before your users do.
[00:10:56] And Sentry also gives you all the information that you need to solve the problem
[00:11:01] that is causing the error in the first place.
[00:11:04] Not only do they give you things like the stack trace,
[00:11:07] so you can look directly in Sentry at the error,
[00:11:11] that you’re seeing, rather than digging through a bunch of logs,
[00:11:14] you also get linked directly to the commit,
[00:11:18] to the code that is causing those errors to happen in the first place.
[00:11:22] Go and check it out, Sentry.io.
[00:11:25] Thank you again to Sentry for sponsoring today’s episode.
[00:11:28] Again, Sentry.io.
[00:11:35] We’re discussing the theory of communication in today’s episode
[00:11:40] and in the previous episode of,
[00:11:41] Developer Tea.
[00:11:43] And we’ve talked about the messenger and the audience,
[00:11:46] the human elements of communication models.
[00:11:49] And then we’ve talked about the medium as well as the message.
[00:11:53] That is, code being the medium
[00:11:56] and the code that you have written being the message.
[00:12:00] Now, that message is an embodiment of some kind of idea
[00:12:05] that you’ve tried to express.
[00:12:07] Perhaps the code is not very good at expressing it.
[00:12:11] And so,
[00:12:11] the process of writing code is often one that has a lot of feedback.
[00:12:17] Now, where is this feedback coming from?
[00:12:21] And really, we need to merge the discussion on feedback with noise.
[00:12:25] Because often, as developers,
[00:12:29] what we think is feedback is noise.
[00:12:32] And sometimes what we think is noise is actually feedback.
[00:12:37] Examples of feedback could be
[00:12:40] someone talking,
[00:12:41] someone talking to us about how they believe the code should work.
[00:12:46] This is the most obvious form of feedback.
[00:12:48] It’s direct feedback.
[00:12:50] It’s feedback that we’re looking for.
[00:12:52] We’re looking for feedback on a pull request, for example.
[00:12:57] Less obvious forms of feedback, though,
[00:13:00] can come from things like non-humans.
[00:13:04] In the same way that a speech or a written letter can be spell-checked,
[00:13:09] we can gain feedback,
[00:13:11] feedback from systems that humans have created
[00:13:15] to provide automated feedback to us.
[00:13:18] So, for example, our test suite failing.
[00:13:21] This is meaningful feedback.
[00:13:22] And it’s not necessarily a machine that’s providing it,
[00:13:28] because it’s a human system,
[00:13:31] a human definition,
[00:13:34] that we’ve created and kind of offset.
[00:13:38] We’ve embedded that knowledge into a test suite,
[00:13:41] and now we’re checking ourselves against that embedded knowledge.
[00:13:46] This is also similar to metric systems,
[00:13:50] like performance profilers or even compilers.
[00:13:53] These systems provide us feedback on what we’ve created.
[00:13:58] Now, sometimes this feedback is more subjective.
[00:14:01] For example, code linting.
[00:14:03] Our code may work perfectly fine,
[00:14:05] but we use the linter often to enforce some kind of approach,
[00:14:11] or we use a more opinionated code style.
[00:14:14] But a lot of the feedback that we receive is also implicit.
[00:14:19] It is disconnected from a specific channel
[00:14:24] that we’re looking for that feedback in.
[00:14:27] We can receive feedback in non-verbal cues,
[00:14:30] and we can receive delayed feedback from our actions from before,
[00:14:37] from a feature that we built three months ago.
[00:14:41] We can even receive feedback that wasn’t really intended for us,
[00:14:45] because we’re collaborating on a team,
[00:14:48] and perhaps we are misattributing some particular reaction
[00:14:52] to someone else’s code,
[00:14:55] and that attributes to our code,
[00:14:58] to whatever it is that we are building.
[00:15:01] So feedback can be difficult,
[00:15:04] and it can be difficult to parse exactly where it’s coming from,
[00:15:07] and sometimes that feedback is actually noise.
[00:15:10] And noise is much harder to control,
[00:15:14] and it’s also hard to delineate sometimes
[00:15:17] between feedback and noise.
[00:15:19] For example, let’s say that we pushed some code,
[00:15:23] and shortly thereafter we had users complaining
[00:15:27] that they don’t like some particular feature.
[00:15:31] Maybe they don’t like the feature that we just pushed.
[00:15:35] Now sometimes that could result in negative feedback,
[00:15:40] messages,
[00:15:42] and those negative messages may be towards the decision
[00:15:46] to write that code in that particular way,
[00:15:49] or perhaps we gather around and we hold a retro,
[00:15:54] and we try to understand why is it that we made this decision,
[00:15:58] and users don’t like it.
[00:16:01] The truth is that often we connect an outcome to a decision.
[00:16:08] We connect a result,
[00:16:10] to an intention.
[00:16:13] And our decision making process
[00:16:16] should be disconnected
[00:16:19] and not judged based on the outcome,
[00:16:22] but instead judged on the quality of the decision
[00:16:27] with respect to the available information.
[00:16:30] So how does this work out?
[00:16:32] Well, essentially if you’re looking to judge a decision
[00:16:37] that you’ve made in code,
[00:16:40] you can’t go with the age-old mantra of
[00:16:43] the proof is in the pudding,
[00:16:45] or look at the result of that code kind of retrospectively
[00:16:51] and judge whether it was a good decision based on the outcomes.
[00:16:56] You can learn from those outcomes,
[00:16:58] but often outcomes are not necessarily the direct result
[00:17:03] of whatever that communication was.
[00:17:06] And so we get noisy feedback, right?
[00:17:09] We get a lot of kind of randomness
[00:17:13] that gets added into our feedback systems
[00:17:16] because we are not necessarily controlling,
[00:17:19] a lot of the time,
[00:17:20] controlling how we are measuring those decisions.
[00:17:24] So it’s important to understand that there’s probably,
[00:17:28] first of all, probably more noise
[00:17:31] than you originally expected.
[00:17:34] Secondly, it’s important to actively attempt to reduce,
[00:17:39] the noisy feedback.
[00:17:41] Identify the likelihood for that noisy feedback
[00:17:45] and especially identify places where noise is likely to show up.
[00:17:51] You do this as a team,
[00:17:53] do it regularly and do it systematically.
[00:17:56] There are plenty of places where noise will show up.
[00:17:59] For example, your biases as a human.
[00:18:02] The bias that you have will introduce noise into the system.
[00:18:07] External voices.
[00:18:09] Or perhaps market voices.
[00:18:12] Things that are not necessarily directly related
[00:18:15] to whatever the thing is that you are doing.
[00:18:18] Noise has a lot of sources.
[00:18:21] And unfortunately, noise and feedback are often confused.
[00:18:26] I encourage you to explore this model of communication.
[00:18:31] Explore more about what it means to be the messenger.
[00:18:35] And especially for developers who are listening to this show,
[00:18:38] I encourage you to do everything you can
[00:18:41] to understand your audience more thoroughly.
[00:18:45] If you understand your audience more thoroughly,
[00:18:48] then the message you create,
[00:18:50] the medium you use,
[00:18:52] even the feedback and the noise that you experience,
[00:18:57] all of it will be put into perspective.
[00:19:01] And your entire intention as a developer
[00:19:05] will be to create that message
[00:19:07] for that audience.
[00:19:10] Thank you so much for listening to today’s episode of Developer Tea.
[00:19:14] Thank you again to Sentry for sponsoring today’s episode.
[00:19:17] To get started with Sentry,
[00:19:19] head over to sentry.io today.
[00:19:22] Thank you so much for listening to this series
[00:19:25] on the construction of software.
[00:19:28] It’s uncertain whether we will continue episodes on this.
[00:19:31] We’re going to pause on this series for now.
[00:19:34] And this perhaps will be the end of the series.
[00:19:37] If you would like to hear more episodes on this topic,
[00:19:40] then you can reach out to me at developertea at gmail.com.
[00:19:43] You can also find me on Twitter at developertea.
[00:19:47] If you haven’t yet subscribed to the Tea Break Challenge,
[00:19:50] I encourage you to head over to teabreakchallenge.com
[00:19:53] and subscribe today.
[00:19:55] This is a daily challenge that gets sent to your inbox.
[00:19:58] And by the way,
[00:19:59] one of the coolest experiences that I’ve had in the history of the show,
[00:20:03] the developer Mark Provan,
[00:20:05] Mark,
[00:20:06] is a developer at the BBC.
[00:20:09] He created an Alexa skill for the Tea Break Challenge.
[00:20:13] You can go and install developer tea as a skill
[00:20:17] for your Alexa devices.
[00:20:19] And then you can ask Alexa to ask developer tea
[00:20:23] to play today’s Tea Break Challenge.
[00:20:26] So go and check that out.
[00:20:27] If you don’t want to subscribe for some reason,
[00:20:30] you can get that over voice as well.
[00:20:33] Go and check it out.
[00:20:35] I really encourage you to subscribe so you get these in your inbox.
[00:20:39] It’s a very easy way to start your day out with this kind of reconfiguring
[00:20:46] and thinking about these soft skills.
[00:20:48] It’s a very simple challenge should take you less than five minutes.
[00:20:51] Thank you so much for listening to today’s episode of Developer Tea.
[00:20:55] If you’re enjoying these episodes,
[00:20:57] then I encourage you to subscribe in whatever podcasting app you use.
[00:21:01] The Tea Break Challenge,
[00:21:02] Developer Tea,
[00:21:03] all of these things are free to use.
[00:21:04] All of these things are free to you as a developer.
[00:21:07] And if they provide any value at all,
[00:21:09] then the cost of subscription is so very low for you.
[00:21:13] I encourage you to subscribe so you can continue to improve as a developer.
[00:21:17] Thank you so much for listening.
[00:21:19] And until next time,
[00:21:20] enjoy your tea.