Vox

Leitura de 24 min

How We Construct Software, Part 4a: Code and Communication

Summary

This episode continues the series on how we construct software, shifting focus from individual perspectives to the role of code as a communication tool. The host emphasizes that coding is only a small part of a developer’s job, and that understanding software construction requires examining the human behaviors and collaborative efforts involved.

The core argument is that code is fundamentally a communication tool before anything else. It exists to manage and modify a stream of events or information, but its primary function within a team is to convey intent and behavior. The discussion highlights the multiple layers of communication that happen around code: meta-communication about coding practices (languages, paradigms, best practices), communication about the objectives the code should achieve, and communication about the broader effects and emotions triggered by the code’s impact on people.

The episode introduces a basic, six-part model of communication theory: messenger, message, medium, audience, feedback, and noise. The host begins analyzing this model by focusing on the ‘messenger’—the developer writing code. The messenger’s personal experience, context, motivations, and emotions heavily influence how they craft code. The goal is often persuasive, aiming to convince the team or regain trust, making coding a highly personal and human experience.

The analysis then turns to the ‘audience’—the multifunctional team that reviews and uses the code. The audience interprets the message (the code) through their own motivations and roles (developer, product owner, stakeholder). Psychological factors come into play, such as reviewers being harsher on others’ code than their own, or being swayed by the messenger’s perceived authority. The episode concludes by noting that code is a multifaceted medium that must both communicate clearly to the audience and correctly modify the intended stream of events, setting the stage for further discussion of the communication model.

Recommendations

Services

  • Linode — A cloud hosting provider that allows you to deploy and manage SSD servers. The episode mentions a $20 credit for new users and highlights features like native SSD storage, a 40-gigabit internal network, and new data centers.

Topic Timeline

  • 00:00:00 — Introduction to the series on code construction — The host introduces part four of a series focused on the human behaviors and collaborative efforts in software construction, rather than specific tools or languages. He clarifies that the discussion is about the complexity of building software with other people, moving beyond individual perspectives to examine what we are actually doing when we write code.
  • 00:01:44 — Code as a communication tool — The host argues that code is a communication tool before anything else. He uses the analogy of sound and letters, stating that good code is highly contextual because its primary job is to communicate intent. This shifts the perspective from seeing code merely as moving bits to understanding it as a medium for conveying meaning within a team.
  • 00:02:56 — Coding is only part of the job — A reminder that writing code is only a small portion of a software developer’s job. To understand its role, we need a better picture of communication from the ground up. The episode will lay the foundation for a two-part discussion on the communication model surrounding code.
  • 00:03:55 — Software’s purpose: managing a stream of events — The host explains that all software exists to run and process a stream of events or information. Code is responsible for managing, changing, magnifying, or creating new streams. This concept applies broadly, from event-driven systems to one-off scripts. The code itself is a communication tool that represents what happens to that stream.
  • 00:05:44 — Layers of team communication about code — Teams communicate on multiple levels: 1) Meta-communication about coding itself (best practices, languages, paradigms). 2) Communication about the objectives—what we want to accomplish with the stream of information. 3) Communication about the effects of those decisions, including the emotional impact on team members, customers, and ourselves. All these discussions should ultimately point toward changing the code to reflect the agreed-upon goals.
  • 00:12:26 — Introducing the basic model of communication — The host presents a mashup of common communication theory models. The basic model consists of six elements: a messenger, a message, a medium, an audience, feedback, and noise. The episode will examine each of these components in relation to code, starting with the messenger.
  • 00:13:30 — The messenger: the developer writing code — The messenger is the developer crafting code for a multifunctional team. This developer is the protagonist, responsible for crafting a message (through code) intended to modify a stream of events. The messenger’s personal experience, context, and motivations heavily influence how they choose to communicate. Writing code is not a pure transaction but a highly personal, human experience often with persuasive goals.
  • 00:18:33 — The audience: the multifunctional team — The audience is the team that must understand, review, and use the code. They interpret the message through their own motivations and roles (developer, product owner, stakeholder). Psychological factors affect this: reviewers are often harsher on others’ code than their own, and authority figures can sway perceptions. The audience’s role is to see the message clearly and decide if it’s acceptable.
  • 00:21:54 — Code as a multifaceted medium — Code is a unique medium because it must serve two objectives simultaneously: it must communicate clearly to the human audience, and it must correctly modify the intended stream of events or data. Even the most eloquent code fails if its core message (the intended behavior) is wrong. Understanding the messenger and audience is half the battle; the remaining elements of the communication model will be discussed next.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2019-02-15T14:15:00Z
  • Duration: 00:23:19

