How To Learn A New Programming Language

The Problem With Starting From Zero Every Time

Most people approach learning a new language the wrong way. They read documentation cover to cover. They watch video tutorials. They copy examples until they feel comfortable. Then they try to build something and realize they understand nothing. I did this with Go in 2019. I spent three weeks reading the official tour and watching Go by Example. When I actually wrote a small HTTP server, I couldn't figure out how context propagation worked across goroutines. The standard library docs assumed I already understood concurrency patterns, and the examples showed them without explanation. It took me two days of reading source code and one very late night staring at a race detector output to finally get it. I could have saved all of that by just building something broken from day one.

How To Learn A New Programming Language

The method is straightforward and it is not exciting. Build a project you actually care about, even if it is terrible. Not a todo app. Not a calculator. Something that solves a minor problem you have. I learned Rust by writing a script that renamed photos in a specific way my camera produced them. The first version crashed because I didn't understand lifetimes. The second version worked but was ugly. The third version was decent. That cycle took about ten days. You will learn more in those ten days than in ten weeks of structured courses. Here is the practical sequence that actually works. Pick your project first. Then open the official documentation and find only the sections relevant to what you need to do immediately. Skip everything else. The reference manual is not a novel. You are not supposed to read it linearly. Use it as a lookup tool, like a dictionary you only open when you encounter a word you don't know. I keep a small set of resources bookmarked for each language I work with. For Python it was usually the docs plus a couple of Stack Overflow threads. For Zig it was the handbook and the stdlib source code. For Nix it was basically just the language reference and a lot of frustration. Each language has a different mental model underneath it, and the documentation reflects that. Python hides complexity. Rust exposes it aggressively. Nix makes you think about evaluation order in a way that feels unnecessary until you hit a caching issue at 2 AM.

The real insight that nobody tells you is that most of what makes you productive in a language is not syntax. It is idioms. Knowing how to write a for loop in Python is trivial. Knowing when to use a list comprehension versus a generator expression versus an explicit loop with a break statement is what separates people who write readable Python from people who write Python that looks like Java. I spent months writing clunky JavaScript before I learned about array methods like reduce and flatMap, and then another few months learning when not to use them because they made the code harder to read. Another thing that catches people off guard is that type systems behave very differently across languages. TypeScript, Rust, and Haskell all have types, but they solve completely different problems. TypeScript types exist to catch mistakes during development. They disappear at runtime. Rust's type system is part of the memory safety guarantee. It affects how you design your program structure from the beginning. If you approach Rust like it is TypeScript with extra steps, you will fight the compiler for weeks. I did exactly that. I kept trying to work around ownership rules instead of restructuring my code to fit them. The workaround was to stop fighting and read the Rust Book chapters on ownership and borrowing twice, then go back and rewrite my project using the patterns it described. You should also know when this approach fails. Building a project from scratch works well for languages you are using for general purpose development. It does not work well for domain-specific languages or query languages where the paradigm shift is so large that you need to understand the theoretical foundation first. Learning SQL by building a web scraper application is a waste of time. You need to understand sets and normalization before writing anything useful. Same goes for Prolog or Mercury. The mental model is fundamentally different and throwing yourself into a project without that foundation usually means you will spend weeks writing code that appears to work but is logically incorrect.

Edge case I ran into recently. I was learning Crystal and needed to handle large binary files efficiently. The Ruby-compatible ecosystem had libraries for everything except what I needed, so I wrote a custom parser using Crystal's C bindings. The problem was that I kept getting segfaults because I was misunderstanding how Crystal handles garbage collection with raw pointers. The workaround was to write a minimal C wrapper around the specific data structure I needed, compile it separately, and then call it through FFI. This added about two days of setup but eliminated the crashes entirely. I wish I had done that from the start instead of spending twelve hours debugging pointer lifetimes inside Crystal's GC. When you are stuck on a concept, switch to reading other people's code in the same language. Look at repositories with significant contributions, not hobby projects. Real code shows you the patterns that documentation never mentions. I learned more about Go error handling by reading the source of popular middleware libraries than I did from any tutorial. The pattern is consistent: errors are values, they are returned explicitly, and you check them at every boundary. This is not obvious from the surface-level examples. Expect to feel lost for the first two weeks. This is normal. The discomfort you feel when reading unfamiliar code is actually the signal that you are learning. If it feels easy, you are probably just reading things you already understand dressed up in new syntax. The productive struggle is the point.

Track your progress by the complexity of problems you can solve, not by the features you have memorized. Can you read someone else's code in this language and understand what it does? Can you write a small utility that handles edge cases without crashing? Can you explain the tradeoffs of the language's approach to memory or concurrency to someone else? Those are the metrics that matter. Everything else is noise.