Preface

What kind of book is this?

As indicated by its subtitle, this book is meant to be a handbook of sorts, but not in any conventional sense of it being a prescribed set of technical instructions.¹ It is not meant to be read to simply learn to code nor to offer critical reflection upon the practice of coding alone, instead it offers something more messy and at the same time more “useful” we would say: a book about the more complex and deeply entangled set of relations between writing, coding and thinking.²

Most programming books are written with the primary objective of teaching readers how to learn a programming language to become a good (or better) programmer, with an emphasis on state-of-the-art technology, as well as practical examples that are explained and then designed to be deployed in technology-related or creative industries. Not many programming books address the cultural and aesthetic dimensions of programming as a means to think and act critically.³ Emerging trans-disciplinary fields involving computational technology — such as software studies, platform studies, and digital humanities to an extent — incorporate the practice of programming into the object of study, yet little practical detail is provided in terms of putting programming into a critical perspective, especially for those studying non-technical or non-scientific disciplines. This book attempts to address this gap between available literature and the growing interest in “computational thinking”⁴ to expand programming beyond the confines of computer science or software engineering (or even the digital humanities, which ultimately presents another set of limitations). We consider our approach to be distinctive from other books in this regard, as well as from other theoretical books in which source code becomes an illustration of the programmer’s thinking or a too-easy analogy for the hidden layers of operations (if not ignored altogether).

Whilst operating broadly in the spirit of Software Studies,⁵ the book offers an applied and overtly practice-based approach to understanding the importance of programming — reading, writing and thinking with software — as a critical tool for our times, in recognition of the way in which our experiences are ever more programmed. It is offered as a deep learning “tool” in its widest sense — a handbook for those unaccustomed to programming — that allows for the programmer’s conceptual skills to develop as they become technically more proficient.

To reiterate the point, our intention is for readers to acquire key programming skills in order to read, write and think with, and through, code (and we will return to the issue of literacy later). 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. In other words, the book embraces both the technical aspects and formal qualities of code as well as opens up imaginaries of code, including acknowledgment of the material conditions of programming practice, the non-human agency of code itself, and its inherent relationality within broader ecologies.

Alongside learning to program, we aim to bridge the gap between theories of computational culture, aesthetics and cultural studies. As part of this, we take a particular interest in power relations that are under-acknowledged, such as inequalities and injustices related to class, gender and sexuality, as well as race and the enduring legacies of colonialism.⁶ This is not only related to our own subject-positions and cultural backgrounds (see our biographies for more on this) and a politics of representation (the contested space between the subject and the representation of the subject), but also to how power differentials are implicit in code in terms of binary logic, hierarchies, naming of attributes, accessibility, and how wider societal inequalities are further reinforced and perpetuated through non-representational computation. In short, the handbook introduces and demonstrates a distinctive approach to the reflexive practice of what we call “aesthetic programming” as we explain and perform it, and to how it constitutes us as subjects.

Why aesthetic programming?

The argument the book follows is that computational culture is not just a trendy topic to study to improve problem-solving and analytical skills, or a way to understand more about what is happening with computational processes, but is a means to engage with programming to question existing technological paradigms and further create changes in the technical system. We therefore consider programming to be a dynamic cultural practice and phenomenon, a way of thinking and doing in the world, and a means of understanding some of the complex procedures that underwrite and constitute our lived realities, in order to act upon those realities.

The phrase “aesthetic programming” usefully describes this approach in our opinion. We claim a certain distinctiveness in this, but of course aesthetic programming is close to other phrases such as “creative coding” and “exploratory programming” that have been introduced in related literature in recent years to emphasize the expressivity of computer programming beyond something pragmatic and functional, in which cultural production, or critical thinking using the practice of programming, can be developed from the broad perspective of the arts and humanities.⁷ It should be explained that the title “aesthetic programming” actually derives from one of the undergraduate courses of the Digital Design degree program at Aarhus University in Denmark, which has been taught in parallel to a course in Software Studies since 2013. Taken together, as they were designed, these courses offer ways of thinking with software to understand wider political and aesthetic phenomena.⁸ We follow the principle that the growing importance of software requires a new kind of cultural thinking, and curriculum, that can account for, and with which to understand better, from within, the politics and aesthetics of algorithmic procedures, data processing, and abstracted modeling. The book’s structure largely emerges from the experience of teaching these courses and we owe gratitude to all our students and fellow teachers for their valuable contributions and critical feedback along the way.⁹