References

Podcast Info

Transcript

[00:00:00] this is part four in a series of episodes on developer t about code construction we’re

[00:00:09] discussing not the specific methods of constructing code we’re not talking about

[00:00:17] what editors to use or what language to use or even what paradigm to use certainly all of those

[00:00:26] things matter and they’re related to the things that we’re talking about on this series but

[00:00:32] we’re discussing more about the human behaviors and the collaborative efforts that we put forth

[00:00:42] when constructing software with other people my name is jonathan cuttrell and you’re listening

[00:00:47] to developer t in the past couple of episodes we’ve discussed the complexity that is the

[00:00:55] construction of software and the complexity of the construction of software and the complexity

[00:00:56] and we haven’t really approached the discussion of software itself very much mostly what we’ve

[00:01:04] focused on is the individual perspectives that may shift the way that we see software the way that we

[00:01:14] visualize it as individuals and then put forth whatever that is into a code form but what exactly

[00:01:26] are we doing when we write code is it as simple as moving bits around certainly if you’re listening

[00:01:36] to this podcast then you probably don’t believe that that’s the case code takes on a lot of

[00:01:44] meaning it takes on a lot of different forms the job of code is kind of like asking what is the job

[00:01:54] of sound

[00:01:56] what is the job of letters how do we put sounds together in the right way that’s kind of similar

[00:02:08] to asking how do we code well good code is highly contextual and that’s because code is a

[00:02:16] communication tool before anything else and if you’re writing a note a quick note one that

[00:02:24] is disposable and you’re writing a note that’s kind of similar to writing a note that’s kind of

[00:02:26] then getting that note reviewed by an english professor seems like a silly idea and anyone

[00:02:33] looking at it trying to scrutinize the plot of your grocery list they’re probably misguided

[00:02:41] so how can we think differently about the role of code in our jobs as software developers

[00:02:53] coding is only part

[00:02:56] of our job and hopefully that’s not a revelation it wasn’t intended to be a revelation just a

[00:03:02] reminder that code is only a small portion of our job which is really why this podcast exists in the

[00:03:09] first place to discuss everything else but we need to understand the role of code and to do that

[00:03:18] we need to understand a better picture of communication from the ground up we’re going

[00:03:25] to talk about the communication of code and we’re going to talk about the communication of code and

[00:03:26] we’re going to talk about the communication model in today’s episode but just to kind of lay the

[00:03:31] the foundation for this and this is going to be two parts in this series we’re going to talk about

[00:03:37] the communication model over the course of two episodes because there’s a lot to discuss here

[00:03:41] but i want to talk about for a moment what we’re doing when we write code and how much

[00:03:47] communication is actually happening so if you take a step back and you think about what software does

[00:03:55] if you take a step back and you think about what software does if you think about what software does

[00:03:56] think about whatever app that you’ve created in the past whatever thing that you’re working on

[00:04:01] today and whatever you will work on in the future all of these things exist to run and when they’re

[00:04:09] running they’re processing some kind of stream of events or information this stream could be

[00:04:17] instructions for example coming from other computers or it could be individuals who

[00:04:22] trigger different types of requests to your application

[00:04:26] through another machine the code you and your team create is responsible for managing that stream

[00:04:33] of events and doing something with it changing that stream in some way or maybe magnifying parts

[00:04:40] of that stream or even creating new streams and the code itself is a communication tool

[00:04:48] that represents what happens to that stream now this isn’t to be confused with streaming

[00:04:56] data that’s a more technical term we’re more talking about the concept of a stream of events

[00:05:03] you can apply this same concept even to one-off scripts the stream of events that is happening to

[00:05:11] the one-off script is that you’re actually running that script perhaps the stream of events

[00:05:16] is that the script is going out and getting information and then doing something with that

[00:05:21] information so i want to make sure that you don’t get hung up on this concept and that you’re not

[00:05:26] going to get hung up on the concept of of a stream or of event-driven programming or something like

[00:05:30] that that’s unrelated to what we’re talking about in today’s episode so in order to accomplish this

[00:05:36] kind of thing we as teams we communicate about first of all the code itself and not the code

