I once pushed the hardest part of a project to the end because I wasn't ready for it.

The project required GraphQL. I wasn't familiar with it. So I kept building the parts I already knew: the components, the layout, the small PRs that felt productive.

When I finally got to GraphQL, I discovered that schema changes took much longer to propagate than I expected.

What I thought was a day of work turned into a week.

I missed my deadline.

Not because the work was impossible, but because I found out too late how long it would take.

The frustration wasn't about the difficulty. It was knowing I could have avoided the whole mess by starting there.

Astro Teller, Captain of Moonshots at X, Alphabet's Moonshot Factory, has a thought experiment: you're trying to teach a monkey to recite Shakespeare while standing on a pedestal. What do you work on first?

Start with the monkey. The pedestal is easy. You can build it anytime. But if the monkey can't learn Shakespeare, none of it matters.

Imagine you're building a real-time chat app in React. You need a message list, a text input, and real-time syncing via WebSockets.

You know how to build the message list and the input box. You've done that a hundred times. But you have no clue how to handle WebSocket connections or reconnection logic when the network drops.

The temptation: focus on the styling, the emoji picker. Feel some progress. That's building the pedestal.

Putting the hard bit at the end means surprises at the worst possible time.

If I had started with GraphQL on day one, I would have hit that wall early, adjusted my estimate, and told the team. Instead, I delivered bad news when it was too late to adjust.

On another project, I started with the most complex component — the one that would teach us how the infrastructure should work and how to talk to the backend. Once we built that, the patterns were set. The other components fell into place.

Even knowing all this, I still fall into the trap. These help me:

Prototype first. Before building anything, do a throwaway prototype that only tackles the risky part. For the chat app, spend a day wiring up a bare WebSocket connection in the console. No UI. No styling. Just: can I make this work? That prototype tells you whether your estimate is 2 days or 2 weeks.

Say it out loud. Share the plan at standup: "I'm tackling the WebSocket logic first." Once you've said it publicly, you feel committed. If you drift back to easy work, the team can flag it.

Ship ugly. Get the hard parts working with minimal UI. A working WebSocket connection with messages in real time, even if the message list is an unstyled <ul>. Once the core works, the polish is easy.

Last month, I spent 2 days building a nice-to-have feature instead of the core problem. I was shipping PRs, getting code reviews, checking things off. It felt like real progress.

Then I hit a wall. The approach had limitations I hadn't considered. It wasn't even recommended. Two days of work, and the hard problem was still exactly where I'd left it.

I had to close the laptop and regroup. The wasted work wasn't what bothered me. It was realizing I'd chosen that work because it was comfortable, not because it mattered.

That's avoidance. And it's sneaky, because it looks and feels like productivity.

Here's the distinction I wish I'd learned earlier:

Paralysis feels like nothing is happening. You're staring at the problem. You can't start. If this is you, knock out a quick easy win to break the freeze. Get your hands moving. Then pivot to the hard thing.

Avoidance feels productive. You're committing code, making PRs, crossing tasks off your list. But the hard problem isn't getting closer to solved. If you're getting things done and the scary part is still untouched, that's not momentum. That's the trap.

Be honest about which one you're in.

Next time you begin a project, ask yourself: what's the part I'm least sure about?

Start there.