Understanding the meaning we make of the code we write can help create more nuanced and ethical software
An insight from "Rhetorical Code Studies: Discovering Arguments in and Around Code"
🧠 Idea
Understanding the meaning we, as individuals, teams and organisations make of the code we write and the software we design (i.e. the rhetorical dimensions of all these acts) “can tell us much about how to assume more nuanced and ethical approaches to creating, using, and discussing software in the public, profession, and academic contexts alike”1
Rationale
Instead of a specific empirical finding, this time I am sharing an interesting idea that certain communities are adopting. So, no methodology or results section, instead I describe the rationale behind the idea.
The primary way in which people think about computer code that they are writing, reading or executing is that of an instrumental tool that produces an effect. While that is undeniable, there is more to it.
The mental models that programmers hold in their minds while developing, the hidden assumptions about what a program is supposed to do, the cultural biases of how the world works affect the technology we create in both simple and complex way.
Software that has been composed with as much attention to the rhetorical dimensions of its code as to its intended and anticipated execution and output might well herald valuable innovations for approaching computer use in general and code composition in particular — Brock (2019)
🛬 Practice
My first reaction to the idea of understanding the meaning we make of code was intrigued but also confused. While logical, the idea seemed too abstract to me. Thus, I sought concrete examples that ground the concept in practice.
Clean code
In a way, Clean Code2, the pragmatic cornerstone of programming books, aims to change the meaning that programmers attribute to their code. More specifically, the core idea of the book is that “communication is the professional developer’s first order of business”. Thus, code should be interpreted first as a message from a programmer to its readers about how something should execute and only in the second instance as mere machine instructions.
The functionality that you create today has a good chance of changing in the next release, but the readability of your code will have a profound effect on all the changes that will ever be made — Martin (2009)
Observing coding
Another interesting application is that of observing what we actually do - instead of what we think we do - while programming. For example, Chris Lindgren3 carefully observed a web developer’s coding on a data-journalism team and found that:
he devoted more coding acts to emergent problems (~60%) rather than explicit aims (~35%). This suggests that the bulk of what we develop may not relate directly to our original design but emerge from the problems we solve in the process. Given this, we may want to find ways of circling back these emerging problems and discuss them more widely within our teams;
as he encountered emergent problems, he made decisions about what contextual and historical factors mattered. This suggests that the insights that we develop about the (i) data, (ii) programmatic transformations of it, (iii) the context of the task and (iv) the relationship between the task and prior experiences; may significantly affect what we decide to develop;
Reinterpreting technical tradeoffs
Giving importance to the properties of the interactions between people and code can also help to make more informed technology decisions. This is because it can allow us to take into account not only the mere functional benefits and limitations of certain technologies but also the constraints and enhancements that may emerge as that technology is exposed to humans.
For example, Paul Ford4 argues that this is why we rarely adopt new programming languages despite the potential technical benefits and the many development hours being invested in the field:
Making a new [programming] language is hard. Making a popular language is much harder still and requires the smile of fortune. And changing the way a popular language works appears to be one of the most difficult things humans can do, requiring years of coordination to make the standards align. Languages are large, complex, dynamic expressions of human culture. — Ford (2015)
Driven designs
Speaking of the meaning of technical abstractions, system design has a history of driven designs, that is, particular ways of guiding the design of a system. Some examples are
Object-Oriented Design focuses on clearly identifying and defining the objects that make up a system;
Test-Driven Design, a method to develop safe code by first defining the behaviour that the code must comply to and only after implement the actual logic;
Domain-Driven Design5 argues that successful software matches the business domain of its application, as this ensures conceptual consistency between the real and the digital (and its users);
The latest addition to the family of design criteria is that of Value-Driven Design6, which aims at ensuring that our system reflects what is meaningful to its users. In the words of Joe Edelman, while designing and developing, we need to be able to answer the question
what do I need to know about a person, to assess whether I'm helping or harming them?
To me, Design systems seem opinionated models of enforcing specific meaning onto how we think and develop.
🗣️ Reactions
To give a sense of what different communities think about the ideas I presented here, I will list some hashtags and try to summarise each with a characteristic tweet
#critcode
#techcomm
#writethedocs
#complexity
Note: Complexity Theory is a much larger concept than what discussed here. However, its interdisciplinary mindset and methods are highly relevant.
If you know of any other interesting initiative and idea in this space, please comment below!
Brock, Kevin. Rhetorical code studies: Discovering arguments in and around code. University of Michigan Press, 2019.
Martin, Robert C. Clean code: a handbook of agile software craftsmanship. Pearson Education, 2009.
Lindgren, Chris Aaron. Writing With Data: A Study of Coding on a Data-Journalism Team. Written Communication, 2021.
Ford, Paul. What is code. Bloomberg Businessweek 11, 2015.
Evans, Eric. Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional, 2004.
Edelman, Joe. Values-Based Social Design. A social design textbook, 2021.
Love this!! You may be interested in this blog post I wrote last year -- I spent the first ~half of the piece developing the idea of code as voice(s): https://blog.jse.li/posts/software/ lmk what you think :)