As a newcomer to live coding, I find the text to be a captivating journey into a realm that transcends the boundaries of conventional programming. Given my little experience with python, c++ and p5.js, the idea of writing code in real time, modifying programs on the fly, and projecting the entire coding process to an audience is both exciting and terrifying. The concept of making software “live” goes beyond my first impression of coding as a static process. The reciprocal relationship between the coder and the code, in which both adapt to one other in real time, provides a refreshing perspective. It challenges the idea of code as a static set of instructions by introducing a dynamic, changing entity that responds to the coder’s requirements.

The text’s analogy of live coding to an improvising composer in the context of music provides a relatable comparison. As a singer and songwriter myself,it’s like envisioning my computer as the instrument, much like my trusty guitar, and the lines of code as the chords forming the foundation for my digital melody. Embracing this paradigm allows me to approach live coding from a musician’s perspective. My laptop evolves into a diverse instrument, and the code serves as my musical language. Live coding creates a digital stage on which I can dynamically compose, improvise, and perform, transforming my code into a song that I may sing and share with the world. 

Thus, for someone new to live coding, this text provides an introduction to a dynamic and evolving field. It inspires me to explore coding’s creative possibilities, emphasizing improvisation, transparency, and the transformative power of live coding. It defies established beliefs about code’s rigidity, portraying it as a living, breathing entity that grows in real time, and invites me to embark on an intriguing journey that promises to be experimental and fun throughout.

This opening excerpt from Live Coding: A User’s Manual offers a compelling definition (or rather, a set of definitions) for the practice, art, and philosophy of “Live Coding.” I was immediately intrigued by how the author(s) addresses the strange nature of writing a book about live coding, much less one that seeks to be a manual (“there is something perverse in writing a book about live doing”). Posed with this question, I was then convinced by the claim that the very constraints of written text—the same ones that lend to this “perverse” disjunction—may also serve to be ample grounds for creative and critical thought. Within this very first portion of the book I saw what I thought to be the riveting soul of live coding: a performance practice that both works within and challenges the limitations of the media used (whether it be the computer used to code or even the book used as a manual).

Another idea that stood out to me was the identity and presence of the “user.” Much of the definition of live coding hinges the presentation of this live conversation held between the user and the machine. I was particularly struck by the part of the text in which the artist Olia Lialina was invoked to discuss the disappearance of the user. The mention of “smart” products and how “Big Tech wants computers to be invisible so our experience of using them becomes seemingly natural” thus goes in tandem (or rather, at odds with) how live coding may be seen as an ideologically potent practice that directly fights against this (corporate) trend to bring the user—and the computer—back into the visible foreground (or even existence) It then does not seem to be merely coincidental that the very title of the book describes itself as “A User‘s Manual.”

The reading touches upon some of professor’s explanation of ‘live coding’ in the first class. It’s something without a set definition or form, and it’s also the attempt to break the normalities of coding and software engineering.

As a computer science student, I’ve always felt like programming is more on the structured and restricting side, rather than the free and formless side. There’s a lot of style and format that has to be met, and there seems to be an answer to solving problems ‘effeciently.’ Hence, programming to me seems like a quiet war that I had to have within myself, trying to figure out what the best way of approach or thinking would be.

I think live coding will be liberating in that it’s not such a lonely fight. Live coders can share their approach and thinking on the spot with the audience. It may or may not be the best way, but regardless that thought process may be what makes the performance interesting.

Sarah Groff Hennign-Palermo’s expression that live coding is about “thinking otherwise about coding- what it can be, rather than what it is” makes me excited to try this new form of programming and coding.

I was quickly entrenched in reading Love Coding’s user manual. Alan F. Blackwell – the author – quickly grabbed my attention when he outright challenged the notion of a user. This chapter immediately brings up multiple dynamics that come into play when one is using a computer, a piece of software, code. I found it fascinating how Blackwell juxtaposes Big Tech’s aim to make computers invisible for a good user experience, and Live Coding’s emphasis on the code. Furthermore, other characteristics of live coding mentioned make me very curious about the field. For example, I had never considered the temporality of software. I wonder if being “constrained” within the present tense when coding live will alter my perspective of regular software. I am also very interested in the materiality of software. The idea presented by the author that live coding brings out the materiality of a computer and hardware is interesting to say the least.

