Dancing with code

How the right guide dissolved my developer paralysis

This isn’t the post I usually write for you.

You’re here for conversations about learning and growth, not coding tutorials. And this isn’t one. But I want to tell you about something that happened to me recently, something that looks like it’s about code and AI tools, but is really about the walls we carry inside ourselves.

For thirty years, I have been involved in coding. Close enough to sense its power. Never bold enough to try. I told myself I was better suited for writing and research. Those stories were true. But they were also armor against a deeper fear: I’m not smart enough for this, I’m not patient enough …

Then, a few months ago, I found the right guide at the right moment. Someone who said, “We don’t have to succeed here right now. Let’s just see what happens.” Six words that changed everything.

What follows is about learning to code with AI. But it’s really about what happens when we trade the need to get things right for the willingness to get curious. About how the right mentor teaches you to think about problems differently.

If you’ve ever stood frozen at the edge of something you desperately wanted to learn but felt certain you’d never master, this story is for you.

Let’s see what happens.

---

I’ve circled code for decades, close enough to sense its power, never bold enough to wield it. I can certainly navigate command lines, copy scripts if prompted, and adjust HTML as needed. Yet, asked to write code from scratch, I froze. This paralysis steered me toward safer ground: writing, research, and podcasting. I told myself I preferred communication to code. Really, I was just afraid to break things.

Then Fraser Gorrie entered, arriving when I was ready to either learn or finally give up. Recommended by a friend, he brought a different approach: “vibe coding,” collaborating with AI tools like Claude Code CLI and Cursor IDE.

Fraser said, “Tom, you were playing the game I used to play. I’m only a few steps ahead.” As we progressed, he would remind me when I stumbled through basics, just to relax, Claude itself, and others will help.

Fraser revealed vibe coding isn’t abandoning structure, but adopting rigor through conversation. Instead of focusing on syntax, you concentrate on what you want to achieve, channeling your energy into your vision rather than worrying about syntax or typos.

Think of it like writing evolving paragraphs, as Fraser explained during one of our sessions. That helped a lot - given how much I write.

You start with ‘I want a simple landing page.’

Then you add ‘add a hero section that has a subtle parallax effect.’

Then, ‘the navigation should stick after scrolling past the hero.’

You’re building complexity in digestible layers.

I include an example structured project.md file at the end that describes the entire description of my initial request to Claude. It covers the technology stack, how I want the web user interface to look and act, and the graphics details with references to other sites I used as an example. The details of implementation I left to Claude.

This structured approach resonated with my engineering training; we referred to it as systematic decomposition, which involves breaking complex systems into manageable components. The difference was that Claude Code could implement each layer methodically, letting me see and adjust as I went, rather than trying to specify everything upfront in perfect syntax.

The critical skill wasn’t learning JavaScript; it was learning to articulate systematic, evolving specifications. I had to become excellent at turning vague desires into structured narratives that a language model could execute step by step. A well-organized project file that outlines the steps “First, establish the navigation structure. Then, create the content sections. Finally, add the interactive elements” became more valuable than knowing Python syntax. Strangely, this required more disciplined thinking than traditional coding. I was freed from syntax but had to become a word architect who could describe a building process, step by step, clearly enough for a master builder to construct it.

This approach raised uncomfortable questions from my developer friends. “You’re not really learning programming,” they warned. “You’re learning to be an AI operator.” They weren’t wrong. When my Claude subscription lapsed for three days, I was effectively paralyzed again. But here’s what that criticism misses: I wasn’t trying to become a software engineer. I was trying to escape a different kind of paralysis: the inability to bring ideas to life. And what structured thinking vibe is required for coding? That was real. The ability to decompose problems, to build incrementally, to think in systems: those skills transcended any particular syntax or framework.

My first real project was rebuilding tomparish.com: not a practice site, not a tutorial exercise, but my actual website, hosted on Cloudflare and managed through GitHub. Fraser’s approach was masterful in its simplicity. Two terminal windows: one for running the development server, one for Claude. We established macros for common tasks (the Q-COMMIT command became my faithful companion). We built branches for experiments, keeping the main branch safe from my inevitable mistakes. Each session followed the same pattern: articulate the intent, implement incrementally, observe the results, and refine the specification. It was engineering thinking applied through natural language.

The moment everything shifted came while setting up an interactive contact form functionality through Resend. We’d been at it for an hour: DNS records, API keys, MX records, verification processes. My screen was littered with terminal windows, each displaying different varieties of failure. The old, familiar paralysis was creeping up my spine, that voice whispering, ‘You’re not smart enough for this; you’ll never be smart enough for this.’ I was about to suggest we give up, maybe just put my email or linkedin address on the page, when Fraser said something that changed everything: “We don’t have to succeed here right now. Let’s just see what happens.”

The simplicity of it stopped me in my tracks. We don’t have to succeed. We’re just seeing what happens.

I typed the next command. It failed. But instead of panic, I felt... curious. What specific part had failed? The API key? The environment variable? We traced through the error message like detectives following clues rather than students failing a test. Claude Code was communicative, suggesting possibilities, explaining the meaning of each failure, and offering alternative approaches. It wasn’t just executing commands; it was teaching me to think systematically about problems. Twenty minutes later, my contact form actually sent an email to my inbox. I didn’t just feel satisfaction. I felt like I’d learned a new way of thinking, not just about code, but about building things incrementally, systematically, and fearlessly.

Shifting from needing to get it right to being curious changed everything. When something broke (and things would break), it became information, not indictment. Each error was Claude saying, “This piece doesn’t fit here. Let’s try something else.” Fraser never acted as an all-knowing guru. “Let me check that,” he’d say, or “I’m not sure; let’s find out together.” We were both orchestrating, both learning this new collaborative approach to building.

What surprised me was the joy. Not just satisfaction at tasks completed, but real delight as ideas became reality through structured AI conversations. The old paralysis faded, giving way to a creative flow. I began spotting possibilities everywhere, from work tools to tracking writing projects, confident I could specify, test, and refine solutions.

Another step forward came last week, when Fraser guided me in building a portable studio for my writing. Using Electron, we assembled a desktop app that housed all my future tools: outlines, templates,RSS feed reader tools, accessible on both Mac and Windows. The real breakthrough, though, was about process: we started with a simple intent and added features through conversation, layer by layer. What once seemed unattainable, creating desktop applications, became possible. More importantly, I understood how and why each part worked, giving me the confidence to expand the tool in the future.

That’s what the right guide provides: not just knowledge, but a framework for thinking about problems. Fraser didn’t teach me to be a developer. He taught me to think systematically about development, to build incrementally through structured conversation, and to treat AI not as a crutch but as a collaborator that could implement my architectural thinking. There’s a difference, and for someone who spent decades paralyzed by the fear of breaking things, it’s the difference that matters.

The code that once paralyzed me has become a language of possibility, not of syntax and semicolons, but of intent and structure, of systematic decomposition and incremental refinement. I speak it through Claude now. Together, we articulate visions that become reality through patient, iterative conversation. And what happens, more often than not, is something gets built: something that didn’t exist before, born from structured thinking rather than memorized syntax.

Something mine.

Reference: Fraser Gorrie - https://frasergorrie.com

If you would like to see the starting project file I used as a starting point in Claude Code, see below. It will mean becoming a paid member. My goal is to provide more project files like this to show the structured approach of the learning process. Thank you.