WEEK 6

Four quadrants

What landed and what did not

We swapped full drafts and filled an A3 sheet with four boxes: I really like that, I do not understand, this works really well, and have you considered. For my draft, peers liked that I questioned why computational systems are expected to be perfect, and that the artist voice stayed present in the writing. They felt the three objectives and pillars sat together in a clear flow.

The gaps showed up in the other two boxes. They wanted a stronger link between slowness, hesitation, and error, and how that connects to care and individuality. They asked who I was citing, what kind of practitioners they are, and requested clearer examples of digital work where traces of the hand are actually visible. Several comments also asked me to name the specific tools and technologies I planned to use, instead of keeping it general.

Language and evidence

Say coding, and show where it comes from

My lecturer pointed out that I hardly used the word coding at all, even though that is what I am doing. I leaned on words like computation and systems, which made the project sound more abstract than it is. The advice was simple: use coding as a verb, and repeat it in context, for example coding for generative design, coding for creative practice. That repetition will make the research question much sharper.

Another point was about name dropping. When I mention theorists, designers, or artists, I often do not say who they are. I need short identifiers so the reader knows why they matter. The same goes for strong claims. They should be followed by precedents, case studies, or specific works, not left floating. Finally, my subtitle, imperfections as a way of making, was flagged as too vague. It should either read as a clear question, a problem statement, or a concise way of framing the proposed response.

Notes as a reader

Clarity as a form of care

Reading four classmates’ drafts made me see how much structure affects attention. The drafts that used story, diagrams, or small visual cues felt easier to follow. Overly dense language quickly lost me. Subtitles that framed the question, problem, or proposal worked better than poetic but vague lines.

I also noticed that references only felt useful when they were triangulated and brought back to the research question. Listing readings was not enough. Name dropping without context was confusing. Taken together, it reminded me that writing here is not just for myself. It needs to carry the reader along, which is its own kind of craft.

Motivation

What happens if I mend instead of restart

This experiment started with a simple question. If a conductive line breaks, what does it mean to repair it and keep going, instead of starting over. I cut a piece of conductive thread into two, tied the ends back together in a visible knot, and wired it up to my existing Arduino and capacitive sketch. The goal was not precision yet, but to see if the circuit would still respond after a clear interruption.

What I observed

The repaired thread stayed conductive. I did not measure changes in resistance yet, so I cannot say what shifted in terms of values, but the basic function remained. The important part here is the gesture. The knot holds the memory of the cut. The system does not return to a clean, untouched state. It carries the scar and still works.

What this suggests

Repair in this case is not just a patch. It becomes part of the method. The knot is a small, physical trace of interruption and care that stays in the circuit. This sits close to how I think about coding and imperfection. Instead of erasing error by restarting, I am interested in ways that repair and adjustment can stay visible and meaningful, both in material practice and in computational work.

Central focus

Does repair change behaviour

The next step was to test whether knots in conductive thread change how a simple circuit behaves. I prepared three samples of the same length. One pristine line, one with a single cut and repair, and one with multiple cuts and repairs. All were kept straight so the only planned difference was the presence and number of knots.

Setup

Sample A was pristine, no cuts. Sample B was cut once and tied back together with a single knot. Sample C had five cuts and five knots spaced along the same length. Each thread was clipped into a simple voltage divider on Arduino so I could read values as analog input. For each sample I took a baseline, flexed the thread a set number of times, then watched how the readings shifted.

What I hoped to see

I expected repaired samples to show higher resistance or more jitter compared to the pristine one. I was also curious whether knots would behave like small scars in the circuit, where readings might change more than in the smooth sections, and whether repaired samples would degrade faster after repeated flexing.

Preliminary readings

Early readings surprised me. The thread with no repairs read around 1301. The sample with one repair read around 1306 to 1308. The sample with five repairs read around 1368. On paper this looked more conductive rather than less, which I did not fully understand yet. It showed me that I need proper resistance measurements and a more careful setup before drawing conclusions.

Sample notes

A — Pristine (14 cm): no repairs; reading around 1301; feel is regular and a bit loose.
B — One repair (14 cm, knot at about 7.5 cm): reading around 1306 to 1308; feels tighter with more tension along the line.
C — Five repairs (14 cm, knots at roughly 0.5, 1.7, 3.2, 6.5, and 9.2 cm): reading around 1368; feels the tightest and most tense to the touch.