Over-Engineering Was My Favorite Way to Procrastinate

There was a stretch where I was working incredibly hard on this project, producing an enormous amount, and feeling wonderful about all of it — while making almost no real progress. I was designing the grand future of the system: a sprawling, many-part architecture, full of components that would coordinate and scale and eventually run themselves.

The only problem was that the basic thing all of it was supposed to sit on top of did not work yet. At all.

Building the empire before the village

The core of the system — the one fundamental thing it needed to do before anything else mattered — was not working. It was unreliable, half-broken, and stubbornly resistant to my attempts to fix it.

So, naturally, I turned my attention to the layers that would sit above it. How the parts would talk to each other. How it would expand to handle far more than it currently could not even handle a little of. How it would deploy and update itself once it was finished. I was, in effect, drawing a detailed org chart for a company that did not yet have a product — planning the management structure of an enterprise whose single core function did not run.

Why over-engineering feels so good

I want to be honest about why this was so appealing, because the appeal is the whole trap. Designing future architecture is pure, frictionless pleasure. There is no failing test staring back at you, no stubborn bug refusing to die, no reality pushing against your plans. There is just you and a clean mental diagram in which everything fits together perfectly, because nothing in it has been forced to actually run.

It feels like the most productive kind of work precisely because it is the kind with no resistance. And no resistance can feel like progress, right up until you notice you have not actually moved.

The honest name for it: avoidance

The real activity, stripped of its flattering description, was avoidance. The core problem — making the basic thing work — was hard, frustrating, and genuinely uncertain; I did not know if I could solve it, and every attempt rubbed my face in that uncertainty. The grand architecture, by contrast, was easy and endlessly gratifying. I could always make progress there, because “progress” only meant adding another tidy box to a diagram.

So I kept fleeing the hard, real problem into the comfortable, imaginary one, and I gave the fleeing a respectable name. I called it design.

The tell: solving problems I didn’t have yet

There was a clear sign I ignored for a long time. Every elaborate piece I was designing solved a problem that only exists once the basic system works. Coordination only matters if the parts function. Scaling only matters if there is something worth scaling. Self-deployment only matters if there is something finished to deploy. I was building careful answers to questions my project had not yet earned the right to ask.

When you find yourself solving problems you do not actually have yet, it is worth asking which problem you are avoiding instead.

The cost was worse than wasted time

The damage went beyond the hours I poured into imaginary infrastructure. The elaborate structure I designed became a kind of cage. Once I had committed to that grand shape, the simple, direct fixes the real problem actually needed had to fight their way through all the architecture I had prematurely wrapped around a system that did not work. I had built scaffolding for a building that did not exist, and then had to take the scaffolding down before I could even start laying the foundation.

Premature structure does not just waste your effort. It can actively constrain the thing it was supposed to serve, and the more elaborate it is, the more it resists the small, honest changes you eventually have to make.

The fix: earn the next layer

What finally helped was a rule, almost embarrassingly blunt: you do not get to build the layer above until the layer below actually works. Not “is designed.” Not “is planned.” Works. Scale, coordination, automation — these are rewards you earn by having something real and worth scaling, not decorations you add in advance to feel like you are building something serious.

I tore most of the imaginary empire down. It was a relief, in the end, to be left alone with the one hard problem I had been so elaborately avoiding.

The deeper lesson: comfort can be a warning

The most uncomfortable thing I took from this is a suspicion of comfort itself. When the work feels purely good — frictionless, gratifying, with no failure and no reality telling you no — there is a real chance you have quietly steered away from the actual problem and toward an easier, imaginary one that happens to feel like the same thing.

Hard problems push back. That is part of how you know they are the real ones. So now, when building starts to feel suspiciously pleasant, I try to treat the pleasantness as a question rather than a reward: what difficult, resistant, genuinely important thing am I avoiding by enjoying this so much?

— No signals, no returns, not investment advice.