Continuing the discussion of aesthetics, it should be clear that we do not refer to ideas of beauty as it is commonly misunderstood (aka bourgeois aesthetics), but to political aesthetics: to what presents itself to sense-making experience and bodily perception (to paraphrase Jacques Rancière’s The Politics of Aesthetics, as one key reference).¹⁰ How we perceive the world in this political sense is not fixed, but is in constant flux, much like software itself and bound to wider conditions, and ecologies.

Political aesthetics refers back to the critical theory of the Frankfurt School, particularly to the ideas of Theodor Adorno and Walter Benjamin, that enforce the concept that cultural production — which would now naturally include programming — must be seen in a social context. Understood in this way programming becomes a kind of “force-field” with which to understand material conditions and social contradictions, just as the interpretation of art once operated “as a kind of code language for processes taking place within society.”¹¹ The much-cited essay by Benjamin on technical reproducibility has become a touchstone for collapsing some myths of artistic production including the dismantling of the aesthetic experience of “aura” (the mark of an artwork’s authenticity and originality).¹² It is also worth remembering that Adorno and Benjamin famously disagreed on the consequences of this destruction of aura: whilst Benjamin expressed the positive aspects of this shift and viewed the destruction of aura as a kind of political emancipation, Adorno expressed the negative view that standardization and pseudo-individuality would follow. It would seem that both tendencies have accelerated with computational culture, hence the continuing need for sharp critique, and one also based along the lines of “immanent criticism,” that which is inherent, as it operates within its object, in the inner workings of software and its material conditions.¹³ Yet it remains in question as to what extent these old (white, male) references are up to the task of unpicking the complexity of computational operations, and address the ways in which most people use computers or think about them. This is as much to do with what aesthetic programming is becoming as to what it is or was, and why we still take our point of departure from such references, also aware that they perpetuate problems in themselves, and require alternatives.

If everything is in flux, as it would seem, then we also need to be sensitive to our received methods, based as they are on Western traditions of knowledge production, and notions of progress, rooted as it is in European colonialism and extraction practices.¹⁴ We find the work on Anna Lowenhaupf Tsing useful in this regard as it offers a feminist perspective in which indeterminacy is taken more seriously to reflect the precarity of lived conditions.¹⁵ Not only are our theories of history and technology bound up with this but also critical practices and other nonhuman imaginaries. Other ecologies open up ways of thinking that are multidirectional, across times and scales, more open-ended and indeterminate, based on ideas of “assemblage,” as Tsing puts it.¹⁶ We don’t look to mushrooms for inspiration as she does, but to the immanent and relational qualities of technology itself. More precisely we have been working with fundamental programming concepts, such as geometry and object abstraction; loops and temporality; data and datafication; variables, functions, and their naming, as well as data capturing, processing and automation, as the starting point for further aesthetic reflection whereby the technical functions set the groundwork for further understanding of how cultural phenomena are constructed and operationalized.

Aesthetic programming in this sense is considered as a practice to build things, and make worlds, but also produce immanent critique drawing upon computer science, art, and cultural theory. From another direction, this comes close to Philip Agre’s notion of “critical technical practice,” with its bringing together of formal technical logic and discursive cultural meaning.¹⁷ In other words, this approach necessitates a practical understanding and knowledge of programming to underpin critical understanding of techno-cultural systems, grounded on levels of expertise in both fields (as in the case of Wendy Hui Kyong Chun or Yuk Hui, for example, who have transdisciplinary expertise¹⁸). Such practical “knowing” also points to the practice of “doing thinking,”¹⁹ embracing a plurality of ways of working with programming to explore the set of relations between writing, coding and thinking to imagine, create and propose “alternatives.”²⁰ By engaging with aesthetic programming in these ways, we aim to further “queer” the intersections of critical and technical practices as in the many examples we refer to in this book (see “List of Projects,” and exemplified by our references to Winnie Soon’s work throughout), and to further discuss power relations that are relatively under-acknowledged in technical subjects. We hope to encourage more and more people to defy the separation of fields and practices in this way.

And software studies?

As stated, we draw heavily upon the field of Software Studies, and to an extent Critical Code Studies — the work of Wendy Chun, Matthew Fuller, Mark Marino, and others, including our own earlier work — to deal with and communicate knowledge of software as a cultural form via analyses of examples of software artefacts and close readings of theoretical texts and source code. In terms of approach we take our inspiration largely from Fuller’s Software Studies: A Lexicon from 2008, structured literally as a lexicon of key terms, it in turn taking its cue from the Raymond Williams’s Keywords: A Vocabulary of Culture and Society first published in 1958.²¹ In many ways, and simply put, our book can be thought of adopting a similar approach of zooming in to the formal logic of computation and zooming out to the cultural implications of software. In this respect it is also important to recognize that the book Software Studies derived from a provisional workshop, and it is worth quoting the project page for its clarity of intention:

