Working code is not a proposal. It is a fact. The rest of this article is a defense of that one sentence.
The two orders
There are two orders in which work can happen.
The normal order: propose, get approval, build. It sounds responsible. It is also an open invitation. In that order, everything that is not building gets to intervene before anything exists — meeting politics, turf anxiety, the approval instinct, the colleague who "just has concerns," the executive who kills things by reflex. A proposal is a request for permission, and requests for permission attract opinions the way an open ticket attracts scope.
The reversed order: build, then show. Between you and the working thing there is no moment for the noise to enter, because there is no meeting where it could. The first time anyone with an opinion encounters the work, the work already runs.
"This exists, by the way." A working thing placed on the desk is not an agenda item. It is a fait accompli with a UI.
The asymmetry of negation
Killing a proposal costs two words: "not needed." Nobody remembers saying them. There is no body.
Killing a working thing requires a very different sentence: "It works, but we don't need it." Try saying that in a meeting, out loud, about something that visibly runs and visibly solves a problem. The burden of proof has changed sides. Rejecting a proposal makes you prudent; rejecting a working thing makes you the person who said no to a solution. Most people will not pay that price, and the ones who will must at least spend real argument to do it.
That asymmetry is the entire mechanics of build-first. You are not being braver. You are choosing the arena where negation is expensive.
Facts compound into territory
One working thing is a defense. A history of finished things is territory.
Interference is a transaction with an expected value. When you finish things — actually finish, end to end, not "mostly done" — the expected benefit of interfering with your methods trends toward zero, because your methods keep producing outcomes, and the expected cost stays positive, because you will have reasons and they will have to hear them. Do that long enough and the people around you arrive, one by one, at the same quiet conclusion: I can no longer interject in this person's domain.
Call it the force of output. Not the force of voice — plenty of people are loud — but the pressure that accumulated, delivered work exerts on everyone who might otherwise have an opinion about how you work. Once that pressure exists, your days get easier in a way no job title provides.
Two phone calls
Early in my career I was a rank-and-file engineer at the company where I would later become CTO. The CEO was famously one-man; in later years we would clash more or less daily. But I had finished one project end to end — actually finished it — and in that company, that bought you the next troublesome assignment.
The troublesome assignment came with two external engineers, both of them problems in their own way, neither of them hired by me. So I called them. Separately, about the same work. I was measuring which of the two would move faster — insurance, learned the hard way from watching this organization's weak spots up close. If one stalled, I would already know where to turn.
The CEO overheard the calls and asked why I was doing something so wasteful.
I was, frankly, furious. What came out, though, was not noise: "Having two problematic external engineers is not a situation I created. I'm confirming which one can move faster. Any objections?"
There were none. And from that day on, he never micromanaged my methods again.
Three things were true in that moment, and they generalize.
First, the words were collateralized. A rank-and-file engineer with no finished work behind him says that sentence and it is insubordination. The same sentence, said by the person who finishes things, is a boundary. The force was never in the sentence. It was in the output standing behind it.
Second, methods that look wasteful from the outside are usually experience in encoded form. Two phone calls looked like one call too many — if you could not see the risk model. I could see it because I had paid for it. The people who have not built the thing are not qualified to price the redundancy of those who have. That is not arrogance; it is information asymmetry, and it is why interference from non-builders misses so reliably.
Third, the boundary was drawn once. Hard, with reasons, and then never again. This is not a recipe for chronic combat. Chronic combat is what you get when there is no output to settle the question; the question then has to be re-litigated forever. One collateralized boundary ends the litigation.
Maybe I was simply filed under "difficult." Fine. Difficult without output is just difficult. Difficult with output is called autonomy.
And here is the part I appreciated only later: the company's unwritten law was "the builder wins" — and the proof is that the CEO obeyed it. A man not famous for backing down looked at delivered work plus stated reasons, ran the numbers, and updated. The law was never posted on any wall. His retreat is what disclosed it. It bound even him.
It's OK to be wrong
Why wasn't I afraid to say it? Not courage. I want to be precise about this, because it is the part that transfers.
Being wrong is not what stings. Being caught without a thought behind your action — that is what stings. If the action was fully considered, with your experience and your environment priced in, then a challenge does not require you to invent a defense on the spot. You wrote the defense before the question arrived. Answering is just reading it out. Anger with reasons behind it comes out as precision. Anger without them comes out as noise.
Admit your mistakes, obviously. But notice what a mistake is, in this frame: a considered decision that turned out wrong is not the exposure of a void. It is a model update. You take the new information, you adjust, you continue. Nothing about you was on trial.
And that gives you the tell — the way to know whether you have actually thought something through: both holding course and changing course feel equally unfrightening. Stubbornness and instant capitulation are symptoms of the same disease. When there is no reasoning to defend, you can only defend your ego blindly or fold immediately; those are the only moves left. The person who thought can do either — stand firm when the challenge brings no new information, turn on a dime when it does — and neither one costs anything.
The confidence underneath this is not generic self-belief. It is local knowledge. You know this genba — this system, this codebase, these two particular problematic engineers — better than the person questioning you does. That asymmetry is real, it is earned, and it is allowed to show.
As for fear: I keep exactly one. I fear shipping a careless mistake. That fear operates before the action — it is the thing that drives the verification, the second read, the test you almost skipped. And because it does its work before, there is nothing left for fear to do after. Put one fear in the right place and it buys you out of all the others — including the fear of what people think of you. By the time you have finished a few things end to end, you will notice that last fear has quietly left the building. Not because you ordered it out. States like that do not take orders. They arrive as byproducts.
No one is physically stopping you
Now the part that sounds harsh and is merely factual.
No boss comes to your house in the morning and hits you on the head. Your evenings belong to you. The repository has no lock on it. If working hours no longer allow building the extra thing — the hours I once worked would not be allowed now — then go home and build in your own repo, and one day put it on the desk: "This exists, by the way." The environment can be genuinely bad. Mine was loud, one-man, and exhausting, and I am not going to pretend otherwise. And still: it could not reach my evenings.
The lid on a person's potential is, in the end, placed by that person's own hand. Every "the environment won't let me" I have examined closely turned out to have some room left in it — an evening, a repo, a first small thing that could have been finished.
The environment gets blamed for a lid it did not place.
One honest caveat
Not everyone has free evenings. Care responsibilities, health, a second job — these are real, and this article is not a demand that every engineer code at night. It is a claim about the qualification for excuses. If buildable room sits unused while you curse your environment, the order is wrong: use the room first, then let's talk about the environment. If there is genuinely no room, that is a different conversation, and an honest one — but be honest about which conversation you are in.
Slogans and mechanisms
Facebook had "Code wins arguments." The MIT Media Lab had "Demo or die." The direction is old and correct. What I wanted here is the mechanism underneath the slogans: inverting the order removes the moment where noise can enter; the asymmetry of negation makes facts expensive to kill; finished work compounds into territory where interference stops; and thought placed before action removes fear after it. Slogans tell you what. Mechanisms tell you why it keeps working when nobody is chanting.
If you think your environment is bad
You may be right. I clashed with my CEO daily, and I was not wrong about the environment either.
But being right about the environment ships nothing. It never has. It is the best-documented, most-agreed-upon, least-productive form of correctness in our industry.
So: finish one thing. All the way — not "mostly done," done. That is the entry ticket; territory starts there. Think your next action through until the defense exists before the question does; fear will not survive that. Then build the thing nobody approved, and put it on the desk.
Your evenings are free. The repo has no lock. And your future is the one thing that never needed anyone's approval in the first place.
Top comments (0)