12 Rules to Learn to Code: Why Dr. Angela Yu’s Guide Sticks
I picked up Dr. Angela Yu’s “12 Rules to Learn to Code” expecting another generic guide about picking the right programming language. Instead, I found myself reading something that made me uncomfortable because it called out exactly why I’d failed at learning to code three times before. The uncomfortable part? Most of her advice has nothing to do with programming.
The Elephant in the Room: Why Do Most People Quit?
Let me be honest. I’ve started learning to code exactly four times. The first time, I did a Codecademy course and built nothing. The second time, I watched YouTube tutorials about Python. The third time, I bought a $300 course on Udemy. None of it stuck.
I can tell you exactly why: the stuff I was building was boring as hell. I was writing programs to check if numbers are prime. I was making functions to reverse strings. I was solving LeetCode problems that felt divorced from reality. At some point, I’d think, “Why am I doing this? I could Google this answer in two seconds. Why am I wasting my time?”
And I’d quit.
Yu addresses this in her second rule, and it’s the one that actually changed my mind about trying again. She says you have to code for a purpose. You have to build something you actually want to exist.
That sounds obvious when you read it. But it’s radical when you consider how most programming education is structured. Most courses are built around teaching a language or framework, not around building something that matters to you.
The 20-Minute Trick (Why Your Brain is Lazy, and How to Use That Against It)
Here’s the first rule, and honestly, it’s kind of genius. You don’t have to code for hours every day. Just 20 minutes. That’s it. When I read this, I was skeptical. Twenty minutes? That’s nothing. How would I possibly learn to code in 20-minute chunks?
But then Yu explains the real insight: 20 minutes is just enough to get you started without sounding impossible.
Think about your day. You get home from work. You’re exhausted. Every fiber of your being wants to collapse on the couch with Netflix. Your brain is tired. The idea of sitting down to “learn programming” feels like a mountain you have to climb.
But 20 minutes? That’s basically nothing. Even a tired brain can convince itself to do something for 20 minutes.
And here’s where the trick actually works: once you start, you get into it. I’ve sat down planning to code for 20 minutes and suddenly it’s midnight and I’m still going. Not because 20 minutes magically turns into hours, but because once you overcome the initial resistance, your brain gets engaged in the problem. Your resistance collapses.
The second part of this rule the calendar thing sounds stupid until you use it. You get a physical calendar and each day you code, you cross it off. The goal becomes not “learn programming” (vague, impossible to measure) but “don’t break the chain” (concrete, visual).
I’m not making this up. This technique actually works. I’ve used it for everything. The psychological power of not wanting to break a visible chain of days is weird but real.
Code for a Purpose (Stop Wasting Time on Meaningless Projects)
So you’re sitting down to code. But what do you code? Most programming courses will give you arbitrary projects. Build a calculator. Create a to-do list. Make a number guessing game. These projects exist purely to teach you syntax. They’re not things anyone actually wants.
And here’s the problem: your brain knows this. Even a beginner’s brain can sense when something is meaningless. And meaningless work drains your motivation faster than anything.
Yu tells a story about one of her students who built an app that wakes them up one minute earlier each day. This gradually eases the transition to an earlier wake time. It’s a small project, but it solves an actual problem in the student’s life.
Another student built a slideshow app as a Mother’s Day gift. Someone else made a timer for cooking steaks to the perfect temperature based on weight and thickness.
None of these are complex projects. But they’re real. They exist because someone wanted them to exist, not because a course assignment demanded them.
This is when learning actually accelerates. Because now you’re not learning abstract concepts. You’re learning how to solve a problem you actually care about. You’re motivated by something real, not by finishing a course.
When I finally tried this, I built a habit tracker because I wanted to track my own habits. It was simple just a Python script but it was mine. It was something I actually used. That changed everything.
There’s No “Best Language” (And Overthinking This is a Waste of Time)
Every beginner asks this question: “Should I learn Python or JavaScript? What’s the best language to start with?” And every programming course has a different answer, which is part of why beginners spend months researching and zero months actually coding.
Yu’s answer is simple: it doesn’t matter that much. Pick a language based on what you want to build, not on some abstract notion of which language is “best for beginners.”
Want to build websites? JavaScript. Want to build iOS apps? Swift. Want to do data science? Python. Want to build Android apps? Java or Kotlin. The language is a tool, and you pick tools based on the job.
The reason this matters is subtle but important: the core concepts of programming are the same everywhere. Loops work the same way in Python as they do in JavaScript. Variables are variables. Functions are functions. The syntax looks different German and English speakers both have werewolves, just spelled differently but the underlying logic is identical.
Once you understand the core concepts, learning a new language becomes way easier. You’re not learning to code again. You’re just learning new syntax for concepts you already understand.
This single insight stopped me from falling into the “tutorial hopping” trap I’d fallen into before. I’d spent weeks trying to figure out whether to learn Python or JavaScript. After reading this rule, I just picked one and started. The language didn’t matter. Learning to code was what mattered.
What You’re Writing (The “Draw an Owl” Problem)
There’s this internet meme about how not to teach drawing. Someone shows detailed step-by-step instructions for drawing owls. Then suddenly: “Now draw the rest of the owl.” With absolutely no instructions. No guidance. Just the massive leap from beginner to advanced.
Yu has seen this same problem in programming tutorials. They start with meticulous detail. Here’s how to set up your environment. Here’s what a variable is. Here’s how a for loop works. Then suddenly: “Now simply set up a cloud database.”
What? Simply? You just jumped from “variables 101” to cloud infrastructure. There’s nothing simple about that.
And here’s what happens: the beginner copies code they don’t understand. The code kind of works, or it doesn’t work, but either way they learned nothing. The next time they encounter a similar problem in a different context, they’re completely lost.
Yu’s advice: if a tutorial loses you, quit it. Find a different one. There are enough programming resources out there that you shouldn’t waste time on tutorials that jump around or make massive unexplained leaps.
I wasted probably 40 hours on tutorials that had these jumps. I’d be following along, understanding everything, then suddenly the instructor would skip 10 steps or explain something in a way that made zero sense. I’d stop, frustrated, thinking I was too dumb for this. The truth is simpler: the tutorial was bad.
It’s Okay to Not Know Everything (And Everyone Else Doesn’t Either)
There’s this weird mythology around programmers. We imagine them as geniuses who memorize everything, who never need to look things up, who sit down and just… know. It’s completely false. And honestly, it’s one of the biggest things holding people back from learning to code.
Yu tackles this directly. She mentions that about 70% of people experience imposter syndrome, and it’s especially prevalent in programming. There’s this pervasive feeling that you’re not a “real programmer” if you have to look things up.
Meanwhile, actual programmers at Google, Amazon, and other major tech companies are looking things up constantly. They use Stack Overflow. They Google error messages. They read documentation. Not looking things up would actually be less efficient and weirder.
The reason is obvious once you think about it: there’s way too much information to hold in your head. iOS alone has over 800 classes and 9,000 methods. That’s not something any human is going to memorize. And why would you? That’s what computers are for to handle the boring stuff.
What actually matters is your ability to think. To break down a problem. To know where and how to find information. To understand the answer once you find it.
Reading this rule genuinely made me feel better. It gave me permission to look things up without feeling like a failure. And that permission made me more likely to actually keep coding, because I wasn’t constantly beating myself up for not knowing something.
Be a Copycat (Build What Already Exists)
This one seemed counterintuitive at first. “Build something original,” right? That’s what everyone says. But Yu’s advice is almost the opposite: build stuff that already exists. Make your own version of Tetris. Build Flappy Bird. Create a note-taking app. Make Minesweeper.
The logic is practical and smart. When you build something original that nobody’s ever done, and you get stuck, where do you find help? Nobody’s built it before. You’re alone.
But when you build something thousands of people have built before, you can find help for almost every problem you encounter. Someone has solved collision detection for Flappy Bird. Someone has written about how to structure a Tetris game. You’re walking a path that’s been walked a thousand times.
Plus, there’s a psychological benefit I didn’t expect. Building a functional game that you can actually play is genuinely satisfying. You made Flappy Bird. It works. You can show it to someone. That’s a real accomplishment. That feeds motivation for the next project.
I built a simple todo app because I wanted to. But honestly, building my own version of 2048 was more motivating because when I finished it, I had something I could actually play and use.
Be Accountable (Build in Public, Find a Buddy)
The biggest problem with online learning, Yu points out, is that there are zero consequences for not doing the work. You can sign up for a course and never open it. Nobody cares. Nobody checks in on you. Nobody is waiting for you to finish. So you don’t.
It’s not that you’re lazy. It’s that internal motivation is weak compared to external pressure. If I go to the gym alone, I might skip it. If I promised a friend I’d go to the gym with them, I’m much more likely to show up. The same applies to coding.
Yu recommends finding a “coding buddy” someone at roughly your skill level who is also learning. You two check in on each other. You share your progress. You help each other debug. You’re motivated by not wanting to let them down.
If you can’t find a buddy, the principle is the same: make your learning visible. Join an online community. Post your projects. Share your code. This creates a weird social pressure (in a good way) that motivates you to keep going.
She also makes an interesting point about money: free courses have higher attrition rates than paid courses. This isn’t because free courses are worse. It’s because when you’ve invested money, you’re more committed. You’re more likely to actually do the work.
I tested this. I signed up for a free course and did nothing. I paid for a course and actually finished it. The courses were roughly the same quality. The difference was psychological.
Keep Learning (Or Become Obsolete)
Programming is not a stable skill. Languages evolve. Frameworks become outdated. Paradigms shift. Yu warns against becoming like the optical drive technology that couldn’t evolve and got left behind.
There are Fortran programmers who learned in the 1970s and never learned anything else. There are Objective-C programmers who refused to learn Swift, even as Apple explicitly said they were phasing out Objective-C.
The lesson is simple: learning doesn’t stop. It’s not like you reach “programmer” status and you’re done. You have to keep learning to stay relevant.
But here’s the thing: once you understand core programming concepts, learning a new language becomes much easier. You’re not starting from scratch. You’re translating familiar ideas into new syntax.
This rule is less about immediate learning and more about mindset. The best programmers aren’t the ones who became experts in one language in 1995 and never learned anything else. They’re the ones who are always curious, always learning, always willing to become a beginner again.
Step Away From the Problem (Why Staring at Code Doesn’t Help)
This rule sounds counterintuitive: to code better, stop coding. When you’re stuck on a bug, when you’re frustrated, when you’ve been staring at the same problem for two hours the best thing you can do is walk away. Play foosball. Take a walk. Sleep on it. Go watch a movie.
There’s actual science here. It’s called incubation. Your subconscious mind keeps working on the problem even when you’re not consciously thinking about it. And often, when you come back to the problem with fresh eyes, the solution is obvious.
Plus, when you’re frustrated and stuck, continuing to code is usually the worst thing you can do. You’re in an emotional state that leads to bad decisions. You’ll write code that’s messy and hard to debug. You’ll make mistakes you normally wouldn’t make.
I’ve experienced this a million times. I’ll stare at code for hours, unable to figure out why something isn’t working. I’ll take a break, do something else, come back 20 minutes later, and see the problem immediately.
The rule sounds like permission to procrastinate, but it’s actually permission to work smarter. The easiest code to debug is the code you wrote when you weren’t tired and frustrated.
Get a Mentor (And Actually Use Their Brain)
Learning from someone more experienced than you is genuinely irreplaceable. Yu uses pair programming as the model. You and a mentor sit at the same computer. You write the code while they observe and guide. They don’t just give you the answer. Instead, they ask questions that make you think through the problem yourself.
This is way more valuable than just being handed a solution. Because now you’ve learned to think about the problem in a certain way. The next time you encounter a similar problem, you can apply the same thinking.
Where do you find a mentor? Yu recommends local meetups (meetup.com has programming groups in almost every city). But importantly, she says don’t just ask someone “will you be my mentor?” Nobody wants to donate their free time to a stranger.
Instead, offer value in exchange. Maybe you have skills they need. Maybe you can help them with something. Make it a trade. Exchange your time and expertise for theirs.
This actually worked when I tried it. I found a local Python meetup, went to a few meetings, started talking to people. Eventually, I found someone willing to do occasional code reviews with me in exchange for some other help I could provide. It wasn’t formal mentorship, but it was invaluable.
Break Down Complexity (The Chunking Rule)
There’s this problem every programmer faces: the project seems impossible. You want to build Instagram. Or a weather app. Or a productivity tool. And when you really think about it, the whole thing is so enormous and complex that you don’t even know where to start.
The solution is chunking. Break the massive problem into smaller problems.
Yu uses the example of a robot that butters toast. The whole task is incredibly complex. But you break it down: (1) position the toast properly, (2) acquire the butter, (3) apply butter with decent coverage.
Then each of those gets broken down further. And suddenly, instead of one impossible problem, you have five or six manageable problems.
The same applies to programming. Your Instagram clone is impossible. But user authentication is doable. Photo upload is doable. Feed display is doable. Like system is doable. Break it into chunks and suddenly it’s not so terrifying.
Plus, there’s a psychological benefit: as you solve each chunk, you get small wins. Each win is motivating. You make visible progress. This is way better than staring at a vague, enormous goal for weeks.
Learn From Other People’s Code (Don’t Just Copy-Paste It)
The final rule brings everything together: how to actually learn from code that already exists. When you find a solution on Stack Overflow or GitHub, the easy path is to copy it, paste it, and move on. But Yu argues this teaches you almost nothing. The moment you hit a similar problem in a different context, you’re helpless again.
Instead, she recommends a process:
- Copy and paste the code
- Verify it actually solves your problem
- Delete the code line by line
- Each time you delete something, check what breaks
- Really test your assumptions about what each line does
- Rearrange lines to see if order matters
Through this process, you understand not just what the code does, but why it works the way it does. You learn to think, not just to copy.
The advanced version is reverse engineering. Find a well-built project on GitHub. Study it. Understand how it’s structured. Then build something similar from scratch. Compare your code to theirs. This teaches you architectural thinking.
I did this with a simple todo app that someone published. I studied it for hours. Then I built my own version from scratch without looking at their code. When I compared mine to theirs, I saw so much I’d done less efficiently. That learning was worth way more than just copying their code would have been.
What This All Actually Means
Here’s what struck me about reading these 12 rules: almost none of them are about programming. There’s no mention of data structures. No design patterns. No explanation of algorithms. No discussion of object-oriented programming or functional programming. Nothing about memory management or optimization.
It’s almost entirely about the psychological and behavioral side of learning. And that’s kind of the point. The syntax you can learn in a week if you need to. The concepts you can pick up as you go. But if you quit before you ever get good enough to see those things, it doesn’t matter how well they’re taught.
The real barrier isn’t technical knowledge. It’s showing up. It’s staying motivated. It’s pushing through the frustration. It’s building confidence. It’s finding community. It’s understanding that you’re not alone in not knowing things.
Most programming courses completely ignore this side. They assume you’ll somehow stay motivated on your own. They assume you’ll be fine with building boring practice problems. They assume you’ll understand everything immediately.
These are terrible assumptions.
Yu’s rules address the actual barriers. And that’s why they work for people who have tried and failed before.
Who Should Actually Read This?
If you’ve tried learning to code before and quit, read this. If you’re thinking about learning but worried you’re not smart enough, read this. If you’re in a bootcamp and struggling, read this. If you’re just looking for a technical guide to Python syntax, you can skip it. There are plenty of other resources for that.
But if you’re looking for a realistic, practical guide to actually learning to code and sticking with it, this is worth your time.
The book is short. You can read it in an afternoon. And unlike most programming books, you’ll actually remember it, because the lessons stick with you in a way that technical knowledge doesn’t.
I’m still learning to code. But I’m actually coding now, regularly, and building things I want to build. The shift didn’t happen because I found a better tutorial or a better language. It happened because I changed my approach. These 12 rules are the map for that approach.
