It’s been eye-opening for me to read about the multimodal epistemological model in live coding. It’s improved my comprehension of the various types of expertise and ability that go into becoming proficient in live coding. For me, this idea has been immensely comforting because I often feel inadequate because of my perceived lack of technical skill. I even feel incompetent at times. However, this concept has enabled me to see that my formal programming language expertise and my ability to write perfect code are not the only factors that determine my value as a live coder. Rather, it highlights the significance of embodied knowledge, reflective practice, and experience learning.

I identify personally with the notion that acquiring information entails combining many forms of understanding. It confirms my conviction that the experiences and learnings I get from practicing live coding—even when it means making mistakes—are important contributions to my development as a coder. It gives me the confidence to accept my learning and growth path and the knowledge that mistakes are to be expected along my journey.

It has also been immensely liberating for me to realize the playfulness and autotelic nature of live coding. The pressure to perform flawlessly in front of an audience during live coding sessions has often been unbearable for me as a performer who is used to being on stage. But my attitude has changed when I realized that the fun of live coding comes from the process itself, not from reaching perfection. It has aided in my realization that accepting experimentation, ambiguity, and even failure as necessary components of the creative process is acceptable. I can now approach live coding with interest and playfulness instead of fear and worry – although it will be hard to get rid of these habits.

This reading about live coding has also prompted me to explore different ways of thinking. It has forced me to see coding as a kind of creative expression and problem-solving as well as a technical ability. I can now think more creatively and innovatively when I code thanks to this mentality change. I now view live coding as a chance to participate in a dynamic conversation between creativity and technology, where experimentation and improvisation are valued, as opposed to concentrating only on creating flawless code.

In “Creative Know-How and No How” the author discusses the practice of live coding through the lens of artistic research and epistemology. The reader is quickly thrown questions like ‘what does live coding know?’ or ‘what does live coding think?’ From this analysis, there are a couple of points which grabbed my attention. For one, this chapter presents an interesting characterization of live coding. It quotes Brian Massumi in explaining that, instead of a predefined artwork, live coding presents “a movement precise with training but still open to regeneration.” Furthermore, it reinforces that the performance of live code makes visible a language deeply embedded into our day-to-day but one “in which still few are so fluent.” In doing so, it highlights how live coding sits at the crossroads of many disciplines. That is to say, it provides visibility to code (CS) through the production of music and visuals (Art), and gives insight into the human behind the screen writing this code. 

“Live coders appropriate and redirect (hack) a specific form of technical knowledge and language which is then played with.”

The author also characterizes live coding as a play experience through Robert Calloi’s framework of Play. In particular, mentioning the autotelic nature of live coding (as play) stood out to me. If live coding, like play, is autotelic (inherently without function or purpose beyond itself), how can we then address the know-how and think-how of live coding. 

Finally, through this excerpt I keep being brought back to our class on composition, when Professor Sherwood kept telling us “just try random things until it sounds decent”. It is also through trial and error only with which I’ve made any progress on my composition project. In response to this reading, I understand how this artistic experimentation, art as the process, applies to our class and my own journey of live coding. I’ve been really enjoying exploring a field not as constrained as others, and would love to see how it will keep impacting the study of knowledge.

I love how the author explains that in live coding, each of the programmer and the program becomes “mutually part of an open-ended and contingent process of both problem generation and problem solving.” Until now, although I had the understanding that live coding is all about showing the process, there was some pressure that the approach that will be shown ‘has to make sense’ and ‘build up’ towards something. The author’s word created a shift in my perspective that the beauty of live coding performances lies in that the process is not just about problem solving and making things better, but also about creating or running into problems and showing how the programmer deals with them through trials and errors.

Expanding on my initial thought that live coding performance still has to ‘build up’ to create something fancy, I think I limited myself to thinking that there has to be an ultimate product I should be aiming for. After reading the philosopher Paolo Virno’s saying “what characterizes the work of performing artist is that their actions have no extrinsic goal” and that “the purpose of their activity coincides entirely with its own execution.” My understanding is that yes, the performance should show progress in some way, but the focus is not necessarily about the end goal and more about making the best (or interesting) moves for that instance and seeing where the performer can go with that.

