Attachment to Code: When You Cannot Delete the Thing You Are Proud Of

What it actually looks like

Someone suggests replacing a piece of your system with an off-the-shelf tool, and before you have thought about it you are already listing reasons why that would not work. The reasons are technically correct. You have noticed that you produce them faster than you produce reasons in the other direction.

You have a module you would describe as the best thing you have built. You can name the problem it solves elegantly. You cannot remember the last time a user encountered it.

The numbers came in flat again, and within about forty seconds you had a frame for them. Seasonality. The onboarding change. A bad week for the category. Each explanation is plausible on its own. You have made four of them in a row and have not yet made the other kind.

When an advisor said the word "pivot", something in your chest went tight before your mind had formed an opinion. You spent the rest of the conversation being reasonable and the drive home constructing the argument you did not make.

There is a branch you have not merged and cannot delete. Nothing depends on it. You know it is dead. Deleting it feels like it would mean something, so it sits there.

And the test that gives it away: you can accept criticism of your company, your pricing, your timing, your positioning — and criticism of that one part of the codebase lands somewhere different, somewhere older, and takes longer to leave.

Who this happens to

This is common among people who are genuinely good at building.

If you spent years developing real craft, you learned to tell your work apart from everyone else's, and you learned to care about the difference. That discrimination is the skill. It is also what makes a codebase feel authored rather than assembled — and an authored thing is much harder to throw away than an assembled one.

It is common in founders who have been on one project for a long time. Not because the months create a debt, but because a thing you have touched every day for two years stops being an external object. It becomes the place you go, the shape your thinking has taken, the record of how much better you got. Very little in a founder's life accumulates that visibly.

It happens to technical founders in particular because the artifact is unusually legible. A designer's work goes to a client, a salesperson's work becomes a number. Your work stays in front of you, reviewable, improvable, yours, forever. It is the rare kind of output you can keep loving up close.

And it is common in people whose self-respect runs through their competence — who are steady when they are producing something good and less steady when they are not. That is not a flaw. It is just a load-bearing arrangement, and the artifact is holding more of the weight than it looks like it is.

What sets it off

It is worth noticing that this almost never fires while things are going well.

The usual trigger is a stretch of flat traction. Not a collapse — a quiet run of weeks where the graph does not move and no single event explains it. That is the condition under which the work has to justify itself on merit, and merit is exactly what you are least able to assess about your own build.

The sharpest trigger is someone else naming it out loud. An advisor suggesting you move on, a co-founder saying the thing carefully, a user describing your favourite feature as confusing. The suggestion is about the product and it does not land like it is about the product.

A competing idea gaining interest does it from the other direction — a nearby space getting attention while yours does not, so that continuing to build becomes a thing you are choosing rather than a thing you are doing. Choosing requires a reason, and the reason available is the one you feel.

And it fires hardest at the exact moment a kill decision becomes possible: when the evidence is clear enough to act on and not yet so overwhelming that no defence survives. That window is where the good arguments get made.

Why it keeps happening

The mechanism is simple and it is not about the hours.

This is where attachment to code and the sunk cost trap get mistaken for each other, and separating them is most of the work. Sunk cost is an accounting error: eighteen months and a hundred thousand dollars are already spent, and you let that spending vote on a decision it has no business voting on. It runs on arithmetic. You would feel it about a channel, a hire, a contract — anything with a ledger.

Attachment runs on identity, and it does not need a ledger at all. You can feel it fiercely about a weekend project that cost you nothing. What makes it hard to move is not the size of the investment but the fact that the thing became a piece of the answer to who you are. Cutting it is not experienced as a write-off. It is experienced as a small subtraction from yourself.

That is why the reasoning goes the way it does. Once the artifact is part of you, evaluating it honestly and defending it become the same activity from the inside — you are not weighing evidence and reaching a conclusion, you are protecting something and finding evidence on the way. This is not dishonesty and it does not feel like bias. It feels like knowing your own work better than the person criticising it, which is usually true, and which is precisely what makes the defence so convincing.

And the cost compounds quietly. Every month the thing survives on your defence rather than on its results, it takes another month of your attention with it and gathers another layer of story. The product is not really what is being protected. What is being protected is the version of you that built it and was right.

What actually helps

Separate the lesson from the artifact, out loud, before you decide anything. The two years did not buy you a codebase. They bought you the knowledge of what this market does not want, how this problem actually behaves, and how much better you build now than you did then. That is the asset, and it is not stored in the repository. It is stored in you, and it leaves with you. The code was the receipt.

Then ask one question that has nothing to do with you: does this serve the person using it? Not is it good, not was it hard, not could anyone else have written it. Ask it about one specific piece this week — the module you would defend, the feature you are proud of, the branch you cannot delete. Answer in one sentence, with a user in it. If you cannot get a user into the sentence, you have your answer.

Get one outside read on the thing you are most confident about. Not the part you are unsure of — you already ask about that. Hand someone the part you would defend, and ask them what it costs to keep. Your judgment about your own work is reliable everywhere except here.

Practise deleting something small enough not to hurt. The dead branch. The clever helper nothing calls. Do it this week, notice what the feeling actually is and how long it lasts, and let yourself find out that the skill that built it is entirely intact afterwards. That is the fact that makes the larger decision possible later, and you cannot reason your way to it.

And put a date on the argument rather than winning it. If you believe this is worth continuing, name what you expect to be true in six weeks and write it down before you start. Then the next flat month is answered by a note you already wrote, instead of by a defence you assemble in the moment out of whatever is nearest. You are the author, not the manuscript. You have written better things than this since.