How to Learn Programming - Geohot

The only advice I have for learning programming is go program.

After watching so many programming channels and articles, I still think Geohot puts it most incisively. There’s a knack to it, and once it’s said plainly it’s not worth much—you won’t suddenly become stronger just by watching videos, and you won’t suddenly have an epiphany and become a developer just because you have AI assistance either (although making good use of AI can definitely speed up the process). You have to start writing code.

This line comes from a clip of his appearance on the Lex Fridman Podcast. The full podcast is three hours long and well worth watching in its entirety.

Who is Geohot

In short: he cracked the PS3 key and got sued by Sony, and he also cracked the iPhone, making it possible for the iPhone to run on networks other than AT&T. In recent years, he has been working on self-driving software comma.ai and the deep learning framework tinygrad (you can think of it as PyTorch). tinygrad started as a small project he launched while streaming on Twitch, with the goal of writing a practical deep learning framework in under 1,000 lines of code. You can find recordings of the streams on YouTube, or go straight to GitHub to look at the code.

I plan to write a separate post introducing more of his accomplishments.

What language should you learn

Geohot recommends the order C, Assembly, Python, followed by three extension tracks:

1. Functional Programming. For example, Haskell, to understand the world of pure functions. He himself once wrote a simple Scheme interpreter in Haskell. Writing an interpreter helps you understand how a programming language is turned into something a computer can actually execute. For details, you can check out his stream archive.

2. Verilog or other HDL languages, to understand the world of hardware. Hardware and software are two completely different mental models. Geohot previously started a repository called fromthetransistor, where he outlined a plan to build a simple browser starting all the way from transistors. Conceptually, it is very similar to From Nand To Tetris.

3. Deep Learning, such as PyTorch. His approach is to read papers directly, then figure out how to implement them in tinygrad. This is actually the most effective way to learn deep learning—otherwise, many engineers just wrap existing frameworks, tweak a few parameters, and have no idea about the underlying principles at all.

First understand how the underlying layers work: how C is compiled into assembly, and how assembly naturally leads you to core computer architecture concepts like stack, heap, CPU, and RAM. Once you understand those, you’ll start to appreciate everything Python gives you.

What you can learn from his streams

There are tons of gems to be found in Geohot’s streams.

Most of his streams at the time used Vim (he later switched to VS Code after discovering how good VS Code is). He types and thinks extremely fast—so fast that you can really feel how fluent he is with Vim, and how he approaches problems when they arise.

I never used to care about typing speed, nor did I pay special attention to whether my hands stayed on the keyboard, but this matters more than I expected: if you’re not fast enough, your thinking can easily get interrupted. This interview was from before LLMs could replace day-to-day development, so handwritten coding was still the norm; that said, Geohot’s more recent streams also involve less manual typing, and he has switched to Opencode.

His debugging style is also worth studying. Even at a god-tier level, when engineers run into problems they still look up syntax and read documentation—there’s no secret trick. In the streams, you can see a lot of trial and error: add a log here, add a log there, see what happens. Simple, but effective. He tries to keep the code as simple as possible, writing a small piece and validating it immediately instead of writing a huge chunk and only then running it, which leaves you with no idea where to start when something breaks.

Over the years, he has accumulated quite a few projects; if you’re interested, you can dig around on a YouTube channel that archives his work.

Why are people like this so rare

Recently, I’ve also noticed that quite a few engineers haven’t written much functionality yet, but are already shouting about DDD, wanting to use the latest frameworks, saying state management A isn’t enough and they need to stack B and C on top, and constantly talking about refactoring—yet their idea of refactoring is just wrapping a lump of code into a function and moving it somewhere else. By the time the features are still unfinished, the project has already become too complex to change.

Because of the nature of frontend development, writing web pages without a bundler is indeed a bit restrictive (though still possible), but in many cases you really don’t need so much fancy packaging to build a project.

Geohot once half-jokingly said that as long as you can send him a high-quality pull request, he doesn’t care whether you’re a human or a monkey—and he’d even be fine paying your salary in bananas.

In my ten-year career, I’ve worked with dozens of engineers who had fairly deep understanding in their respective domains, but I’ve only met one who also understood the underlying layers thoroughly. Working with someone like that, your perspective on problems, the direction of debugging, and your tolerance for “complexity” are all obviously different from those of the average engineer.