“[T]he project aims at folding the internalist/externalist question of science studies inside out, the mechanisms of the one conjugating the subject of the other: what does software-enabled scholarship, in software, art, and literary practice have to say about its own medium? The purpose of this interaction is therefore not to stage some revelation of a supposed hidden truth of software, to unmask its esoteric reality, but to see what it is and what it can be coupled with: a rich seam of paradoxical conjunctions in which the speed and rationality of computation meets with its ostensible outside.”²²

We believe that paying attention to fundamental, or key, concepts from programming provides the opportunity to open up new insights into aesthetics and critical theory, as well as new perspectives on cultural phenomena increasingly bound to computational logic. In this way, although aware that we inhabit the problem, we think it important to work in this way, from the inner workings of software and its material conditions. By extending the discussion beyond formal logic to its outside, we also emphasize the usefulness of artistic practice for opening up more speculative, alternative, and messy imaginaries. In this spirit, and in keeping with the development of software studies in Europe at least, we take inspiration from what has been referred to as “software art” (although admittedly the category was only meant as a placeholder) or “computational art.”²³ That we draw upon examples from artistic (and critical design) practices as part of our argument, stresses our point that programming is not simply a practical tool that produces an artwork, but is a critical-aesthetic object²⁴ in itself. Curator Inke Arns neatly clarifies this:

“‘Software art’ […] refers to artistic activity that enables reflection of software (and software’s cultural significance) within the medium – or material – of software. It does not regard software as a pragmatic aid that disappears behind the product it creates, but focuses on the code it contains – even if the code is not always explicitly revealed or emphasized. Software art, according to Florian Cramer, makes visible the aesthetic and political subtexts of seemingly neutral technical command sequences. Software art can base itself on a number of different levels of software: source code level, abstract algorithm level, or on the level of the product created by a given piece of code.”²⁵

We would argue something similar for this book. Moreover, in order to discuss the aesthetic dimensions of code and computational processes, we incorporate artistic works that explore the material conditions of software and the operations of computational processes as practical and theoretical examples. They are an integral part of our argument in other words, as well as serve to demonstrate some of the ideas in practice and offer unexpected epistemic insights. We might add, repeating what has already been introduced, that we are not simply interested in a critical aesthetics of programming but also programming as critical aesthetics.

Open publishing

More to the point, text is in code (in the ways that it is made human-readable) and code is in text (in the use of the text editor, interfaces and online platforms we use to render these thoughts). There is more to say on this, and we will return to these issues across the various chapters of the book, each following the logic of fundamental programming concepts. Suffice to say for now, that the book sets out to express how writing and coding are deeply entangled, and how neither should be privileged over the other: we learn from their relationality. Writing code and writing about code are forced together in ways that reflect broader cultural and technical shifts in data practices and open publishing initiatives, and, moreover, emphasize that writing a book is necessarily a work in progress. Like software, this is a book to be read, and acted upon, shared and rewritten.

There are clearly many precedents for such an overtly collaborative approach to software production, and clearly, free and open source principles underscore our thinking. It is worth emphasizing that FOSS development is a collective practice that challenges the normative relations of production associated with commercial development, such as a narrow definition of authorship and copyright, and fixed divisions of labor, which can be extended to the production of books and the associated reputation economy of academic publishing. However, we also recognize that the release of source code and open access books represents a number of ambiguities related to the sharing economy, free market capitalism, and opportunities to capitalize on free labor. We persist in the hope that our efforts challenge reductive logic, and our publisher, Open Humanities Press, broadly reflects FOSS principles of transparency and reproducibility in its commitment to open access for scholarly work.²⁶ As such, this book can be downloaded for free or purchased as a hard copy at a reasonable price.

This is nothing particularly original. We acknowledge there are numerous other experimental publishing initiatives and even “anti-platforms” for decentralized article publishing.²⁷ There are also plenty of other examples that have picked up on the perversity of writing books about programming where you have to type out the examples to run them, and live coding platforms demonstrate alternatives (e.g. Jupyter Notebook or DevDocs²⁸). Our use of print and an associated software repository is our way of managing this problem. This has also informed our choice of designers for the book: Open Source Publishing collective (OSP) design using only free and open source software — “pieces of software that invite their users to take part in their collaboration,” as they put it²⁹ — and make all files freely available using a Git versioning system that contains all the files for the project, distributed under the terms of Version 2 of the GNU General Public License. The following chapter introduces this in more detail.

