WEEK 10

Too many landmines

From abstract imperfection to concrete practice

Feedback from my RPO presentation made me realise my framing was still too descriptive and too wide. I was using big terms around imperfection, but not showing how it appeared in my own experiments. My supervisor described it as having too many landmines. I was stepping into too many areas at once without grounding them in practice.

I also noticed that I was writing about imperfection more than I was working through it. I kept explaining what imperfection means, instead of demonstrating it in the way I set up systems and respond to their behaviour.

In my notes I wrote, I was writing about imperfection as if it were a belief system, not a design approach.

Changing the question

What can be made when craft and code interact

I rephrased my question from How can we understand imperfection in code to What can be made when craft and coding directly interact. This change made the project active instead of descriptive. It forced me to treat imperfection as something that appears through making, not something to define from a distance.

By placing the focus on the interaction itself, I could move beyond vague phrases like presence of the maker and start thinking about care and patience as active forces. These qualities show up through time, repetition and attention, not only in the final aesthetic.

I wrote in my notes, Theory does not disappear. It finds its place after the experiment.

Three modes of working

Making, reflecting, contextualising

The feedback also showed that my methods section was messy. I kept using words like experiment, prototype and critical journaling in overlapping ways, which made my process sound more complicated than it actually is.

I restructured it into three clearer modes that match how I actually work:

• Making – practical experiments with code, materials, sensors and drawing.
• Reflecting – documentation and analysis through notes, photos and sketches.
• Contextualising – linking these insights to readings and precedents afterwards.

This small structural fix helped me separate what happens in the studio from what happens when I write. It kept the project more grounded and manageable.

Designing small systems

Where craft and code actually collaborate

From this feedback, my focus became clearer: design small systems where craft and code collaborate, not just sit side by side for comparison.

This could mean pairing a p5.js sketch with a physical process, letting an Arduino respond to a hand drawn sensor pattern, or building tools where human gesture and computation both have agency.

I wrote, I moved from theorising imperfection to building systems where imperfection naturally appears through making.

Where code lives

Environment, editor and setup

Today I learned that Node.js lets JavaScript run outside the browser. Normally I think of JavaScript as part of a web page. With Node, the same language can read files, build small servers or run scripts in the background. It feels less like a decorative layer and more like an engine.

I wrote, Knowing how code runs behind the surface lets me design how it slows down.

I also clarified the difference between the tools I use. VS Code is the text editor where I write. Node.js is the environment that executes the code. That separation reminded me of how my FYP sits between two modes. Craft as the manual act, and computation as the system that runs on its own once it is set up.

We were also introduced to Vite as a way to set up modern web projects quickly. It takes care of the messy parts so I can focus on what the code does rather than how to attach it to the page. Even though my project deals with slowness, this showed me that efficiency at the setup level supports slowness at the conceptual level.

I wrote, Technical fluency is not the opposite of craft. It is what lets me slow down with intention.

Learning Node.js and Vite made me realise that in digital practice, understanding the backend is part of craft. It gives me more control over timing, response and how the system feels to use.

Watching Emily Xie

How metaphors frame systems

Over the weekend I watched a YouTube talk by generative artist Emily Xie. One line stayed with me: Metaphors matter because they shape the way we think about things for ourselves, and how others might also think about them too.

It made me more aware of the metaphors I use in my own project. When I say code as craft or gesture as material, I am not just describing. I am deciding how I want others to think about these systems and how I allow myself to think about them.

This pushed me to be more careful with language in my dissertation and CPJ. Metaphors can either open up useful ways of thinking or trap the project in something fuzzy and hard to defend.

Becker on craft

Use, skill and traditions of doing

I also spent time with Howard S. Becker’s writing on art worlds. He describes craft as a body of knowledge and skills used to produce useful objects. His focus is not on technique alone, but on the social and practical work behind making.

This helped because it shifts craft away from a fixed aesthetic and toward a practice grounded in skill, repetition and purpose. Even though my outcomes may not be useful in a traditional sense, Becker’s view reminded me that craft involves applied skill, using the right tools and working within traditions of doing.

It made me ask what the use of my project is. If it is not pragmatic utility, maybe the use is emotional, conceptual or educational. It could sit in slowing down, noticing movement or understanding how gesture behaves through a system.

Code as craft, code as art

Sitting in between

I started a small comparison in my notes. Code as craft feels like applied skill, using the right tools, often collaborative and functional, tied to traditions of doing and made to be operated. Code as art feels closer to individual expression, aesthetic focus and work made to be interpreted.

My project sits between these two. I am treating code as a craft practice because I care about process and skill, but I am also using it to produce artefacts that are read and felt, not only used. This tension feels productive. It gives me room to talk about care and precision alongside ambiguity and interpretation.

Reading Coding As Craft

Coding as part of making, not an add on

I read Coding As Craft: Evolving Standards in Graphic Design Teaching and Practice by Sherry Saunders Freyermuth. The article argues that coding in design education is often treated as a technical extra, but should be approached more like a craft practice, learned through repetition, iteration and attention to detail.

The key takeaway for me is that coding can be taught and discussed using the same language as traditional craft. Process and experimentation matter as much as final visuals, and the value lies not just in what the code produces, but in the thinking that happens while writing and debugging it.

This aligns with how I want to position my FYP. Code is not a separate technical layer. It is part of the making process and part of my craft.

In conclusion

Refining tools, refining thinking

On Tuesday, I learned to refine my question and method so they reflect what I actually do in the studio. On Friday, I learned how my tools shape the way my code lives and runs. Over the weekend, I connected metaphors, craft theory and coding practice, and started to see my work more clearly as coding as craft.

Together, these moments shifted the project from talking about imperfection to building systems where imperfection, patience and attention can appear naturally.

I wrote, Refining my tools is part of refining my thinking. Both are acts of care.