What twelve years self-taught taught me about the craft

February 4, 20264 min readBy Harman Kamboj
CareerBuilding in public

I have been a self-taught engineer since I was a kid messing with code at seven, and twelve-plus years of shipping later, the questions I get most are about how you learn without a curriculum and whether it leaves gaps. It does leave gaps, and it also gives you something a syllabus rarely does. The trick is knowing which is which, and not romanticizing the messy path or apologizing for it. Both reactions miss what actually happened.

You learn by needing something

The defining feature of teaching yourself is that you learn things because a real problem demands them, not because they appear on week six of a course. That order is powerful. When I needed to make an indexer keep up with chain data, I learned exactly what the problem required, and it stuck because it was load-bearing. Knowledge attached to a real failure is sticky in a way that abstract study is not.

The downside is obvious. You learn the thing in front of you and skip the thing you did not know you needed. That is how self-taught people end up with surprising holes next to deep expertise. The fix is not to feel bad about it, it is to go looking for your blind spots on purpose once you are honest that they exist.

Fundamentals outlast trends

The biggest thing twelve years taught me is that the durable knowledge is boring and the exciting knowledge expires. Frameworks come and go, but how memory works, how data moves over a network, how a database actually finds a row, those do not change much. The engineers who stay valuable are the ones who went down to that layer at some point, not the ones who only ever learned the framework of the moment.

I have shipped in Go, TypeScript, Node, React, several web3 indexing tools and a pile of game engines, and the reason I can move between them is not that I memorized each one. It is that I understand the ideas underneath, so a new tool is mostly new vocabulary for concepts I already hold. That is the real return on learning fundamentals, and it compounds for decades.

  • Chase the layer beneath the tool, not just the tool
  • A new framework is usually old ideas in fresh syntax
  • Depth in fundamentals makes everything above it cheaper to learn

Building beats consuming

You cannot tutorial your way to competence. I learned more from one broken project I had to fix than from any number of polished courses, because building forces you to confront the parts that videos quietly skip. The gap between watching someone solve a problem and solving it yourself is enormous, and it only closes by getting your hands dirty and being wrong a lot.

This is why I am suspicious of people who collect courses but never ship. The discomfort of a thing not working is the actual teacher. Tutorials feel like progress because they are smooth, but smoothness is the enemy of learning. If you never hit a wall, you are not learning, you are watching.

Game jams taught me this in a compressed form. You have a weekend, a broken idea, and no choice but to figure things out in real time with the clock running. I have run plenty of them and watched newer developers learn more in forty-eight hours of building under pressure than in months of passive study. Constraints force you to make decisions, and decisions are where the learning actually lives.

The self-taught chip on the shoulder

For years I carried a quiet worry that I had missed something everyone with a degree got handed. The reality is more even than that. Formally trained engineers have their own gaps, often around the practical messiness of shipping, and self-taught engineers have theirs, often around theory they never met by name. Neither path is complete, and pretending otherwise just wastes energy.

What twelve years actually settled for me is that the credential matters far less than the habit. The engineers I trust are the ones who are still curious, still willing to be wrong, and still building when nobody is watching. That habit is available to anyone regardless of how they started, and in the end it is the only thing that compounds. Where you began is a footnote. What you keep doing is the whole story.

Building something where this matters?

I am open to senior full-stack, Web3, or AI engineering roles, fully remote and any timezone. If the hard part of your product is fighting you, that is the work I like.

Get in touch →