[00:05:44] that we’re writing but the coding the practice of writing code this is kind of a meta communication

[00:05:51] where we discuss different dialects or flavors ways that we can communicate

[00:05:56] better through code best practices now it should be noted that this discussion about code

[00:06:02] that we’re having on the show kind of compresses out the possibility that you know one language

[00:06:10] performs significantly better for your problem set than another language so we’re assuming that

[00:06:17] your performance problems are not at stake in this discussion this is often not the case and

[00:06:24] i don’t want to say that we’re not at stake in this discussion but we’re assuming that we’re

[00:06:26] going to minimize these best practices discussions because they are very important but this is

[00:06:33] something that we communicate about and sometimes we have arbitrary differences between various

[00:06:40] languages various opinions about you know how to perform a particular task you know what kind of

[00:06:46] naming structure do we want to use and for the things that we’re trying to accomplish usually

[00:06:52] as teams those discussions are much more weighted

[00:06:56] towards opinions than they are towards some restriction that you can’t bypass so we communicate

[00:07:04] about coding the coding itself what languages should we use what kind of paradigm are we

[00:07:11] interested in you know what fits our problem the best and some of that is how do we understand

[00:07:16] our problem so that we can map that problem best to the code so we communicate a lot about

[00:07:26] coding we also communicate about the things we are trying to accomplish with that stream of

[00:07:31] information so this is kind of a parallel discussion that we we discuss you know what is it

[00:07:37] that we’re trying to do with that information that’s coming into the to whatever our application

[00:07:43] is and so this isn’t a direct discussion about what the code should do what this generates is

[00:07:49] some kind of you know objective criteria that we’re trying to meet and then we take that criteria

[00:07:55] and we figure out what the code should do and then we take that criteria and we figure out what the

[00:07:56] code should do and then we figure out what the code should do and then we feed it into the exercise

[00:07:58] of communicating through code so we communicate about the things that we want to try to do but we

[00:08:05] also communicate about the effects of those decisions the people who are affected we

[00:08:12] communicate about the emotions these are third and fourth and you know tenth order effects of

[00:08:19] writing code when we write code the first order effect is that bits are moving and we’re

[00:08:26] you create a positive or negative charge and that’s not necessarily as meaningful to us

[00:08:34] until we recognize what the culmination of all those bits changing does to another person

[00:08:43] so it’s critical that we talk about these kinds of things in addition to discussing you know what

[00:08:51] should our code look like we should be discussing what does our code do and how does it work and

[00:08:56] how does it affect other people and other people in this case could be other people on your team

[00:09:01] it could be your customers it could be the people that are you know around your customers your

[00:09:08] customers friends and family or maybe even your customers customers and let’s not forget ourselves

[00:09:16] how does this code affect us how do we feel about this code and fast forward into the future

[00:09:24] if we’re working with this code how do we feel about this code and how do we feel about this code

[00:09:26] then how does it affect us then all of these discussions are pointed at actually changing

[00:09:35] code we will change something in the code to affect something that we discussed outside of the

[00:09:44] code this is a very important concept to grasp because a lot of our discussions may be well

[00:09:51] meaning but if they don’t result in some kind of direct change then we’re not going to be able to

[00:09:56] change to whatever it is that we’re responsible for in in most cases for developers that is the

[00:10:03] product that is the code that you are writing then those discussions don’t have much of an effect

[00:10:09] on the work that we do we’re going to take a quick sponsor break and then we’re going to come

[00:10:15] back and talk about a basic model a theory of communication we’ll discuss that model of

[00:10:24] communication right after we talk about it and then we’ll come back and talk about it and then

[00:10:26] talk about today’s sponsor

[00:10:27] today’s episode is sponsored by linode with linode you can instantly deploy and manage an ssd server

[00:10:40] in the linode cloud you can get a server running in just a few seconds with your choice of linux

[00:10:45] distribution resources and the location of the node with 20 worth of credit that’s free money

[00:10:54] basically

[00:10:56] you can get started on linode on for example their one gigabyte of ram plan that starts at five

[00:11:02] dollars a month and under that twenty dollars worth of credit you essentially get four months

[00:11:06] for free on this plan with that plan you could for example boot up your own virtual machine

[00:11:12] on top of this native ssd storage by the way and a 40 gigabit internal network so if you wanted to

[00:11:20] spin up another node and then communicate between those two nodes you could do that very easily

