What I Wish I Knew Before Learning to Code

I started learning to code in 2024, in my first year of a Computer Science degree with an AI/ML specialization. Two years later I still think about that first stretch a lot; not because it was inspiring, but because almost everything I believed about learning to code in month one turned out to be wrong in some specific, useful way. This isn't a motivational post. It's the list I wish someone had handed me, unglamorous parts included.

The First Month Will Lie To You

The first month is confusing in a way that doesn't feel like normal confusion; it feels like evidence that you're not cut out for this. You follow a tutorial, your program prints "Hello, World", and for a second it feels like you understand something. You don't, not yet. You've pattern-matched your way through someone else's steps, and the gap between recognizing code and producing it is the actual wall almost everyone hits and nobody warns you about.

Tutorials are especially good at manufacturing that false confidence, because they're designed to. Every step works, every example runs, and the instructor already knows which mistakes to avoid making on camera. Close the tutorial and try to build the same thing from a blank file, and the fluency evaporates, not because you weren't paying attention, but because following isn't the same skill as producing, and no amount of watching closes that gap.

Beat FOMO

There's a specific kind of FOMO that hits early: the sense that you need one more course, one more framework, one more "fundamentals" video before you're allowed to actually build something. I fell for this for longer than I'd like to admit, bookmarking things, half-finishing courses, always preparing to start instead of starting.

The fix wasn't discipline, it was lowering the bar for what counted as "starting." A project doesn't need a clean architecture or a finished feature set to be worth building; it needs to exist, badly, so you have something real to be confused by instead of an abstract feeling of not knowing enough yet.

Motivation Is A Spark, Systems Are The Engine

Motivation got me to open the editor a handful of times. It never once got me through the boring middle of a project; the part after the idea is exciting but before anything works. What actually got projects finished was smaller and less interesting than motivation: showing up on a schedule regardless of whether I felt like it, and treating a bad day of output as still better than no day of output.

This sounds like a cliché until you've lived the alternative a few times, starting a project on a burst of enthusiasm, hitting the inevitable wall a week in, and watching it die because there was no system underneath the motivation to carry it through. Consistency is unglamorous. It's also the only thing that has ever actually worked for me.

You Don't Need Math To Start

I spent real time worried I needed to be "good at math" before any of this would make sense, which mostly just delayed starting. Most early programming work is closer to careful reading and pattern recognition than it is to mathematics; you need the math when you actually get to the algorithms and machine learning coursework that specialization implies, not before you're allowed to write your first program.

What actually taught me more than any theory-first approach was debugging, sitting with a program that's wrong and figuring out exactly where and why, one hypothesis at a time. Watching someone else debug on video teaches you their process. Debugging your own broken code teaches you how to think, because there's no script to follow and no one else's intuition to borrow. It's slower and far more frustrating than watching a video, and it's also where most of the real learning happened for me.

Code Reviews Teach Faster Than Courses

Nothing accelerated my growth faster than having someone else actually look at code I'd written and tell me, specifically, what was wrong with it. A course tells you the right way to do something in the abstract. A code review tells you the specific way your code, the one you actually wrote, falls short, which is a much sharper kind of feedback because it's about a real decision you made, not a hypothetical one.

The other habit that quietly compounded was reading documentation instead of only searching for the answer. Documentation is slower up front and far more useful long-term; it tells you not just how to solve today's problem but the shape of the whole tool you're using, so the next ten problems get easier instead of requiring ten more searches.

AI Is A Power Tool

I started learning to code at a point where AI assistance was already normal, and I think that's a genuinely different experience than the one people had five years earlier. Used well, it's a real accelerant; it can explain an unfamiliar error, suggest an approach, or save you the twenty minutes of syntax-lookup that used to interrupt actual thinking.

The distinction I try to hold onto is between using AI to move faster through work I already understand, versus using it to skip understanding entirely. The first is leverage. The second just delays the moment you actually have to learn the thing, usually to a worse moment than now.

The Dunning–Kruger Curve Is Real

There was a point, a few months in, where I felt genuinely capable, I'd finished a couple of small projects, things worked, and it was tempting to believe the hard part was over. It wasn't. Every real project since has surfaced a category of problem I didn't know existed the month before, and I've come to expect that as the actual shape of this work rather than a sign I'm behind.

Learning to code doesn't have an ending where you arrive and the confusion stops. It has a rhythm: build something, get confidently wrong about some part of it, get corrected (by a bug, a reviewer, or just time), and recalibrate. Two years in, that rhythm hasn't slowed down. I've just gotten less afraid of it.

If there's one thing I'd tell the version of me who started in 2024, it's that the confusion isn't a signal to stop. It's the actual process, and it never fully goes away; it just moves to more interesting problems.