Code as Material

Practice - what you do

The Conventional View

In traditional education, code is treated as instruction: you tell the computer what to do, it does it. Code is a means to an end - the end being the running program.

This frames code as transparent. You think about what you want; code makes it happen. The code itself is irrelevant; only the result matters.

The Material View

In the material view, code has its own properties - like clay, wood, or paint. You work with it, not just through it. It pushes back. It suggests possibilities. It resists certain things and enables others.

Properties

Code has inherent properties:

It runs: Unlike a sketch, code executes. You can feel it.
It's exact: No ambiguity. 0.5 is not "about half."
It's repeatable: Same input, same output (usually). You can iterate precisely.
It's modular: Pieces can be combined, separated, reused.
It's fragile: Small changes can break everything. Syntax matters.

Resistances

Code resists certain things:

Vagueness ("make it feel good" isn't code)
Simultaneity (things happen in sequence, not at once)
Continuous values (you pick a number; the material doesn't)
Inconsistency (it does exactly what you said, even if you didn't mean it)

Possibilities

Code enables things other materials can't:

Instant variation (change a number, see different behavior)
Parametric design (expose values, make them tunable)
Interactivity (the material responds to input)
Reproduction (copy infinitely, share globally)
Combination (stack systems on systems)

What This Changes

Design Through Implementation

If code is material, you design through implementation, not before it. You discover possibilities by working with the material. A painter doesn't fully plan the painting before touching canvas; a designer doesn't fully plan the feel before touching code.

Prototyping as Sketching

Code prototypes are sketches in material. Rough, exploratory, meant to be thrown away. Like a sculptor's maquette, the prototype reveals what the material can do.

Feel Is Found

Gesture emerges from the code. You can imagine how a jump should feel, but the actual feel comes from gravity values, jump velocities, frame timing. The code gives you the feel; you refine it.

Parameters Are Handles

Good code exposes parameters - handles you can grab to change the behavior. The Code Bank scaffolds are designed this way: exposed variables at the top, tunable without understanding the implementation.

The Code Bank as Material Library

The Code Bank provides pre-shaped materials. Like buying lumber instead of felling trees, or using premixed paint instead of grinding pigments.

You're not cheating by using scaffolds. You're starting with refined material so you can focus on design decisions, not implementation details.

Use scaffolds to:

Get something running fast
Feel the behavior before deciding if it's right
Tune parameters to find the feel you want
Learn by reading working code

Knowing vs. Feeling

Knowing what you want is not the same as feeling it. "I want a floaty jump" is knowledge. The actual floaty jump - the gravity, the hang time, the landing - is feel. Code makes the jump real. Then you react to the real thing.

This is why prototyping matters. You don't know if your idea works until you feel it in material form.

Exercise: Material Exploration

Take any Code Bank scaffold. Don't try to make anything specific. Instead:

Change every exposed variable to see what it does
Push values to extremes (gravity = 10000? gravity = 0.1?)
Note which changes produce interesting behaviors
Find a feel you didn't expect but like

This is material exploration - discovery through manipulation.

Craft - for educators

Why Teach This

The "code as instruction" framing makes students afraid of code. It's abstract, logical, demanding. You have to know exactly what you want before you start.

The "code as material" framing invites exploration. You don't need to know what you're making - you need to start making and see what happens. This is how artists work. It's less intimidating.

Introducing the Concept

We introduce "code as material" in Week 1, before any coding. We talk about other materials: clay, paint, wood, fabric. What are their properties? What do they resist? What do they enable?

Then: code is the same. It has properties. We're going to learn them by working with the material.

Scaffolds as Entry Point

The Code Bank scaffolds let students work with code-as-material without writing code from scratch. They start by tuning, then modifying, then eventually building.

This is how apprentices learn crafts: start with prepared materials, focus on one skill at a time, gradually take on more of the process.

Common Challenges

"I don't know what values to use":

Good. That's the point. You find them by trying. Start somewhere. See what it feels like. Adjust. The material tells you when you're close.

"I want to do something the scaffold doesn't support":

Perfect. This is when you start modifying the scaffold - or writing new code. The material is telling you it wants to grow. Follow it.

"The code broke and I don't know why":

This is debugging. The material pushed back. Now you read it to understand what happened.

Assessment

Assess process, not just product. Did the student explore the material? Did they discover something unexpected? Can they articulate what the code does and why?

The material exploration exercise above works as an assessment: document what you found by manipulating the material.

Theory - deeper grounding

Theoretical Background

Key Influences

Donald Schon: The Reflective Practitioner. Designing as a conversation with materials. The designer proposes; the material responds; the designer adjusts.

Seymour Papert: Mindstorms. Constructionism - learning by building. The computer as a material for thinking.

Richard Sennett: The Craftsman. Material engagement as a form of thought. The hand and the head are not separate.

The Phenomenology of Materials

Every material has a phenomenology - a way it presents itself to the person working with it. Wood has grain. Clay has plasticity. Paint has viscosity.

Code's phenomenology includes: instantness (changes appear immediately), precision (exact values), fragility (syntax errors break everything), and depth (layers of abstraction).

Learning a material means learning its phenomenology - how it feels to work with, what it wants to do, where it resists.

What We're Taking

The insight that design happens in dialogue with material, not before touching it. This licenses exploration, reduces the pressure to "know what you want" in advance, and positions prototyping as central to design.

What We're Resisting

The "code is just a tool" view: Tools are extensions of intention. Materials have their own agency. Code shapes design, not just executes it.

The "design documents first" approach: Documents have their place, but they're not design. The design is in the material. Docs are plans; material is reality.

Unresolved Questions

How much should designers know about the material's internal structure? You can work with clay without knowing chemistry - but is code the same?
At what point does "material exploration" become "random messing around"? How do we scaffold productive exploration?
Does the material metaphor work for non-programmers? Or does it require enough code literacy to "feel" the material?

References

Schon, Donald. The Reflective Practitioner (1983)
Papert, Seymour. Mindstorms (1980)
Sennett, Richard. The Craftsman (2008)
Ingold, Tim. Making: Anthropology, Archaeology, Art and Architecture (2013)