Like a lot of beginners, I started learning Go the usual way: tutorials, courses, and coding along with someone who had already solved every problem. It felt productive. I finished lessons, learned the syntax, and everything seemed to make sense.
Then I tried building something on my own.I had no idea where to start.
That was the point where I changed my approach. Instead of following tutorials, I started building small, messy, imperfect projects. I still use AI, but not to generate the code for me. I use it as a guide that helps me think through the problem.
Tutorials are great for introducing concepts and showing that something works. What they don't teach very well is how to make decisions when you're on your own.
When you're following along, someone else has already decided how to organize the project, what to name things, how to structure the packages, and how to solve the tricky parts. You learn what to type, but you don't get much practice deciding why to do it that way.
I could finish a tutorial and still struggle to build a simple API from scratch. That was a clear sign that I wasn't actually learning how to solve problems.
Now I begin with a small project I actually want to build.
Nothing huge—just something manageable, like:
The goal isn't to build an impressive portfolio piece. It's to build something that's mine, where every design decision is one I have to make myself.
The problem, of course, is that starting from a blank page can be overwhelming when you're still learning.
That's where AI has become genuinely useful.
I don't ask AI to build the project.
Instead, I ask it to break the project into small, testable milestones.
For example: "I want to build a basic URL shortener in Go.Break this project into small steps, where each step is one feature I can build and test before moving on."
The response usually looks something like this:
The exact steps aren't the important part.The Order is.
Each milestone is small enough that I can build it, understand it, test it, and only then move on. I still write the code myself. I still get stuck. I still read documentation and debug my mistakes.
The AI simply helps me avoid feeling overwhelmed by turning one big project into a series of achievable problems.One rule: don't skip ahead
I've made one rule for myself: Don't move to the next step until the current one works and I understand why it works.That has made a much bigger difference than I expected.
Building projects has taught me things that tutorials never really did.
Goroutines and channels only clicked after I introduced a real concurrency bug into my own project and had to figure out why it happened.
Error handling stopped feeling like repetitive boilerplate once I experienced how a single ignored error could break an entire feature.
Package structure became much more intuitive because I had to make those decisions myself, realize where I'd gone wrong, and refactor instead of copying someone else's layout. Those lessons stuck because they came from solving my own problems rather than watching someone else solve them.
Still learning,I'm not writing this as someone who's mastered Go.
I'm only a few projects into this approach, but it's already helped me understand the language more deeply than tutorials ever did.
It's definitely slower.
You'll spend more time stuck, debugging, and reading documentation.
But for me, that's exactly where the learning happens.
If tutorials haven't been sticking for you, try picking one small project, breaking it into tiny milestones, and refusing to move on until each one genuinely works. I'd also love to hear how other people learned Go. If you've found an approach that worked well, let me know.