Forty Years of Code, Still Can't Type: A Developer's Confession

After forty years of writing code, I finally realized the thing that made me feel like an impostor had nothing to do with my ability to code—and everything to do with my fingers.

TL;DR

I’ve been writing code for over forty years. I’ve never taken a single computer class. And despite building countless projects that work, that solve real problems, that create value, I’ve spent most of those four decades feeling like a fraud.

Here’s my confession: I’m terrible at the mechanical act of coding.

This isn’t a story about replacing developers with AI. It’s about removing an unnecessary handicap so I could finally code the way my brain was wired to.

The Love and the Struggle

I love creating digital things from thin air. The moment when you imagine something that could exist, work through the logic in your head, and then, solely by thinking, make it real. That part is magic, and that part I’m good at.

But there’s a gap between my brain and the computer. A chasm, really. And crossing it has always felt like walking through quicksand.

I literally cannot touch type. I’ve tried to learn, so many times, but my fingers don’t work that way. Ironically, when typing natural language (like this sentence), my index and middle fingers on both hands race across the keys faster than you’d guess. The words flow from thought to screen (though often not spelled as they should).

But code? Code demands perfection: the right words, the right spelling, the right syntax. Every brace, every semicolon, every character in exactly the right place. One hundred percent accuracy, no exceptions. And I’m a terrible speller on top of it all.

My brain excels at problem-solving. It’s great at seeing patterns, understanding systems, architecting solutions. But it struggles with mechanical precision. And for forty years, I’ve been trying to force a problem-solving brain to do transcription work that requires a level of exactness my fingers have never mastered.

The Reality of My Days

Here’s what implementing a simple authentication check actually looked like for me:

The Thinking: “Need to verify user has admin role OR owns this resource.” It was clear, simple, immediate.

The Transcription:

1. Look up the syntax for our authorization library
2. Type the condition slowly, fixing typos as I go: if (user.hasRole('admin') || resource.ownerId == user.id)
3. Catch the typo myself: should be === not ==
4. Remember to add error handling; look up try/catch syntax again
5. Add the try/catch block
6. Run the linter, fix the typos it catches
7. Re-read everything one more time to make sure

The thinking was quick. The transcription felt endless. The ratio was backwards.

By the end of a coding session, I’d be exhausted. Not the good exhaustion of solving hard problems, but the draining fatigue of transcription work. Like an introvert after hours in a loud room, depleted from the wrong kind of effort.

And I kept thinking: Real developers don’t struggle like this. Real developers don’t make these basic mistakes. Real developers can just… type.

The typing was necessary work. I was just really, really bad at it. So bad that I developed an unsustainable coping mechanism over the decades: code frenzies. I’d psych myself up, marshal all my energy and focus, and have these huge bursts of productivity where I’d push through the exhaustion and transcribe as much as I could. Then I’d crash. For days afterward, I’d have no energy for coding. I could research, plan, think through problems, but actually writing code? I had to wait until I’d recovered enough to force another frenzy.

For me, this is what “being a developer” meant. This was my normal.

To bosses, clients, and teammates, it probably looked fine. The work got done. I hit deadlines. But I was working myself to mental exhaustion just to produce what other developers seemed to do effortlessly.

The Turning Point

Then I started using Claude Code. Not as a replacement for my thinking (I’m still the one solving the problems, making the architectural decisions, determining what the code needs to do) but as a partner that handles the mechanical transcription while I maintain creative control.

Something unexpected happened.

The bottleneck between my brain and the computer was gone. I could think through a problem and see it implemented correctly, immediately. No typos, no syntax errors, no hunting down the same function signature for the dozenth time. And best of all, no exhaustion from forced mechanical precision.

I was getting more done, feeling better at the end of the day, and most importantly, I was still writing code, still creating, still solving problems.

I just wasn’t spending most of my energy on transcription anymore.

What Changed

With Claude Code, the frenzies stopped. I could work at a steady pace. Think through a problem, explain it in detail, review the implementation, move on to the next problem. No psyching myself up. No crashes. No cycles of burst and recovery.

For forty years, I’d been measuring myself against the wrong metric. “Good developers” were people who could type code quickly and accurately. But that was confusing the medium with the message.

I was always a great developer. I was just programming on hard mode for four decades.

What This Isn’t

Working at the Speed of Thought

These days, I work differently. When I need to implement something, I think through the problem, explain what needs to happen, and Claude Code handles the transcription. I review it, validate it, adjust it. The code is still mine—I’m still the one creating it, making the decisions, taking responsibility for it.

I’m just not exhausting myself typing it anymore.

A Recent Example:

Recently, I rebuilt the search functionality for my LocallyGrown.net farmers market platform. The old Rails implementation was slow and inflexible. I needed to add filters, improve performance, and support multiple market contexts.

With Claude Code:

• Designed the new architecture (my decisions about caching strategy, query optimization, API structure)
• Explained the requirements and constraints
• Reviewed the generated TypeScript services and Svelte components
• Caught edge cases Claude missed (markets with no active products, search terms with special characters)
• Adjusted and shipped

The work that used to take days of exhausting transcription now takes hours of focused problem-solving. Not because the thinking is easier, but because the mechanical bottleneck is gone.

The projects I’m building now ship faster, work better, and reach more people. The code is not fundamentally different, and I’m not draining my energy on transcription anymore.

Will the impostor syndrome ever fully fade? Probably not. There will always be ways, real or imagined, to measure myself against my peers. That’s not something a tool can fix.

But now I have one more coping mechanism stripped away, one more mask that was hiding my neurodivergence that I can remove. The code frenzies, the exhaustion, the forced mechanical precision—I don’t need those anymore to keep up.

After forty years of trying to force my brain to work like everyone else’s, I can finally apply my actual strengths: the thinking, the problem-solving, the architecture, the creation of digital things from thin air.

The typing was never going to be my strength. And that’s okay now.