Live coding makes the process of thinking visible — including errors, trial and error, and self-reflexive annotation — as part of the performance

The making visible of operational thinking is central to live coding performance. This includes: the live code itself as it is written, error messages when they appear, and sometimes live annotations or comments embedded in the code for the audience. Importantly, making the process visible is not always about transparency or explanation — it can add complexity, further enriching the work through purposeful opacity, humor, or confusion. The showing of the screen makes not-knowing visible, turning trial and error into performance material rather than shameful failure. This also means live coding is constitutionally different from a lecture or tutorial: the performer is not teaching but sharing an unfolding creative process that includes genuine uncertainty.

Examples

A live coder writes a comment, then evaluates a block that crashes — the comment and the error are both visible. The audience sees the thought process, the attempt, and the recovery. This moment is impossible in pre-composed performance.

Assessment

Why is it insufficient to say live coding is transparent because the code is visible? Give an example of a live coding moment where making the process visible adds complexity or opacity rather than clarity.