Building Is a Strange Way of Refusing to Accept Reality

Building is a strange way of refusing to accept reality. It begins with a quiet objection: this could work better; this should not hurt so much; this problem does not have to keep repeating. You look at what already exists and, for a moment, behave as if it is not final.

That refusal can feel childish. Children are not very interested in accepting the world exactly as it was handed to them. They rearrange it, invent rules, and make another thing out of whatever is nearby. Growing older often means being taught to call the existing version realistic. Building lets me resist that lesson, but it has also taught me a more adult form of acceptance: I cannot control whether what I make arrives at the right time, reaches the right person, or becomes important to anyone else.

You can build for yourself, and only for yourself. Everything after that belongs partly to luck, timing, context, and other people.

Franco Zeta

Looking for work made this difficult to remember. I spent too much time trying to prove that I could be useful in the exact shape a job description requested. Every unanswered application made usefulness feel like a verdict delivered by someone else. Perhaps my first job was not as a developer, but work still taught me to notice friction inside a business: the repeated task, the unclear handoff, the small process everyone tolerates because nobody has stopped to name it.

That changed the role I imagine for myself. I do not only want to inherit a ticket and translate it into code. I want to understand why the problem exists, who keeps paying its cost, and whether a smaller intervention could remove it. Sometimes that intervention is software. Sometimes it is automation, a clearer interface, or a conversation between people who have been solving different halves of the same problem.

I do not think legacy work is beneath me, and novelty by itself is not a virtue. I simply know that I feel most alive where something can still be questioned. I want to help build work that is new where newness matters, unique where character matters, and efficient where people are losing time. A simple change can resolve something that looked impossibly complicated from a distance.

You do not need to be a brilliant mind to do useful work. You need enough patience to understand the problem and enough empathy to notice how it feels from the other side. Start with your own pain as a customer, a user, or the person responsible for a project. Then accept that your view is incomplete. You are not every role at once, but you can listen across roles and suggest what they may not yet see together.

This is not a new idea. In How to Get Startup Ideas, Paul Graham argues that real ideas often begin with problems you have experienced yourself. Don Norman makes the more important correction in People-Centered (Not Tech-Driven) Design: begin with human abilities and needs, then let technology extend them. The point is not to romanticize personal pain. It is to treat lived experience as evidence, then test it against the experience of other people.

Programming has sometimes been a cure for my loneliness. I do not mean that it fixes loneliness, or that every difficult feeling should become a project. I mean that it gives my attention somewhere honest to go. When nobody speaks to me, I can make one thing respond. When my thoughts are noisy, a system asks me to name them more precisely. When I do not understand myself, the way I build can reveal what I care about: clarity, patience, control, beauty, usefulness, or simply the relief of finishing something small.

There is no shame in using programming as a way to stay with yourself. A refuge becomes dangerous only when you mistake it for the whole world. Code cannot replace friendship, rest, grief, or asking for help. But it can be a room in which you recover enough quiet to return to them.

Life is absurdly imprecise, much like a system. There is no perfect system, only consistency trying to become more precise so the people using it do not have to suffer the same damage every day. We are not superheroes. We do not remove chaos. At our best, we build a more tolerable interface for living with it.

Fred Brooks wrote in No Silver Bullet that software contains an essential complexity that no single technical breakthrough can erase. I find that strangely comforting. The goal is not perfection. The goal is to understand enough of the complexity to stop passing its cost to someone else.

A phrase still follows me: apprentice to everything, master of nothing. Maybe it is an accusation. Maybe it is permission. I have not decided. For now, I would rather remain curious enough to cross the boundaries between business, design, code, and the ordinary discomforts that reveal where a system is failing.

Choose your path, but do not be afraid of the thing that distracts you for a while. Some distractions are rehearsals for the person you are becoming. You do not need the world to confirm that you were necessary before you begin. Improve. Cry. Build. Then let timing decide what happens next.