I Taught Myself to Code. Here's What It Did to My Brain.

I was not a technical person.

I say this not as a qualification or a modest caveat. I mean it literally. I had no programming background. I'd spent my career in finance and capital markets. I understood systems — business systems, capital systems, decision systems — but I understood them from the outside. I had no idea how software was actually built.

Then I decided to build NUVC.

Not to hire someone to build it. To build it myself. An AI-native venture capital intelligence platform. Eight autonomous agents. Thirteen intelligence layers. A scoring engine trained on 172 real VC deal memos. A database covering 7,900+ investors across 35 countries.

I did not fully understand what I was committing to.

Why I Decided to Build It Myself

Part of the reason was practical: I couldn't afford to pay for the team that would have been required to build what I had in mind. And the more I thought about it, the more I believed that an investor who evaluates AI companies should probably understand how AI systems are actually built.

But the deeper reason was something closer to compulsion. I had a clear picture in my mind of what NUVC should do — how the agents should reason, how the intelligence layers should interact, what the output should feel like. Handing that picture to someone else and hoping they'd translate it faithfully felt like an abdication of something I couldn't quite name.

So I learned to code. And then I learned to build machine learning pipelines. And then I learned how large language models work from the inside — not just as API calls, but as systems with specific failure modes and specific strengths.

The process took longer than I want to admit. It was more uncomfortable than I expected. And it changed how I think in ways I didn't anticipate.

What It Was Like at the Beginning

Terrible, mostly.

The learning curve for programming is not a curve — it's a cliff followed by a plateau followed by another cliff. For the first three months, I couldn't write code that did anything useful. I could follow tutorials. I could replicate examples. I couldn't build anything that wasn't already in a tutorial.

The specific experience was a kind of cognitive vertigo. I knew what I wanted the system to do. I had a clear conceptual model of the architecture. And I could not bridge the gap between the model in my head and the code that would realise it. That gap felt enormous in a way that was hard to explain to people who weren't in it.

What I didn't know then: that gap is normal. The gap between the conceptual model and the implementation is where programming actually lives. Getting comfortable in that gap — learning to work productively in the space between what you understand and what you can build — is the real skill.

I didn't know that for months. For months, I just felt stupid.

The Cognitive Shift

Something changed around month four or five. I'm not sure exactly when.

I started thinking in systems differently. Not just conceptually — which I'd always done — but mechanically. I developed an intuition for how components interact, where state lives, what happens when you change one thing and why it breaks something three layers away.

This is the thing about programming that nobody told me: it's not primarily about syntax or even logic. It's about building a mental model of an invisible system and then reasoning clearly about what happens to that system under different conditions.

Once I could do that — once the mental model became more reliable — the gap between conception and implementation started to shrink. Not disappear. But shrink.

The other shift: I developed a completely different relationship with "I don't know." Before coding, "I don't know" was a destination. Something was unknown. Now "I don't know" is a starting point. It means: I need to isolate the specific thing I don't understand, figure out where to find the information, build the mental model, and test whether the model predicts the right behaviour.

Debugging taught me this more than any other practice. A bug in a complex system is an invitation to think clearly about what you believe is happening versus what is actually happening. That discipline — that specific rigour about the gap between your model and reality — turns out to be useful everywhere.

What Changed About How I Evaluate Companies

Learning to build changed how I read pitch decks. Not in subtle ways.

I can now ask a founder to describe their technical architecture and understand whether the description is plausible. I can identify the point where a "technical moat" slides from genuine defensibility to complexity theater. I can tell the difference between a product that works in a demo environment and one that works under real conditions, because I've built things that only worked in demo environments.

I ask different questions. Not "is your technology defensible?" but "walk me through what happens when a user does X and the system responds with Y — specifically, mechanically, what's happening?" The answer to that question — its specificity, its comfort with the details — tells me something important about the quality of execution underneath the pitch.

The NUVC research finding that product execution quality is the strongest predictor of investment outcomes (r²=0.77) is not just a data point for me. It's a finding I can feel. I know what good product execution looks like from the inside. I know what the gap between vision and execution feels like. I know how easy it is to describe a product that doesn't quite exist yet as if it does.

The Part Nobody Talks About

There's a particular kind of loneliness in teaching yourself a technical skill as an adult.

You're surrounded by people who either learned this twenty years ago (and have forgotten what it was like not to know) or who learned it in school (and have a completely different relationship with the learning curve). The community is built around people who have already arrived. The journey from non-technical to technical adult is poorly documented and under-discussed.

I spent a lot of time feeling like I was the only person who found this as hard as I found it. I wasn't, of course. But the internet mostly shows you either beginners' tutorials or experts' documentation. The messy middle — the months of productive-feeling work that doesn't produce anything yet — is mostly invisible.

If you're in that middle right now: it's real, it ends, and what's on the other side is different from what you expect. Not easier, exactly. Just different. You have a relationship with problems that you didn't have before.

What I Would Tell Myself

Start with the smallest thing that does something real. Not a tutorial. A small, real thing. Something you actually want. The motivation to make the real thing work carries you through the parts that would defeat you if you were only doing it as an exercise.

Accept that you will be wrong about what's hard and what's easy. I expected the coding to be hard. The coding was hard. I did not expect the debugging to be where I learned the most. Debugging is where you develop your relationship with your own assumptions.

Build something no one has asked you to build. The accountability of a real project — where you are the only person who cares whether it works — is different from the accountability of coursework. The NUVC system needed to actually work. That need was clarifying in a way that exercises aren't.

And be patient with the gap. The gap between the concept and the implementation is not a failure of intelligence. It's the actual work. Every technical person lives there. You just haven't moved in yet.

---

Related: What Solo Founding Actually Feels Like — the companion piece on the psychological reality of building alone. Why I'm Betting on AI-Native Venture — on how building NUVC changed how I think about every company I evaluate.

Tick Jiang is the technical co-founder of NUVC (nuvc.ai), an AI-native venture capital intelligence platform built in Melbourne. She writes on capital, building, and the long game.