Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
In this Discussion
Week 4: Introducing Aesthetic Programming - discussion starter
+++++
We are a team of 5 people who are working on a translation of the book “Aesthetic Programming: A Handbook of Software Studies” into Chinese. Winnie Soon (HK/DK) and @geoffcox (UK) are the co-authors of the book in English (published late 2020). Based in Taiwan, Tzu Tung Lee is the artist facilitator, Ren Yu and Shih-yu Hsu are the lead translators. See: http://aesthetic-programming.net/ and https://hackmd.io/@aesthetic-programming/book (Feel free to join us)
+++++
In late 2020, Winnie Soon and Geoff Cox published the open access book “Aesthetic Programming: A Handbook of Software Studies”. Together with a Taiwanese working group, we are also involving the local community to translate it into Traditional Chinese language (see here for the discussion thread on the politics of translation as part of CCSWG22).
In summary, the book addresses the cultural and aesthetic dimensions of programming from its insides, as a means to think and act critically, offering an applied and overtly practice-based approach to understanding the importance of programming. Our intention is for readers to also become writers in the sense that they acquire key programming skills in order to read, write and think with, and through, code. We feel that it is important to further explore the intersections of technical and conceptual aspects of code in order to reflect deeply on the pervasiveness of computational culture and its social and political effects — from the language of human-machine languages to abstraction of objects, datafication and recent developments in automated machine intelligence, for example. Moving beyond a STEM focus, the book develops discussion of power relations that are still relatively under-acknowledged in technical subjects, concerning class and capitalism, gender and sexuality, as well as race and the legacies of colonialism - issues that are already familiar to the critical code studies community of course. This not only relates to the politics of representation but also nonrepresentation: how power differentials are implicit in code in terms of binary logic, hierarchies, naming of the attributes, and how particular worldviews are reinforced and perpetuated through computation.
Details of the book
The book contains 10 chapters + 1 bonus machine generated chapter, containing both the technical and basic principles of learning to program with sample code explanation, as well as wider political, cultural and social issues (also see : http://aesthetic-programming.net/). Each chapter starts with a flowchart that serves as the starting point to exemplify our approach of turning concepts “inside out” and the need to understand computational and programmable objects, relations, and processes in both logical and discursive forms. The current topics of the 10 chapters are: Getting started, Variable Geometry, Infinite Loops, Data Capture, Auto-generator, Object Abstraction, Vocable Code, Que(e)ry Data, Algorithmic Procedures, Machine Unlearning. They are the topics that are currently used in the delivery of the BA course/module “Aesthetic Programming” at Aarhus University, in Denmark.
Forking: An Open Invitation
Importantly, we do not see this book as a fixed and universal teaching resource, but rather a situated curriculum with the potential for extension and customization with other arts and coding communities. Following the free and open source ethos, we want to open up different possibilities for making “cuts” across the various materials and ideas, and encourage readers to fork a copy and produce their own versions; with different references, examples, reflections and new chapters for example, for further modification and re-use (see the respository: https://gitlab.com/aesthetic-programming/book). Responding to the invitation, in 2021, @SarahCiston and @markcmarino forked the book and created the chapter 8.5 entitled “Talking Back,” which sits between Chapter 8 (Que(e)ry Data) and Chapter 9 (Algorithmic Procedures), extending our discussion of APIs and conversational agents. They have also added two new perspectives and structural changes: Code Confession and Code Commentaries, considering the affective relationship and further insights regarding coding. With this open invitation, we want to stress that Aesthetic Programming is not only a book, but it is also a computational networked object, distributed across other spaces and temporalities, made available to both readers and writers alike.
To begin the thread, we invite you to join us to explore the following questions:
What pedagogical approaches are useful to teach/learn how-to-code, but also to work with (read and write) code through critical and creative action? What are the challenges in practice (“the real-life cases”) of working across engineering and culturalist traditions? And how to cultivate “problem-posing” rather than “problem-solving” through learning to program?
Beyond the solutionist approach of emphasising state-of-the-art technology, big tech normalisation, as well as the ideology of standardisation, efficiency and optimisation that fit into capitalist economy, how might combinations of free and open source ethics, and intersectional feminist/queer politics open up ways of learning to code otherwise?
What other themes and topics are useful to explore in Aesthetic Programming? And what are the implications of forking a book like forking software? How to involve and include local contributors and situated real life cases?
Comments
First off, I must say that I believe @siusoon and @geoffcox have written one of the best books to teach critical code studies, especially through creative and critical programming. This book continually moves through the realms of the cultural and the technical.
Second, as @SarahCiston and I have written, by allowing -- no, encouraging their book to be forked, they have moved the Gutenberg book to the next level of discourse object. George Landow wrote in Hypertext about the way linked pages were going to blow the covers off the book, framing it more as the Text than the Work in Barthes' terms ("From Work to Text"), the work being the fragment and the text being the ongoing evolving stream of discourse without beginning or end. Winnie and Geoff have made the book something extensible, something more like software. To be able to add a chapter to the book felt like we were sneaking new pages into a book in the library, but that just shows the lingering legacy of book covers from the Gutenberg parenthesis. I look forward to other scholars following their lead, writing open source, extensible works, if you will. Their book as open source software then itself performs "combinations of free and open source ethics, and intersectional feminist/queer politics open up ways of learning to code otherwise."
I look forward to seeing how it is extended and transformed next, for it invites participation beyond citation, beyond response, beyond excerpting, and beyond the remix, into a making new.
In response to questions 1 and 2, I'd like to put forward a suggestion that we should include some imagined execution contexts in mind when we do, teach, and imagine programming. Namely I suggest that we consider extending the "I am making this program" with the step "I am making this program for you". What the move is, is that we'd consider pushing the programmers attention from the software to the recipient interacting with the code.
While struggling to build some code, it's easy (and useful!) to lose sight of when and where its run. If the sight is not re-gained, and it very seldom is in programming education, we'll end up teaching programming as if "anyone could run the program" once we've managed to cobble it together. As if we didn't care.
I am variously calling this "I'm programming for you" attitude either intimate programming or more relevantly here Subject, Predicate, Object Oriented Programming (SPOOP). Of course the whole idea is under the influence of form-follows-function tradition design, relationist ontology, Marxist critique, material culture stuff, intersubjectionality, care-talk in STS and blah blah; but also it's fun and very engaging! I don't spend huge amount of time programming (sadface) but some of the most interesting coding I've ever done was when I was programming for very, very specific people in mind; I've made some birthday presents programs, a few graduation presents, a mini-game or two for a romantic partner, and also at work some programs which are intended for very specific individual research colleagues to run. The very title of Cornelia Sollfrank's and Winnie's book Fix my Code captures something of this same idea by naming those relations. This engagements might be small, but they take place in-the-middle-of-things, might be repair or maintenance oriented, and attend to something else than constructing castles or to "sharing content".
I actually hypothesize that this is a very typical, I'd say even normal way programming takes place, beyond "software factories" which are the normal model which is implicitly assumed to be what programming is about; making code for "anybody", rather than for somebodies. Let's consider "I am programming this for you" (SPOOP) when we do creative, æsthetic, critical or post-critical programming! That's my response to 1 and 2
I love how this book is accessible to novice programmers while challenging some of the most fundamental rules of code style -- mainly the pretense that a "neutral" code style is possible.
Nearly all of us who learn to code are taught "good coding" as first formulated by mathematicians like Dijkstra and Knuth. Knuth's concept of elegance is rooted in mathematical Platonism. Dijkstra's "Humble Programmer" told us to write in a neutral, objective voice. The argument was against code that was overly clever -- to favor readability over efficiency -- but secondarily, almost without thought, he also dismisses all personal style in the text of code. We can write a program that makes a cultural statement, but the code behind that program is not the place for such a statement.
Codework of course breaks from this entirely, with the naming of variables determined not only explicitly in a cultural context, but also by how they sound read aloud.
Vocable Code makes great use of that. Not only is the code "queered," but the exercise has us saying what "queer is", and just as we command the machine, we establish (a) truth through the social medium -- connecting the magic of commanding the machine to Speech Act Theory.
In addition to that ideology, there is a consumptive mode of capitalism at work in coding style. When Microsoft releases a new version of their C# language, code written the old way immediately begins to look unkempt. Well-maintained code is current: this is how we can know it is looked after. If you use outside libraries, outdated ones are a security concern; updating means changing your code to accommodate the way they currently work. Meanwhile, the language itself changes to fit larger trends (one day dependency injection is in and setting up a new web project is all about that). This points to the ephemerality and arbitrariness of "good" code style.
@Mace.Ojala You have made a really good point regarding what you have called 'intimate programming' to account for subjectivities and personal relations. I actually think of the generative “love-letters” that appeared on the Manchester University Computer Department’s noticeboard in 1953 (something we have discussed in the book chapter Auto-Generator). These computer-generated declarations of love were produced by a program written by Christopher Strachey using the built-in random generator function of the M. U. C.(Manchester University Computer, the Ferranti Mark I). The book also points to the approach 'care in action' - the syllabus Digital Love Languages at the School for Poetic Computation, where the instructor Melanie Hoff explores how code can be cultivated as a “love language” that is more gentle, healing, and intimate than corporate systems of surveillance and exploitation.
In terms of teaching programming, I always ask my students: what's their motivation to learn programming? Why do they need to program beyond it is a mandatory course in their program? What kinds of things that matter them in which they would like to voice/express?
Thank you, @siusoon for the the discussion starter! I'd like to second @markcmarino and @SarahCiston's position on the huge impact the book project has. Making the book not only widely accessible but also extensible using Gitlab is a great way of opening the discourse. This way the source code literally becomes a resource not only for learners but also for scholars and fellow researcher willing to contribute or directly build upon your work. Therefore I'd like to understand the book as technic (technique and technology at the same) that exceeds not only the borders of linear written text, but also enables others to engage punctually with the topics provided and problems outlined - which is amazing!
I'd like to respond to the first question that asks for useful pedagogical approaches to teach/learn how-to-code and on the healthy relationship of creative and critical action. An important asset is, that the book seeks to go beyond a STEM focus by developing discussions of power relations that are still relatively under-acknowledged in technical subjects. Therefore, I understand the book as a great resource for interdisciplinary classrooms. Interdisciplinarity is important and it can be highly beneficial for all participants, but there are also some pitfalls and learnings.
Together with students of Media Education, Computer Science and Computational Visualistics, we're constantly working in an highly interdisciplinary context that goes with different prior knowledge and skill levels. While I think such a setting is great, it goes with some challenges in creating a common ground and it holds the risk of discussing terms and concepts only to a limited extend. So, it takes some time to set the framing and it requires an openness towards different discourses or study cultures (the study programs mentioned reach across departments). Since Aesthetic Programming offers inputs for discussions in class, it enables scholars to work along the chapters considering the heterogenous backgrounds of the students.
We have offered courses on creative coding, educational data science, hacker cultures and critical data studies in the past, where recently discussed specific chapters of the book such as machine unlearning. I specifically speak of a 'we', since in preparation we came to the conclusion that these courses most often benefit from multiple perspectives, so in order to stimulate rich discussions, it might be a good way to bring in multiple perspectives. Therefore the creative coding classes have been designed and conducted in a team of two scholars.
In these courses, we have had good experiences with an inquiry based learning approach and supplemented team-building activities in the beginning of the course. Activities that tangle the topic of the course but in a very abstract way, such as ways to make numbers count with easily understandable examples and metaphors. We achieved this by re-formulating numbers and other data and bound it to specific topics in present discussions (that took place in present, via online calls and asynchronous chats using Mattermost). Opening multiple ways of communication allowed us to get in touch with the topic and different data sets provided. We could also easily share code snippets and discuss ideas. Communication is key in these settings and I think raising awareness on the social and cultural implications of coding is at least in the courses outlined here most important. Of course, coding itself is a crucial fact, since it enables the students to make sense of coding by articulating their positions not only in discussions but rather in coded expressions. However, as @Temkin also emphasises, programming languages are changing, paradigms might remain longer and ideologies might persist. Therefore reflecting on the power of clean code guidelines or rules and their implications for collaboration and teamwork is also an important step going beyond STEM.
I'd be highly interested in the ways how others design their classes especially on creative coding and critically reading code (in higher education).
@Temkin I really like the way you highlight "consumptive mode of capitalism". In the context of computational culture, I have been always interested to think about what it means by constant/endless upgrade/update beyond fixing security issues and features enhancement. I like your line:
Thank you for your thoughts.
Thank you for sharing @danvers on your interdisciplinary and pedagogical approaches. I never experienced a full course with students from such a diverse educational background. It seems that the course you mentioned is a master course? Do they work on a project in groups every week? Or are there any specific skill levels that they need to reach individually? It is super interesting to see how courses are positioned, and what sort of 'outcome' students need to have. During the past years as a teacher and researcher, I have been challenged by others in terms of how deep (or thorough) would be the technical skills that students could learn in this environment, as it seems that the discussion/conceptual thinking would have taken away the concentration on code as a technical medium. Besides, I also found the scope of various syllabi is interesting. In the context of humanities, some include both front and backend programming in one intro to programming course, some others, especially in the realm of creative coding in art and design, would have a different scope and themes. As such, I am really interested in seeing how other people deal with various challenges and topics. For me, I put in a few pause/catch up weeks to slow things down so that people can have time to think about ideas to work with and to reflect on computational culture.
I agree so much with what you have mentioned: the course would "most often benefit from multiple perspectives", I am so happy to see or hear different ways of teaching programming beyond STEM in practice and real-life cases, especially with the focus on humanistic values and unfold the implications of code in a wider cultural and societal context.