The Space Before Building

The step I kept skipping and why it matters more than ever

A few weeks ago I wrote about Skillset, a Claude Code plugin I built to automate my development workflow. Five skills. Full lifecycle. I was proud of it.

Then I kept using it and realized I’d been doing it wrong.

The Gap

The skill I called plan fetched a ticket, set up a branch, and jumped straight into implementation. How are we going to build this? Useful work. Wrong question.

Should we build this? Why? What problem does it solve? Are there other approaches? What happens if we don’t build it at all?

I was treating every ticket like the thinking was done. Like the only remaining work was how. Most of the time I was just eager to build. And eagerness is a terrible substitute for understanding.

You can spend your whole life climbing the ladder, only to find it’s leaning against the wrong wall. - Joesph Campbell

That’s what happens when you skip the why and go straight to the how. You build the wrong thing at full speed.

The Pause

There is a quote I go back to quite a bit. A piece of wisdom so poignant I’ve taped it to my desk where I journal every morning.

Between stimulus and response there is a space. In that space is our power to choose our response. - Viktor Frankl

Sure, that advice is about far more than software development, but that just means it applies here as well. Between the need for something to get done and the doing of it, there is a space that most of us collapse entirely. We see the ask, we feel the pull of the keyboard, and we start building. No pause.

That space is where the real work lives. It always has been. Requirements gathering, problem framing, trade off analysis. None of this is new. We have always just been eager to get to the “real” work.

Now building is cheap. AI writes code at a pace that would have seemed absurd two years ago. The entirety of human knowledge is at our fingertips. We can answer hard questions faster than any generation of builders before us.

So why don’t we?

The Pattern

The more people I talk to, the more I see the same thing. A deep, genuine proclivity toward building. Eyes lighting up about architecture and elegant solutions and gnarly problems conquered. That energy is real.

But then the questions get harder. Why this? Who is it for? Can it be a business?

A hesitation. Almost a flinch.

“I want it to be, but... that’s hard work.”

The building is the comfort zone. It feels productive because it is productive, in the narrowest sense. Lines of code. Features shipped. But productivity without direction is just motion. And the ladder is only as useful as the wall it’s leaning against.

What I Changed

I went back to skillset and split plan into two phases.

plan is the real one now. It takes a ticket and starts a dialogue. Not about implementation. About requirements. What are we doing and why? It asks one question at a time. Challenges assumptions. Surfaces edge cases. Everything lives on the ticket itself, built out iteratively until the problem is understood.

design is what the old plan was. Branch setup, codebase exploration, implementation. The how. It only fires after the why has been explored.

One extra step. The entire character of the work changed.

The Space

We got into this field because we love building. Being told the future demands more thinking than typing can feel like the fun part is ending.

It’s not ending. It’s evolving.

The best sessions I have now start with fifteen minutes of genuine dialogue about a problem. Why does this matter? What are the trade offs? What are we missing? Then the implementation materializes in a fraction of the time.

The creative satisfaction didn’t go anywhere. It migrated. From the typing to the thinking. From the how to the why.

The thinking was always the good part. We just did so much typing we forgot.

Between the ticket and the code, there is a space. I’m learning to stay in it. I’d encourage you to do the same.