The Origin Story
I still remember the moment clearly. I was sitting in yet another product planning meeting, whiteboard markers in hand, discussing features we would build "someday." The engineers were nodding politely while I drew diagrams of what I wanted. And I thought: Why can't I just build this myself?
That question changed everything.
The Scientific Basis for Learning to Code
According to research on deliberate practice (Ericsson, 2006), experts aren't born — they're made through focused, structured practice. The 10,000-hour rule, while often misinterpreted, has a kernel of truth: mastery requires sustained effort.
What does this mean for learning to code as a PM?
- Chunking — Break complex problems into smaller, learnable units
- Spaced repetition — Review concepts over time
- Immediate feedback — Coding provides instant validation (it works or it doesn't)
"The brain is not a vessel to be filled, but a fire to be kindled." — Plutarch
The Backstory
At 27, I had already co-founded Glaz — a company I built with my own hands in New York. We were doing product design and development, and it was exciting. We were growing.
But here's what they don't tell you about startups: the cost of running a team is prohibitive.
According to data from AngelList, the average startup in NYC spends 40-60% of its budget on personnel. In 2017-2018, when I was running Glaz, the burn rate was unsustainable. Engineers in NYC commanded $150k+ salaries, plus equity, plus overhead.
The math didn't work. We could design great products, but hiring to build them was eating us alive.
The Pivot: Dallas
So I made a tough decision: move to Dallas, restart, and figure out a new path.
Dallas offered:
- Lower cost of living (40-50% less than NYC)
- Growing tech scene
- A chance to rebuild from scratch
But I didn't just want to recreate what I had done before. I wanted to build things myself.
The Learning Science
I approached learning to code like a product:
The Feynman Technique
- Choose a concept
- Teach it to a child
- Identify gaps and go back to the source
- Simplify and use analogies
My Implementation
- Morning: Learn a new concept (YouTube tutorials, freeCodeCamp)
- Evening: Build something with it
- Weekend: Apply to a real project
Research shows this interleaving — mixing different skills — leads to better long-term retention than blocking (Bjork, 1994).
The Beginning
I started with:
- freeCodeCamp — Structured curriculum
- Codecademy — Interactive exercises
- YouTube — Traversy Media, Net Ninja
- Eloquent JavaScript — The book that made it click
The first few months were humbling:
- Syntax errors everywhere
- CSS layouts that wouldn't align
- Debugging for hours to fix a missing semicolon
But there was something addictive about it. When the code worked — when the page rendered, when the button clicked — it worked. No ambiguity. No waiting for someone else.
What the Research Says About My Journey
The Curse of Knowledge
In his seminal paper, The Curse of Knowledge, Economist John List shows that experts can't easily imagine being novices. This is why good documentation matters — and why I write these posts. I remember being confused, so I write for my past self.
Growth Mindset
Carol Dweck's research on growth mindset changed how I approached failures. Every bug wasn't a failure — it was data. Every error message was feedback.
"In the growth mindset, failure can be a painful experience. But it doesn't define you." — Carol Dweck
What I Learned
Looking back, here's what that first year taught me:
-
You don't need permission to start — Anyone can learn. The internet is full of free resources.
-
Perfection is the enemy of progress — My early code was messy. But it worked. Ship first, refactor later.
-
Building beats planning — I spent years planning products. Coding let me actually build them.
-
The cost of hiring is prohibitive — Running a team in NYC taught me this. That's why I'm building solo with AI now.
The Meta-Learning
Here's the real insight: learning how to learn is the skill that matters most.
According to Stanford's Learning How to Learn course (Dr. Barbara Oakley), the two modes of thinking are:
- Focused mode — Linear, analytical
- Diffuse mode — Creative, associative
I learned to switch between them:
- Focused: Writing code, debugging
- Diffuse: Walking, showering, sleeping
Many of my best solutions came in the shower.
Why It Matters Now
Three years later, I can build full-stack applications. Not perfectly, but functional. Not production-ready out of the box, but close enough to validate ideas quickly.
The gap between vision and execution? It's almost gone.
And now, with AI agents, that gap is even smaller. But that's a story for later.
References
- Ericsson, K.A. (2006). "The Influence of Experience and Deliberate Practice on the Development of Superior Expert Performance"
- Bjork, R.A. (1994). "Einstellung, the Dips Effect, and Learning"
- Dweck, C.S. (2006). "Mindset: The New Psychology of Success"
- Oakley, B. (2014). "Learning How to Learn" — Coursera