Practices
Contemplative Coding
Every instruction has consequences. Every abstraction hides something. Every system carries the values of whoever built it. This practice is a way of learning that slowly, with your hands.
- Time needed 30 minutes, or longer if it holds you
- Alone Can be practised on your own
What this practice is
Contemplative Coding is the slow study or making of systems, done for what it teaches rather than for what it produces.
It is close to what some traditions have meant by manual work as prayer. You take something with a structure, you attend to it for a while without hurrying, and you let the structure teach you. The output is secondary. Sometimes there is no output at all.
We think this is worth naming as a practice because most people’s relationship with technology has become entirely one of use. Things arrive finished. They present a surface. The surface is designed to be effortless, and effortlessness is precisely the condition under which we stop asking how anything works or who it works for.
What it teaches
Four things, which arrive in this order and are difficult to learn any other way.
Every instruction has consequences. You write a line, and something happens that you did not fully picture. You change a rule in a process, and three weeks later someone is stuck. The gap between what you meant and what you caused is the whole moral problem of building things, compressed into something you can hold.
Every abstraction conceals complexity. A name stands in for a mechanism. This is necessary; nobody can hold the whole stack. But abstraction is a promise that the hidden part is not your problem, and that promise is sometimes false in ways that only become visible when someone is hurt.
Every system reflects the values of its makers. Not usually deliberately. A form has fields, and the fields are the shapes of life it was willing to imagine. A default is a moral position that nobody had to defend.
Every creator inherits responsibility. You did not choose the people your system will meet. You are answerable to them anyway.
It does not require programming
We want to be plain about this, because the name suggests otherwise and the name is only a name.
Repairing a device is contemplative coding. So is taking apart something broken to understand why it failed, even if you cannot fix it. So is designing a process at work so that the tired person on a Friday afternoon still gets it right. So is studying a system you did not build: reading how a benefits assessment is scored, or how a school allocates places, or how water reaches your street.
Mapping relationships counts. Drawing the actual path a request takes through an institution, with the waits and the handoffs and the place where it disappears for six weeks, is a serious piece of work and almost nobody does it.
Organising knowledge counts. So does documenting a problem that everyone has learned to route around, which is one of the most useful and least rewarded things a person can do.
Improving accessibility counts, and counts particularly. Making a thing usable by someone with different sight, hearing, movement, memory, or attention is the clearest available form of building for a person who is not you.
None of these require money, a computer, or training. Several require only paper and stubbornness.
Working without an audience
The practice asks you to separate making from being seen making.
Modern work makes this hard. Almost every act of construction now has a place to be posted. The posting is not wrong, but it changes what you are doing while you do it: you begin to build the version that explains well, which is not always the version that is true.
So try, at least sometimes, to do the work in private. Fix the thing and tell no one. Trace the system and keep the map for yourself. Notice whether the work still feels worth doing, and notice honestly if it does not.
Where it goes wrong
It goes wrong when it becomes productivity with better lighting. If you find yourself measuring the practice in output, it has quietly turned back into work.
It goes wrong when the study of systems becomes a way of feeling superior to the people who use them without understanding. Most people do not have time. That is not a failing.
And it goes wrong if it becomes another obligation. This practice is optional, like all of them. If your week has no room in it, the correct response is not guilt. It is to leave the practice alone until it is genuinely available to you, and to notice that a life with no room in it is itself a system worth examining.
The sequence
The order matters more than the wording. Nothing here has to be said aloud, and no step is improved by being hurried.
-
Choose something small and real
Pick one system you can actually reach: a script, a broken lamp, a form your workplace uses, the route a complaint takes through an organisation. Small is not a compromise here. Small is the point.
-
Work without an audience
Set aside the question of whether this will be seen, shipped, or praised. If it helps, decide in advance that you will not tell anyone.
-
Follow one thread to the bottom
Take a single behaviour and trace it as far down as you can go before you lose the thread. Note the exact point where your understanding stops.
-
Name what the system assumes
Write down what it takes for granted about the person using it: their language, their income, their body, their attention, their honesty.
-
Ask who bears the cost of an error
Follow a failure through to a person. Not a metric. A person, with a name you could imagine.
-
Leave one thing better documented than you found it
A comment, a note, a label, a short message to whoever comes next. This is the offering, and it is meant to be modest.
Questions to sit with
- What is the last system I used without any idea how it worked, and did that bother me?
- When I build or arrange something, whose convenience am I optimising for by default?
- Where does my understanding of the tools I depend on actually stop?