DEV Community: Dhaval_Rasputala

Learning Go the Slow Way: Building Projects Instead of Following Tutorials.

Dhaval_Rasputala — Tue, 28 Jul 2026 03:46:06 +0000

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.

Why tutorials stopped working for me

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.

My new approach: start with a real project

Now I begin with a small project I actually want to build.
Nothing huge—just something manageable, like:

A URL shortener
A simple job queue
A CLI tool that automates something I find repetitive

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.

How I use AI

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:

Create a basic HTTP server.
Add a single hardcoded route.
Create a struct to represent stored URLs.
Store URLs in an in-memory map.
Add a POST endpoint for creating short URLs.
Add a GET endpoint that redirects.
Replace the in-memory storage with a database.
Add expiration support.
Improve validation and error handling.

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.

What I've learned

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.

How I Tackle Blank Days as Beginner Developer

Dhaval_Rasputala — Sat, 25 Jul 2026 11:36:24 +0000

What are "Blank Days"?

My definition of a Blank Day as a beginner programmer is simple: Those days where you just don't feel like doing anything.

My Experience

As a beginner to development, there are days where you don't want to solve that one bug or tackle that one error because it instantly makes you feel exposed—it reminds you that you are a beginner.
I’ve had plenty of experiences with these blank days. To combat them, I put together a basic five-step framework to help shift mindset and instantly salvage a productive workflow.

The 5-Step Framework to Overcome Blank Day:-

1.Check for typos and minor syntax errors.Often, the resistance comes from feeling overwhelmed by a massive architectural problem. Shrink the scope. Look for missing semicolons, misspelled variables, or broken imports. Getting a tiny win builds quick momentum.

2.Step away from the screen for 15 minutes.If staring at the cursor isn't working, force a reset. Walk away, drink a glass of water, or step outside. Do not look at code during this break. Let your subconscious process the problem.

3.Switch to documentation or reading.If writing logic feels impossible, drop down a gear. Read an article, review documentation for a tool you use, or read someone else's code on GitHub. It keeps you in the tech space without the pressure of outputting code.

4.Write the problem out in plain English.Open up a markdown file or grab a physical notebook. Explain the bug or feature out loud or on paper as if you are teaching it to a rubber duck. Stripping away the syntax often reveals the logic gap instantly.

5.Lower the bar drastically.Tell yourself: "I am only going to write one terrible line of code today." The hardest part of a blank day is the friction of starting. Once you break the inertia, you'll often find yourself working longer than expected.

Remember: Hitting a wall doesn't mean you aren't cut out for development. It just means you're human, and you're learning how to problem-solve when things get frustrating.

Conclusion

Blank days used to make me feel like giving up entirely, but realizing they are a normal part of the engineering journey has changed everything.

What about you? How do you handle days when your brain refuses to cooperate with your IDE? Have you tried a framework like this, or do you prefer to just step away and take the day off? Let me know in the comments below!

Building GateKeeper: Designing a Role-Based Access Control Library in Pure Go

Dhaval_Rasputala — Sun, 19 Jul 2026 03:20:56 +0000

As developers, we use authorization libraries almost every day. Whether it's a web application, an API, or an internal tool, we often rely on packages that decide who can do what.

But I realized I had never actually built one.

So instead of using an existing library, I decided to build my own Role-Based Access Control (RBAC) library in Go using only the standard library.

This project eventually became GateKeeper v1.0.0.

Why I Built One

As a beginner in backend development, I wanted to get exposure on how to make public APIs and how to make them work under the hood.
It also made me fight my old syntax habits. Go has strict error handling, which I also learned.
I built it because I wanted to understand the engineering decisions behind public libraries. Instead of watching another tutorial, I built it myself.

Project Goals

Before writing any code, I brainstorm the architecture in my mind.
No external library used, only the standard Go library.
Keeping the public APIs simple and easy to read for developers to use.
Write tests for each and every function, no matter how small.

These constraints forced me to think more carefully about the design instead of depending on external packages.

The Core Model

Engine
├── Users
├── Roles
└── Permissions

Relationships are straightforward:

Users
  |
  V
Roles
  |
  V
Permissions

A user can have multiple roles, and roles can have multiple permissions.
Permissions describe access to a resource and an action.

Designing The API

One thing I learned the hard way is that API design matters more than the implementation itself.
I wanted to keep the library easy to read even without documentation.
The public API ended up looking something like this:

CreateUser()
CreateRole()
CreatePermission()

AssignRole()
AssignPermission()

Can()

DeleteUser()
DeleteRole()
DeletePermission()

RenameUser()
RenameRole()

I had to redesign the API many times before eventually coming up with the final one.
The time spent fighting the design was worth it. It taught me API design and how to think about architecture rather than just implementation.

Bugs I Found Along The Way

One of the most interesting bugs appeared when deleting roles.

Initially, my implementation simply deleted the role.

Delete Role
    |
    V
Role disappears

That looked correct.

Until I realized users still stored that role ID. But the role no longer existed. The system had entered an invalid state.

The correct solution wasn't just deleting the role. It was:

Delete Role
    |
    V
Remove role from every user
    |
    V
Delete Role

The same issue existed when deleting permissions.

That experience introduced me to the idea of maintaining referential integrity, something I had previously only encountered in databases.

Another bug that surprised me, and almost went unseen, was about slices.

Slices in Go point to their backing array, which means if we send a user a copy of User, that user can modify the internal state of the engine, which can cause problems.

The fix was to make defensive copies of the slices before returning them.

That bug taught me more about Go's memory model than several hours of reading documentation.

Lessons I Learned

As a beginner, you are always fighting two battles while learning: one with the programming language, and the other with the architecture you want to create.

By making this project, I not only had to think about correct, production-ready architecture, but also had to learn about Go's underlying structure.

This project made me learn many topics that are important for a beginner, like encapsulation, API design, maintaining invariants, and designing software that remains consistent after every operation.

Final Thoughts

Building software from scratch is a very different experience from using libraries.

You begin to appreciate the small design decisions that make software reliable.

GateKeeper started as an exercise in learning authorization. It ended up teaching me much more about software engineering than I expected.

If you have any suggestions or feedback, I'd be happy to hear them.

GitHub: GateKeeper