The first time I attempted to understand a published algorithm for market microstructure, I was lost. The notation was foreign. The assumptions weren't obvious. The implementation details were buried in academic shorthand. I had no formal training to fall back on, and that was the best thing that could have happened to me.
Being self-taught in hard tech forces you to develop a learning system. You can't memorize your way through. You have to understand the why—the underlying structure that makes the algorithm work. This essay is about that learning system, and how to build it.
The Three Layers of Understanding
Most people try to learn hard tech in one step. They read a paper, or a textbook chapter, and expect comprehension. Then they're confused, and they give up. The mistake is assuming you can jump from zero to mastery in one bound.
Real learning happens in three discrete layers:
Layer 1: Pattern Recognition. You're not trying to understand the algorithm—you're trying to recognize its shape. What inputs does it take? What outputs does it produce? What constraints does it assume? This layer is about building a mental model of the problem domain, not solving the problem.
For example, when I first encountered feedback loops in trading systems, I didn't try to derive the math. I tried to answer: When do systems with feedback become unstable? What does that instability look like? What patterns predict it? This took weeks of reading, sketching, and failed experiments. But I built the shape of the problem in my head.
Layer 2: Mechanistic Understanding. Once you know the shape, you study how it actually works. Why does this algorithm work for this class of problems but fail for that class? What are the failure modes? What are the trade-offs?
This layer requires you to implement it. Reading about an algorithm is not understanding it. You have to code it, run it, watch it fail, and fix it. Only then do you understand why each step exists.
Layer 3: Mastery and Innovation. After you've built the system, you ask: How could I make this better? What assumptions could we relax? Where are the hidden costs? This is where you start making original contributions—not from intuition, but from deep understanding.
Most people never reach layer 2. They stay in pattern recognition and assume that's understanding. That's why most online courses don't produce practitioners—they optimize for layer 1 and call it learning.
Your Core Learning Tools
Without a formal classroom, you need to build your own structure. Here are the tools that work:
Tool 1: Implement Everything. Not theoretically. Not in pseudocode. In production code. Make it run. Make it fast. Make it correct. The implementation is where you discover whether you actually understand the algorithm or just think you do.
When I first studied signal processing, I didn't just read about the Fast Fourier Transform. I implemented it from scratch. I timed it. I compared it against NumPy's implementation. I profiled it. Only after I could explain why my version was slower (and in which ways) did I understand FFTs. The book couldn't teach me that. Only implementation could.
Tool 2: Study Published Code. Not tutorials. Not documentation. Read actual production systems that solve problems you care about. Understand why they made the architectural choices they did. This is your peer group, even if you never meet them.
When learning distributed systems, I didn't read a textbook. I read the source code of systems that had to solve distribution problems. How did they handle consistency? Latency? Fault tolerance? Why did they make different choices than other systems? Reading code is slow, but you're learning from experts who had to ship.
Tool 3: Build Toy Systems. Before you build anything real, build simplified versions that teach you the core concepts. Write a distributed cache system to understand caching. Write a simple optimizer to understand optimization. These toy systems are your laboratory.
The toy system lets you fail safely. You can make mistakes, hit the limits of a naive approach, and learn what constraints force architectural choices. Then when you build the real system, you're not discovering architecture for the first time—you're optimizing something you already understand.
Tool 4: Measure Everything. You need empirical feedback. When you don't have professors grading your work, metrics become your teacher. Latency. Accuracy. Stability. Throughput. Failure modes. Every system you build, you measure it obsessively.
This measurement is how you detect when your understanding is incomplete. You built the algorithm correctly, but it's slow? That tells you something about the bottlenecks. It's inaccurate under certain inputs? That tells you about hidden assumptions in the algorithm.
Navigating the Knowledge Gaps
Self-taught engineers have blind spots. You might be expert in systems but weak in theory, or vice versa. You might miss entire domains you don't know exist.
The antidote is intentional breadth. Read surveys across domains adjacent to your work. Listen to talks by people doing different things. Read papers that aren't directly relevant. The purpose isn't to become an expert in everything—it's to know what you don't know.
When you encounter a concept you're unfamiliar with, you have a choice: go deep or mark it and move on. Most concepts can wait. But if you encounter the same gap three times, it's probably important. That's your signal to invest in understanding it properly.
Example: I was weak in statistical testing early in my career. I'd build systems, measure them, but I wasn't rigorous about whether differences were significant or noise. This gap appeared repeatedly: in algorithm comparisons, in A/B tests, in strategy selection. When it appeared the third time, I invested in learning statistics properly. It made me better at every subsequent project.
The Pacing Problem
Self-taught learning is self-paced, which is a double-edged sword. You move fast on things you care about. You stall on things that are frustrating.
The fix is external structure. Find collaborators who will hold you accountable. Code review forces clarity. Questions force you to articulate what you know. Publishing forces precision. Set milestones. Measure progress.
I kept logs of what I learned, what I implemented, and what I measured. This log became evidence of progress when I felt stuck. It also became a reference—I could look back and see: in three months of focused learning, here's what actually stuck.
Credibility Without Credentials
The hardest part of being self-taught is proving competence to others. You don't have a degree. How do people know you're legitimate?
The answer is simple: ship working systems. Write about what you've learned. Open-source subsystems that solve real problems. Submit your work for peer review. Over time, your work becomes your credential.
This is actually better than a degree. Anyone can get a diploma. Not everyone can build systems that work under production constraints. Your code is evidence of your competence in a way a transcript never can be.
What Actually Matters
Looking back, the things that mattered most weren't the books I read or the courses I took. They were:
- Solving real problems. Not toy problems. Problems where failure had real cost.
- Feedback loops. Measurement, code review, peer feedback, published criticism.
- Time and focus. Deep learning takes time. You can't rush it.
- Breadth with depth. Understanding how your specialty connects to adjacent fields.
- Documented learning. Writing forces clarity. Journals capture progress.
The hard tech world needs more self-taught engineers. Formal education is expensive, takes years, and often teaches outdated material. Self-taught engineers who build systems, measure obsessively, and learn from evidence often move faster and deeper than credentialed peers who stopped learning after graduation.
Your lack of a degree isn't a weakness if you have a system for learning and evidence of competence. Build that system. Ship working code. Let your work speak.