13. What Do I Believe and Build?
The Problem: Code Is a Trace of Belief
At two in the morning, an incident alert sounds. A red graph spikes on the monitor, and someone posts in the team channel, “Let's roll back to the previous version for now.” Someone presses the deployment button, someone searches for logs, and someone copies and pastes customer inquiries. At moments like this, we usually ask technical questions. Which service is down? Which commit caused it? Will a rollback restore the system? But there is another question we should ask first: What did we believe about how the system ought to work?
Every piece of software contains unstated beliefs. The belief that users will read the terms, that data will be accurate, that a network interruption will be followed by reconnection, that administrators will not abuse their privileges, and that future developers will understand today's code. Design documents usually list features and interfaces, but it is the assumptions underneath them that determine a system's character. In making something, an engineer also fixes the sentence “This is how the world is” in an executable form.
The Philosophical Question: Belief Is Not Preference but Responsibility
Philosophy pauses what we take for granted. When someone says that efficiency is good, it asks whose standard of efficiency is being used. When someone says that automation is convenient, it asks who pays the price of that convenience. Engineering translates those questions back into code and structure. So asking “What do we believe?” is not a personal confession of faith. It is a decision-making standard and a design principle that makes responsibility traceable when things fail.
Suppose we are building a recommendation system. The team chooses increased time spent on the service as its measure of success. At first, this seems like a natural choice: if users stay longer, the content must be more engaging. But as that metric is optimized again and again, the system may begin optimizing the intensity of stimulation rather than user satisfaction. Posts that provoke anger, headlines that trigger anxiety, and information that reinforces what people already believe take over the screen. The algorithm is not a neutral calculator here. It is closer to an institution that reproduces, moment by moment, the belief that “watching for longer is a good experience.”
We might instead believe that users have the right to understand and adjust their own feeds. If so, the design changes. It displays why something was recommended, lets users reduce or disable the weight of particular signals, and provides options such as chronological viewing or deleting their browsing history. Autonomy must be built into the API, data model, settings screen, and audit log; it cannot remain a sentence on a help page. If a belief does not become structure, it remains a slogan.
An Engineering Case: A Maintainable System Is a Way of Trusting the Future
Maintenance is also a question of belief. Organizations that prioritize rapid release often say, “We'll clean it up later.” But that is not merely a promise to postpone technical debt. It is a decision to spend the time of developers who have not yet arrived in order to move faster today. Nameless flags, tangled global state, and exception handling whose purpose is unexplained will later bill someone else for the cost of interpretation.
Readable code, explicit boundaries, and observability that does not hide failure are, by contrast, designs that trust future colleagues. They express the belief that those colleagues should be able to repair the system even if they do not remember every piece of context. Tests are not only devices for preventing bugs. They are records that declare, “This behavior is not accidental; it is a promise we chose to preserve.” Database migration procedures and rollback plans say the same thing. Rather than believing that the system will always operate normally, they express a belief that it must be recoverable when it breaks.
The same questions recur in organizational decisions. Should security review be an approval gate immediately before deployment, or an input to the design from the beginning? Should we search for the person who caused an outage, or change the boundaries between permissions and automation so that the same mistake cannot be amplified? The former trusts individual attentiveness; the latter trusts the power of structure. The choice between them does not remain only in meeting minutes. It appears in on-call fatigue, customer trust, and the scale of the next incident.
Objection and Tension: Can We Build Without Beliefs?
There is, of course, an objection: if we question every assumption, we will never build anything. Releases have deadlines, budgets are limited, and some assumptions must be accepted provisionally. Real products are not built on complete certainty. The problem is not having beliefs; it is hiding them as though they were facts.
Assumptions should be marked as assumptions. Which users are central, what error rate is tolerable, which data must be retained, and who should have the authority to stop the system—all of this should be visible in documents and metrics. And when a belief turns out to be wrong, we must be able to change it. Reversible deployments, gradual rollouts, experiment stop conditions, and independent audit paths turn philosophical humility into engineering mechanisms.
Questions to Leave With
What image of the human does the function I wrote today, or the roadmap I approved, assume? Does it treat users as people to be controlled, or as collaborators who can understand and choose? Do I trust my colleagues to repair this code in the future? And when that trust is misplaced, can the system warn and stop without relying on someone's goodwill? What we build is not only a set of features. It is a small model of the world we believe in.