[00:11:26] and with high performance it’s all on top of intel e5 processors and linode is continuously

[00:11:32] improving for example there’s new data centers opening in india and canada before 2020 and

[00:11:39] there’s block storage now available in newark fremont dallas atlanta frankfurt london and

[00:11:45] singapore soon to be released in tokyo linode is a company of developers for developers and

[00:11:53] they happen to be hiring head over to linode.com

[00:11:56] slash careers to learn more about that and if you want that twenty dollars worth of credit go and

[00:12:02] sign up for linode head over to linode.com slash developer t and use the code developer t 2019

[00:12:08] that’s developer t 2019 at checkout thanks again to linode for sponsoring today’s episode of

[00:12:15] developer t

[00:12:16] so let’s discuss the

[00:12:26] basic model of communication now this is a little bit of a mashup of multiple models

[00:12:32] of communication but this is essentially what most people agree on as the primary

[00:12:39] the primary kind of building blocks for for a communication theory so the most common model

[00:12:47] of communication theory goes something like this you have a messenger and that messenger sends

[00:12:54] a message

[00:12:56] across a particular medium that is intended for an audience that audience provides feedback

[00:13:03] along the way that message may be interrupted or otherwise garbled by some kind of noise

[00:13:12] and we’re going to look at each one of these things that’s messenger message medium audience

[00:13:19] and uh feedback as well as noise we’re going to look at all six of these in today’s and the next

[00:13:25] episode of developer t and we’re going to start with the messenger

[00:13:30] we’re going to use the concept of a single developer writing code with a multifunctional

[00:13:38] team that includes other developers maybe a product owner a designer maybe a stakeholder

[00:13:45] that developer is writing this code to accomplish some kind of specified behavior remember that

[00:13:52] stream we discussed earlier that developer is trying to write a code that is specific to a

[00:13:55] team and that team is trying to modify that stream of events the team will review the code and

[00:14:01] subsequently the team has to rely on that code and work with it they have to use whatever that

[00:14:08] code provided to them or maybe they have to change it but ultimately once it gets accepted that code

[00:14:15] becomes a part of that product what that team’s working on so the messenger in this case is kind

[00:14:24] of our hero he’s our protagonist and we’re going to look at that code and we’re going to look at

[00:14:25] that code and we’re going to look at that code and we’re going to look at that code and we’re going to

[00:14:25] it’s you the coder and you’re responsible for for crafting a message now code is kind of the

[00:14:34] primary medium that you’re going to use and we’ll talk about the medium in just a little bit but

[00:14:39] code has the intent to modify that stream of events of information in some specific way

[00:14:45] and as we’ve discussed in previous episodes in this series the way a given messenger chooses

[00:14:52] to communicate could be vastly different

[00:14:55] from another messenger this is how you and another developer on your team approach problems with

[00:15:02] totally different ways of solving them even well-scoped minor problems can be solved very

[00:15:10] differently depending on the developer and you may solve a problem differently from one day to

[00:15:17] the next now it’s important to note and perhaps most important to note that you have a lot

[00:15:24] of personal experience and motivations you have a lot of context and when you’re writing that code

[00:15:34] it’s very difficult perhaps not even worth it to try to shed that context often that context is

[00:15:42] actually helpful the messenger’s experience and personal opinions will heavily influence the way

[00:15:49] they choose to communicate in code now this is not a pure transaction

[00:15:54] you’re not just moving bits exactly the way that they should be moved because should is a really

[00:16:02] difficult thing to understand instead it’s a highly personal and human experience to write code

[00:16:10] it’s very important to understand that you have different motivations based on whatever your role

[00:16:16] is on this team and really whatever your role is in general when you craft a message often there’s

[00:16:24] a persuasive element you’re trying to convince the team there is some goal to sending the message

[00:16:33] otherwise you wouldn’t send the message at all maybe the goal is to convince your team that

[00:16:40] you are doing a good job it could be as simple as that or maybe you have a very highly motivated

[00:16:49] stake in whatever it is that you’re building and this is probably a better scenario for you

[00:16:54] a more satisfying scenario for you but often our motivations are not simple they’re not easily

[00:17:02] summed up perhaps for example the last bit of code that you pushed had a bug in it and so maybe some

[00:17:10] of your motivation on this new push is to gain back the trust of your teammates you’ll notice

[00:17:18] very quickly that when you start talking about motivation you can trace a lot of the decisions