“Not knowing is not only to be overcome, but sought, explored and savored; where failure, boredom, frustration and getting lost are constructively deployed.”

I feel Like this quote is something I one tries to understand on a deeper level to be able to live code. The idea of knowing for science and not knowing for art is sometimes bigger than just a know-how and a no-how, like a balance between both is also at some level required. The author talked in the reading about the idea of knowing how something works is not exactly required for creating in a live coding environment; that is is more about the exploration, the errors, the questions raised and the answers (or possibly answers?) found. It is about feeling the music in some way, feeling the visuals and trying to find a common ground for which you can go forward.

However, as the authors explained,

“Both ancient weaving and live coding involve a live, embodied process of decision-making and knowledge activation that operates in excess of or between the lines of conventional notational systems.”

the know how is also always in a way required. The idea that some sort of knowledge is required, but experienced level knowledge is not. That by live coding you need to keep the next part of the carpet unknown to keep going, yet you base what is to come on what was, and what is to come is what bases layers and layers of code to reach the end of the carpet. That the knowledge of how to code, how to weave, at a basic level, needs to be acquired before live coding, that some idea of color and music needs to be there. But that is the idea, that knowledge of some is all that is needed for one to have the ability to live code. It is more a talent of how to build layers over one another, the unpredictability and the block of advanced scientific knowledge that is needed.

Forcing yourself out side the box of science and thinking else where. That is what live coding needs, that is what comes from pushing yourself, exploring something new and seeing the things you know from the things you do not know to find an area where art shines.

The reading presents live coding as a dynamic interplay between problem generation and problem-solving, where practitioners continuously test the boundaries of possibility. This unpredictable and experimental nature resonates with my own experience in preparing for class demonstrations, where the journey often involves navigating uncharted territory and embracing the unknown. Most of my class demo preparation so far involves trying different things, testing, adding new things, and experimenting without knowing the answers until I end up somewhere. It’s like driving without a destination, exploring the possibilities, and ending up wherever my curiosity takes me.

The concept of embodied knowledge and “knowing-in-action” reminded me of the quote “Knowledge is a rumor until it lives in the body” from a Sci-fi TV series The OA. While the practice of live coding itself requires a preconceived knowledge, I appreciated how the text pointed out that a risk and uncertainty are innate parts of the practice. It explains how Live coding performances actively disclose to an audience their moments of not knowing, of trial and error, and of testing something out. Therefore, embracing failure and trying to figure out how to make it work is part of the live coding process. However, This is easier said than done since one can sometimes panic and mess up even more when they are presenting in front of an audience.

In this text, the author discusses the cognitive process of Live Coding and how it encompasses different ways of thinking. For example, the author states that live coding “pressures the if-then thinking of computational logic toward the what-if of speculative experimentation.” It is interesting to view live coding as an experimental way of computing where open experimentation is actively encouraged compared to the standard way of programming. In some way, I felt the same way because, in live coding, you first try something, modify it, and expand on it until you like the outcome, while in the standard way of computing, you want to have logic in mind before you start typing. However, I think both are similar when you start improvising the code. In both scenarios, you want to understand what you wrote and improve – to make the codes perform what you imagined and to make them cleaner. For example, in live coding, you might want to group multiple sound layers into a structure or assign them to a variable after you find something you like. Similarly, when writing codes for software, you want to remove unnecessary lines or structure them in a more consistent way after you implement the functionality. Therefore, I think there are some areas in the process where live coding and other ways of computing overlap and differ.

I found the reading made me critically consider how complex live coding is, especially in relation to software engineering. Having a SWE background myself, I primarily saw programming as a way to fulfill requirements and the trial and error involved were always roadblocks to the end goal of creating a program that meets certain specifications. However, working in Hydra and TidalCycles, I found myself agreeing with the idea that the process of trial and error leads to roadblocks but also innovation. I may have a certain sound I’m trying to create, but in trying to do so, I may create a completely different sound I enjoy and incorporate into my final piece. The idea of no-how adds to this, with uncertainty of how something might look or sound comes new innovation and avenues of artistic expression.