In brief, the use of a Git repository for our writing further emphasizes FOSS working principles, and, by treating writing as software, or indeed software as writing, allows us to formalize the production of the book as an iterative process, in need of timely updates, allowing for forking and endless reversioning. By allowing new versions to be produced by others, we hope in a modest way to challenge commercial publishing conventions and illuminate our capacity to understand some of the infrastructures through which we encode our ideas and distribute them across networks. We believe that this way of working marks a departure point for collectively engaging with programming and creating changes in the social-technical systems (both inside and outside). We aim to do something similar to what Adrian Mackenzie has identified as “auto-archaeology” to indicate how the object of study is fully integrated into the analysis, which he demonstrated using the associated GitHub site for his 2017 book Machine Learners.³⁰ This helps us as readers to understand something of the iterative process of writing a book about code in the spirit of how software developers collaborate, host, review, and merge code, as well as build software together.³¹

Flow of contents

Throughout this book, we use JavaScript as the main programming language with a primary focus on the open source and web-based library called p5.js, which already comes with a comprehensive and accessible resource for beginners to learn programming (more details will be included in chapter 1, “Getting started”). Our resource combines the aquisition of technical knowledge as a necessary part of doing critical work, all part of learning to program in its widest sense, programming as doing and thinking, as world-making.

Each chapter of the book starts with a flowchart³² to provide a “diagram” of entangled relationships between the formal/technical and aesthetic/conceptual aspects of its contents. Each captures the dynamic (learning) processes in both concrete and abstract representation for thinking with, especially the relations between the stage setup as expressed in the section “setup(),” starting point as expressed in “start(),” artefacts and sample code as expressed in “Source code,” formal and discursive activities concerning code and syntax as expressed in “Exercises and discussion in class,” and the further extended discussion as expressed in “While().” If a flowchart is conventionally used as an aid to the design of computational processes both for technical understanding and communication,³³ then we also consider critical reflection to be an integral part of that process. Indeed, the flowchart 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.

Beginning with the first chapter, “Getting started,” we illustrate the tools and environments that are required to use the book. The chapter is a guide to making your first program as a means to think through the notion of literacy, both in terms of writing code (RunMe) and writing about code (ReadMe). Chapter 2, “Variable geometry,” explores the use of variables, and the drawing of geometric shapes, sizes, positions, space, and so on, to connect to the discussion of emojis and the politics of representation they invoke. Chapter 3, “Infinite loops,” moves from static to moving objects using different syntaxes for transformation. Using the graphical spinning wheel icon of a preloader, we learn about conditional statements, loops, and time-related syntaxes, to reflect on how technologies play a crucial role in our experience of time. Chapter 4, “Data capture,” introduces how a program captures and processes input data (via audio and webcam devices, mouse and keyboard press, as well as customizable and clickable buttons), and further discusses the consequences of capture and datafication. Chapter 5, “Auto-generator,” focuses on how rules and instructions are performed, and how they can produce unexpected and/or complex results in generative systems, and produce emergent/queer life forms. At this point the book becomes more technically complex, and chapter 6, “Object abstraction,” introduces object-oriented programming in which customizable properties and behaviors of objects are introduced, alongside a discussion of the movement between abstract and concrete reality. Chapter 7, “Vocable code,” pays close attention to notation and computational structure, exploring the poetic relationships between program code and natural language. With a particular focus on voice, we reflect on how the human subject is implicated in coding practices and how coding itself can voice wider political issues. Engaging with the real-time query of an Application Programming Interface (API), chapter 8, “Que(e)ry data,” takes a closer look at how to request and acquire data, exploring how information processing is coupled with data selection, normalization, extraction, transmission, and presentation. As such, we gain an insight into the politics of a query-driven society and the ways in which search engines produce knowledge in compromized forms. Working towards the end of the book, chapter 9, “Algorithmic procedures,” does not focus on code syntax, but instead how we can break down the procedural operations of an algorithm into a logical form. It introduces flowcharts as a means to unfold the practical and conceptual aspects of algorithms, and to explore the political consequences of procedural operations (a strategy adopted to map each chapter, as mentioned above). The last chapter, “Machine unlearning,” introduces machine learning algorithms to explore the implications of training, teaching, and learning in general, drawing together many of the issues across the chapters, and operating as a further reflection on the purpose of the book as a learning tool. But this is not simply didactical, and we offer a bonus chapter in the form of an “Afterword: Recurrent Imaginaries,” a machine-generated chapter based on the contents of the book, on what has been learnt, and what might be unlearnt. In summary, the first six chapters set up the ground from which to understand the fundamental elements of programming, and the last four chapters build upon this towards more speculative forms and imaginaries.