The practice of live coding as per Blackwell’s introduction makes me recall the live poets that I saw on the streets of New Orleans. These people write poems for people on the spot on a typewriter. The magic of these experiences lies not on the poem, but on the temporality and visibility of the whole process. I am eager to explore live coding and recreate this sensation that the poets brought out! Perhaps exploring the elements that Blackwell points out through this comparison will be a useful experience!!

The answer to this question was somewhat unclear to me before I took this class. I had watched an IM showcase performance from this course before, but apart from finding it very cool I wasn’t sure what the ideas behind it were. The book Live Coding: A User’s Manual quotes live coder David Ogborn on why live coding should not have a fixed definition:

“To define something is to stake a claim to its future, to make a claim about what it should be or become. This makes me hesitate to define live coding.”


As mentioned in the text, Computer Science textbooks and other sources where static code is printed often become outdated pretty quickly due to the ever-changing nature of coding practices. This holds even more true for live coding, which is improvisatory and involves thinking on the fly, writing and rewriting all in a public performance.

I liked the reflectiveness this reading incited, especially when it came to questions such as what it means to be live. I had not been aware of the etymology of programming (“writing in public”). Given the isolationist nature of programming today, we could say that we have strayed a lot from these ancient origins, further highlighting the need for live coding. Opening up this usually private activity to the public provides a liberating creative aspect which is also helpful in building community.

Finally, I want to touch upon the analogy to musicians they made for live coding in a creative context. This was particularly the most exciting part for me. I have watched live jazz performances and been floored by the open jam sessions where random people would come together with their instruments and jam on the spot, not having met or practised together before. I do not know much about music theory, so I just learned that what they usually do is choose notes from a particular chord sheet. Live coding gives even more freedom to the performers and basically makes them the on-the-spot composers, which is daunting but exhilarating to imagine. Overall, this reading made me look forward to learning more about live coding and actually practising it myself.

In this writing, instead of answering the question, “What is Live Coding?” with a fixed definition, the author explains it as making software live by interacting with each other, with software, and with the act of coding itself. What I like about this writing is how the author looks at live coding as “thinking in public” and as communication between the performers and the crowd. In live coding, the performers openly share their mental process through codes, while the audience gets to question and reflect on it as they follow the journey. Live coding differs from traditional computing, where we only focus on refined code rather than the process of coding itself.

The most interesting part for me was the following: “Live coding asks questions about liveness, inviting us to reflect on what it means to be live—to have bodies, to communicate, to act.” It made me think of live coding as a collective and performative ritual where everyone in the room is connected through the code-as-interface. I think live coding is an interesting and relevant way of performance that makes coding more accessible and visible, especially now when software is deeply entangled with our everyday lives.

The reading from “Live Coding: A User’s Manual” by Alan F. Blackwell and others presents live coding not just as a technical practice, but as a profound cultural and philosophical phenomenon. This perspective invites a deeper exploration of live coding beyond its surface-level description. The reluctance to strictly define live coding, as expressed by David Ogborn, suggests that its essence lies in its fluidity and resistance to rigid categorization. This resistance is not merely a characteristic of live coding; it is a statement about the nature of creativity and interaction in the digital age.

Live coding challenges conventional notions of software development, which is typically seen as a methodical, behind-the-scenes process. By bringing the act of coding into the public sphere, live coding transforms programming into a performative art. This transformation raises questions about the relationship between the coder and the audience, the nature of software as a creative medium, and the role of improvisation in technological practices. The act of coding in real-time, in front of an audience, demystifies the process, making technology more accessible and understandable. It bridges the gap between the enigmatic world of code and the tangible human experience.

Furthermore, the concept of “thinking in public” as a form of live coding is intriguing. It suggests a vulnerability and openness in the creative process, where the coder exposes their thought process, errors, and revisions in real-time. This transparency is a stark contrast to the often opaque nature of software development. It invites the audience to engage with the process of creation, blurring the lines between creator and spectator. The text also touches upon the idea of live coding as a way to “unthink” conventional engineering practices. This notion aligns with Viktor Shklovsky’s concept of defamiliarization, where familiar objects or practices are made strange to enhance perception. In the context of live coding, this means viewing code not just as a tool for building software, but as a medium for artistic expression and exploration. It encourages a reevaluation of the roles of creator and audience, the nature of software as an artistic medium, and the potential for improvisation and spontaneity in technological practices. Live coding is not just about making software live; it’s about bringing life to the process of software creation.