[00:17:24] that you’ve made in your life and you can trace a lot of the decisions that you’ve made in your

[00:17:24] back to some kind of emotion or a human need these feelings can’t be discounted they absolutely

[00:17:34] affect the way that you communicate now it should be noted also that code is not your only method

[00:17:42] of communication we talk about our code we write documentation around our code we discuss what the

[00:17:52] code should be in meetings in meetings in meetings in meetings in meetings in meetings in meetings

[00:17:54] and even non-verbal communication like managing our code in a particular way or

[00:18:01] you know doing a midnight push all of these actions all of this behavior is a part of your

[00:18:10] communication as the messenger so it’s important to understand that the messenger’s communication

[00:18:17] is not limited and it’s not directly controllable it is a very human thing

[00:18:24] and on the other end is the other human the audience and in this case many humans typically

[00:18:33] and the multifunctional team works alongside that messenger to both understand their message

[00:18:40] and hopefully to help refine that message through some kind of feedback which we’ll talk about in a

[00:18:46] future episode but here again we run into an interesting situation not only do we craft

[00:18:52] messages and code with a heavily influenced message but we also have to understand that

[00:18:54] when we read code we read it with a different perspective than we write it

[00:19:10] we judge the messages that others provide differently based on who they are this is

[00:19:17] actually a studied phenomenon people are less likely to agree with their own judgments and

[00:19:24] decisions when they don’t realize that they made those decisions themselves this ultimately means

[00:19:31] that the reviewers will on average be harder on the code than the writer will but there’s some

[00:19:37] caveats to this for example what is the actual role of that person remember we mentioned that

[00:19:43] this is a multifunctional team and so you have different motivations even intentionally so

[00:19:49] the developer’s motivations are naturally going to gravitate towards

[00:19:53] maintainable code and the developer’s motivations are going to gravitate towards

[00:19:54] maintainable code while the product owner’s motivations are naturally going to gravitate

[00:19:59] towards making progress on a product roadmap or something similar to that a stakeholder’s

[00:20:06] motivations may be slightly different perhaps weighted towards the highest economy or most

[00:20:11] lucrative decision that can be made all of these different motivations will change the way that you

[00:20:18] see or hear that message beyond these more obvious roles

[00:20:24] beyond these more obvious roles there’s also a lot of motivation that can be made to make a

[00:20:24] change in the way that you see or hear that message beyond these more obvious roles there’s also some

[00:20:25] caveats to the idea that other people will be harsher on your code than you will for example

[00:20:32] if the reviewer can connect an authority figure to the messenger they may be swayed to review

[00:20:40] that code less harshly they may even trust the authority figure more simply because they have

[00:20:47] some authority even despite their best efforts otherwise authority has a major

[00:20:54] psychological sway over the way that we view the messages of others perhaps an interesting exercise

[00:21:01] would be to review code without knowing who wrote it but our intuition doesn’t always serve us wrong

[00:21:07] it doesn’t only make us do bad things we develop for example trust in others work based not only

[00:21:15] on their title of authority but also on their practiced intuition on their proof we may

[00:21:23] unknowingly for example paint a picture of a person who has a code but we don’t know who it is

[00:21:24] we may not pay more attention to a particular piece of code if we know that that developer is

[00:21:29] new on the project the audience’s role in many ways is to see clearly what the messenger’s message

[00:21:38] is and then to determine in our case whether that message is acceptable should we change the message

[00:21:48] as we mentioned before code is kind of a multi-faceted

[00:21:54] medium it holds both messages that we communicate to each other but it also has an effect on that

[00:22:05] stream of data that stream of events that we mentioned at the beginning of the episode

[00:22:09] so the message crafting is not completely separate from that modification of the stream

[00:22:18] both objectives need to be met the code needs to communicate clearly

[00:22:24] to the audience but it also needs to accomplish that modification of the event stream it needs to

[00:22:32] do whatever it was intended to do even the best written most eloquently communicative code

[00:22:40] if the message is wrong if the the thing that is being communicated is not the thing that needs to

[00:22:49] be communicated then it doesn’t really matter how how eloquent it is in the first place

[00:22:54] understanding the messenger and understanding the audience is really kind of half of the battle

[00:23:04] but there’s more to it than that we need to discuss the message itself we need to understand

[00:23:13] the medium that the message travels across we need to understand the feedback

Visão de gráfico