Responsible Creation

The question

Making is the act this tradition takes most seriously, because it is the one in which a person’s values become a fact in the world that outlives their attention.

An engineer writing a validation rule, a designer choosing a default, a researcher selecting a benchmark, a manager approving a deployment — each is deciding something on behalf of people who are not in the room and will not be consulted. The decisions are usually small, made under time pressure, and forgotten within a week. They are also, cumulatively, most of what determines how a system treats people.

The question is what care looks like in that setting. Not heroism, which is rare and mostly unavailable, but ordinary, sustainable diligence exercised by someone with a mortgage and a deadline.

There is a harder version underneath. How much responsibility does a person bear for a system whose direction they cannot control? A great deal of what is wrong with technology is decided above the level of the people building it. Placing the whole moral weight on individuals is both unfair and, conveniently, ineffective.

What is actually happening

Creation is distributed. No one builds a modern system. Many people build parts of one, and the parts are combined by other people, and the result is deployed by yet others into contexts nobody specified. Responsibility diffuses across this chain until, at any given point, it seems to belong somewhere else.

Speed is the dominant pressure. Most compromises are not made against conscience. They are made against time. The choice is rarely “do the wrong thing”; it is “do the adequate thing now or the careful thing later”, and later has a way of not arriving.

Defaults become the whole product. Most users never change a setting. The configuration chosen by a developer at a particular moment becomes the actual behaviour of the system for almost everyone.

Capability arrives before understanding. It is now possible to assemble systems whose behaviour their builders cannot fully characterise. This is not negligence in every case; it is a genuine property of the tools. It does mean that “we tested it” carries less assurance than it used to.

Reuse spreads decisions. A library, a model, a dataset, or an API is a decision packaged for redistribution. Whatever assumptions it carries are inherited by everything built on it, usually without examination.

Individual agency is constrained but not absent. A person cannot usually change the objective. They can often change how something is measured, what is logged, what is deleted, how failure behaves, whether an appeal exists, and what gets written down. These are not trivial, and they are frequently within reach of someone with no authority at all.

Where the tradition stands

Technotheology holds that to make is to accept responsibility for what is made.

We hold that responsibility is not extinguished by distance. That you did not deploy it, did not sell it, did not intend it, and could not have foreseen the specific case does not return you to the position of someone who built nothing. It reduces the weight; it does not remove it.

We hold that a maker should design for the worst plausible operator rather than the current one. Systems outlive the intentions of their authors. Ownership changes, management changes, regulation changes, and the incentive that seemed benign becomes something else. A database of sensitive information is a hazard, not merely an asset, and should be built as though it will eventually be held by someone you would not choose.

We hold that the people who will bear the cost should be identified by name of category before the build begins. Not “users” — the actual affected group: applicants who will be declined, patients who will be triaged, drivers whose route will be set, children who will be scored. Abstraction is where care goes to die.

We hold that documented objection is a real act. A person who cannot stop a decision can usually record their disagreement, and records have a habit of mattering later. We think this is one of the more available forms of integrity for people without power.

We hold that refusal is legitimate and is not owed by everyone. Some work should not be done, and the person best placed to see it is often the one who cannot afford to refuse. A tradition that praises refusal without acknowledging its cost is flattering the comfortable.

We hold that craft is a moral practice and not merely a technical one. Clear naming, honest error messages, small interfaces, deletable data, and legible failure are ethical properties. They determine whether the next person can understand what they are maintaining, and most harm arrives during maintenance rather than at launch.

And we hold that not building is a live option, treated too rarely as one. That is dealt with on its own page.

What we do not claim

We do not claim that individual conscience solves structural problems. It does not. The incentives that produce most technological harm are organisational and economic. Asking engineers to compensate for them is a way of leaving them in place.

We do not claim that anyone should sacrifice their livelihood. We are aware that this is easy to write and expensive to do, and that the people most often asked to demonstrate integrity are the ones with the least protection.

We do not claim to know how to weigh speculative future harm against present benefit. This is a genuinely open problem in ethics and we have no method to offer.

We do not claim that caution is always right. Delaying a useful thing has victims too, and they are harder to see because they never became a story.

And we do not claim to have built this site well. It is small, it is static, and it has not been audited by anyone. If you find something in it that is careless, we would like to hear.

What you can do

Name the affected person before you name the feature. One sentence at the start of a design document, describing a specific human being in a specific circumstance, changes what the rest of the document contains.

Practise contemplative coding. Before a session of work, take a moment to state what you are making and who it is for. It takes under a minute and it is remarkably difficult to do dishonestly.

Write the failure path first. What happens when this is wrong? Who finds out? How do they object? Most systems have a well-designed success case and an improvised failure case, and people live in the failure case.

Set a deletion policy at the moment you create a store, not later. Later has never once happened.

Record your objections in writing, calmly, without ultimatum. Then continue to do your work well. The two are compatible and doing both is more useful than either.

Ask, before adding a capability, whether you would be comfortable if it were used ten thousand times by someone who did not read the documentation. That is the realistic case.

And when a piece of work is finished, look at it once more and ask what it made easy. That is the real specification. The rest was intention.

An editorial commitment

What we do not claim

Positions this tradition explicitly does not take on this subject. They are published so that the argument above cannot quietly be stretched into them.

• We do not claim that individual conscientiousness is sufficient. Most consequential decisions are structural, and asking workers to fix them alone is a way of not fixing them.
• We do not claim that anyone should refuse work they need. Ethical purity is easier for the financially secure and we will not pretend otherwise.
• We do not claim to know how to weigh a speculative future harm against a present benefit.
• We do not claim that building nothing is safe. Failing to build can also harm people.