Creative practice is at the forefront of our approach. Every chapter comes with an example that utilizes different technical syntax, facilitating the discussion of the formal aspects of code. But beyond that, we also have experienced in our teaching that students, especially beginners, have difficulty in putting different functions together in a sketch. Although each chapter builds on others, we have found that it is important to repeat the use of syntax and to show how different functions and syntax can be combined and used in multiple ways. Most individual functions can be found using the p5.js reference page or are available in other instructional online videos,³⁴ however we stress the importance of how to bring making and thinking together. Our examples are developed with this in mind and increase complexity across the chapters, and each sketch has around one hundred lines of code for relative ease of comprehension. It should be said that we do not take effective and efficient code to be a priority here and sometimes twist the expected use of syntax accordingly. Indeed we do not aim to offer a comprehensive list of the core p5.js functions like many other programming books, but rather we offer ways of explaining the syntax according to the examples that we have selected and for their ability to generate further discussion. Our examples, inspired by other artists, designers, scientists and theorists, are custom-made according to the perceived pace of learning and their critical potential, with the incorporation of syntax and features that are closely aligned to the corresponding focus of the chapter. Examples are thus provided to spark both the technical and conceptual discussion in and outside of the classroom, including the mini exercises (aka “miniX”) that we have set out for each chapter.

Using the dual elements³⁵ of “RunMe” and “ReadMe” to cultivate reflection by writing code and writing about code, students are encouraged to question the application of their learning in the making of artefacts. Using the pedagogic principle of “low floors, high ceilings,”³⁶ students can easily get started with the materials in the book but each miniX also encourages independent learning by addressing the theme openly instead of looking for a prescribed outcome. We introduce various set and open tasks as well as questions throughout the chapters to test the limits of what is known at any point in time. When it comes to practice and iterative learning, we have also included peer-feedback for every miniX so as to encourage peer learning through reading other people’s code,³⁷ and to further emphasize the diversity of approaches as well as the value of sharing ideas in public, like a shared recipe. The analogy to cooking is something we have adopted in the book by making conceptual parallels between, for example, variables and kitchen containers, algorithms and recipes, and so on. We take inspiration here from our book designers Open Source Publishing who have extensive experience of running workshops for beginners, and adopt their use of kitchen metaphors: drawing together practices of coding and cooking, tasting and testing, to invite further experimentation with various ingredients: “In the OSP kitchen, source files = ingredients.”³⁸

What we have attempted to outline follows the principle of “situated knowledge,” in the sense that what we offer reflects the particular conditions in which it was produced, and the situatedness of the knowledge producers (us, as well as the students we have worked with).³⁹ Specifically, the book has been developed over the past five years through the actual setting of classroom teaching and assignments, in a very specific cultural and educational context, situated within an educational degree program in the humanities with a focus on software studies. Students mostly have had no prior programming experience. The course has run for fourteen classes with blocks of eight and three contact hours every week — for Aesthetic Programming and Software Studies respectively. Though we offer ten main chapters here, in practice⁴⁰ we provide a “pause week” to slow things down by not introducing new functions and syntaxes, instead revisiting previous ones and discussing what constitutes aesthetic programming, and how this links to their weekly practice and learning. We also have project weeks for preparation towards the final assessed submissions. Some flexibility is recommended if you are following this book for your own curriculum and clearly the intention is for readers to adapt, modify and re-arrange the contents to suit their purposes and the particularity of the context in which they work. Our contents are offered as an open resource, to open up different possibilities for making “cuts” across the various materials and ideas,⁴¹ and to encourage readers to fork a copy and customize their own versions, with different references, examples, reflections and new chapters for example, for further modification and re-use.⁴² Thus, adopting the words of Jennifer Gabrys, our project is “an invitation to make, organize, orchestrate, conjure, and sustain people, technology, and worlds toward openings rather than prescribed ends.”⁴³

The book object

Finally we would like to stress that this book is not simply the physical object that you might be holding in your hands as you read these words, but a computational and networked object, distributed across various other spaces and temporalities, made available to both readers and writers alike. In saying this we reference Benjamin again, and his essay “The Author as Producer” in which he writes: “The reader is always prepared to become a writer, in the sense of being one who describes or prescribes. […] And writing about work makes up part of the skill necessary to perform it. Authority to write is no longer founded in a specialist training but in a polytechnical one, and so becomes common property.”⁴⁴ Interestingly, for Benjamin, as with this book, cultural production requires a pedagogic function.

That is precisely our point. The book expresses itself as a dynamic object not fixed in terms of attribution or commodity form or specific determination. It follows that, although this preface is only the beginning of the book, there can be no end: this book is purposefully stuck in an endless loop of its own becoming.

Notes