Why I Started Learning to Code at 35

Every product manager has experienced it: you write a spec that seems clear, hand it to engineering, and what comes back isn't what you imagined. Sometimes it's better than you expected. More often, it's different in ways that matter—edge cases you didn't consider, performance constraints you didn't know existed, architectural decisions that close off future options. This isn't engineering's fault. It's a communication gap. Specs are abstractions. Code is reality. The gap between them is where products fail. I've shipped dozens of features where the spec-to-implementation translation went wrong. Sometimes catastrophically. A feature that seemed simple required weeks of refactoring. An "easy" integration turned out to be architecturally impossible without major changes. A "quick win" became a six-month project. The pattern was always the same: I didn't understand what I was asking for.

I started with Python. Then moved into building AI applications with LangChain, RAG architectures, and various frameworks. Here's what it's taught me: Technical constraints are real. When an engineer says "that's harder than it looks," I now understand why. I've experienced the difference between something that seems simple and something that is simple. They're not the same. Everything has tradeoffs. Fast vs. maintainable. Flexible vs. simple. Scalable vs. quick to build. These weren't abstractions before—I knew they existed. Now I feel them. Every line of code is a decision. Debugging is most of the work. I used to think engineering was mostly writing code. It's not. It's mostly figuring out why code doesn't work. This changes how you think about timelines, complexity, and what "done" means. Edge cases multiply. That feature that handles five user scenarios? Each scenario has ten edge cases. Each edge case has three ways to fail. The complexity isn't in the main path—it's in everything else. The best product sense comes from building. When you've built something yourself, you see products differently. You notice architectural decisions. You recognize patterns. You understand why some things are easy and others are hard.

Ten years ago, learning to code as a product manager would have meant months of basics before building anything useful. Today, AI has changed that. I use Claude and other AI tools to accelerate learning. When I don't understand something, I ask. When I'm stuck on a bug, I get help. When I want to build something, I can prototype it in hours instead of weeks. At Pangea.ai, we used AI to reduce spec time from 4 weeks to 1 week. The same tools that helped the team move faster helped me learn faster. AI isn't replacing the need to understand code—it's making that understanding more accessible. Here's the key insight: AI lowers the floor without lowering the ceiling. You can build real things faster as a beginner, but you still need to understand what you're building. The fundamentals still matter. AI just gets you to them quicker. I'm building real applications: RAG systems, data pipelines, automation tools. These aren't toys. They're production-capable systems that solve real problems. The difference between "I could learn to code" and "I am coding" is just starting.

Let me be clear: I'm not trying to become an engineer. I don't want to be on the critical path for shipping code. I don't want to be the person debugging production issues at 2am. What I want is to be a better partner to the engineers I work with. When I can prototype something quickly, we can align on the concept before investing engineering time. When I understand technical constraints, I write better specs. When I know what's hard and what's easy, I make better prioritization decisions. The best product-engineering relationships I've seen have one thing in common: mutual respect built on mutual understanding. Engineers respect product people who understand technical constraints. Product people respect engineers who understand user problems. Learning to code is how I'm building my side of that bridge.

If you're a product person considering learning to code, here's what I'd say: Start with a real project. Don't do tutorials for months. Pick something you actually want to build and figure out how to build it. You'll learn faster when the problem is real. Use AI generously. Don't treat it as cheating. Treat it as having a patient tutor available 24/7. Ask questions. Get explanations. Use it to move faster. Focus on understanding, not syntax. You're not trying to memorize Python functions. You're trying to understand how software works. The concepts matter more than the specifics. Build things that fail. My first attempts were terrible. They're supposed to be. Every failure taught me something that reading couldn't. Don't set a finish line. "Learning to code" isn't a destination. It's an ongoing process. I'll be learning for years. That's fine—every bit of understanding makes me better at my actual job. The gap between spec and reality is where products fail. I'm closing that gap, one line of code at a time.