I Had Zero Programming Experience. Two Months Later, I Built My First Real-World Solution.

Two months ago, I couldn't explain what a variable was.

Today, I'm writing backend code in Go, working with APIs and databases, using Git, Docker, and PostgreSQL, and recently spent 48 hours building a solution to a real environmental and economic problem.

The journey between those two points has been messy.

And that's exactly what I want to talk about.

The Beginning

When I joined Zone01 Kisumu, I didn't come in with years of programming experience.

I came in as a complete beginner.

I had to learn things that many developers consider basic:

• What is Git?
• What exactly does git push do?
• Why isn't my code compiling?
• What's the difference between compile-time and runtime?
• What is an API?
• Why can't my application connect to PostgreSQL?
• Why does my code work on my machine but fail somewhere else?

Sometimes, I spent hours trying to solve what seemed like a tiny problem.

At the time, it was frustrating.

Looking back, those problems were some of the most valuable things I could have experienced.

Because I wasn't just learning syntax.

I was learning how to think.

Learning Go

My first serious programming language has been Go.

At first, it felt strange.

I had to understand variables, functions, loops, pointers, structs, packages, interfaces, error handling, and a lot more.

Then came the projects.

I worked on exercises that forced me to actually understand what I was writing instead of simply copying code.

One of the biggest lessons I learned was this:

Knowing the syntax is not the same as knowing how to solve problems.

You can memorize a programming language and still struggle to build something.

The real skill is learning how to break a big problem into smaller problems.

That changed the way I approached programming.

Then Came the Real Problems

Things became more interesting when I started working on backend projects.

Suddenly, I wasn't just writing isolated functions.

I had to think about:

• APIs
• Authentication
• Databases
• PostgreSQL
• Migrations
• Environment variables
• Docker
• Git workflows
• Project architecture

And then came the errors.

A lot of errors.

My application couldn't connect to PostgreSQL.

Git rejected my push.

Migrations conflicted.

The compiler complained.

Packages were missing.

Sometimes I fixed one problem only to create another one.

But every error forced me to understand something I didn't understand before.

Eventually, I reached a point where I could start a backend server, connect it to PostgreSQL, create endpoints, and actually see the pieces working together.

That feeling was incredible.

Not because the application was perfect.

But because I knew how far I had come.

The 24-Hour Challenge

Recently, I participated in the KijaniSpace Hackathon, a 24-hour challenge that pushed us to think beyond code.

Our team worked on a problem affecting Lake Victoria: declining fish populations, unpredictable catches, pollution, and the spread of water hyacinth.

We wanted to explore how technology could help address these challenges.

Our idea was to combine different sources of information:

• IoT sensors for real-world environmental data
• Copernicus data for satellite-based observation
• AI to help analyze information and provide actionable recommendations

The goal was to continuously observe the lake, detect environmental changes as early as possible, and help stakeholders make better decisions.

The solution wasn't just about building an app.

It was about asking:

Can technology help us understand what's happening in our environment before the problem becomes too big to ignore?

That question made the project meaningful to me.

And after 24 hours of building, debugging, discussing, changing ideas, and probably questioning our life choices a few times...

We finished 3rd.

That was a huge moment for me.

Not because I suddenly became an expert.

But because it showed me that even someone who started with zero programming experience can contribute to solving real-world problems with technology.

What I'm Learning

My biggest lesson so far is that becoming a developer isn't about knowing everything.

It's about becoming comfortable with not knowing.

I still Google things.

I still ask questions.

I still get stuck.

I still encounter errors that make absolutely no sense to me at first.

But now, instead of seeing an error as proof that I can't code, I see it as a problem that I haven't solved yet.

That's a very different mindset.

I'm also learning that software development is much bigger than writing code.

It's about understanding people.

Understanding problems.

Working with a team.

Communicating ideas.

Making decisions with incomplete information.

And turning an abstract idea into something that can actually be used.

What's Next?

I'm still at the beginning of this journey.

I'm currently learning more about backend development, databases, APIs, Git, Docker, and software architecture.

My goal is to become a full-stack developer and eventually build production-grade applications that solve problems that actually matter.

I also want to keep exploring the intersection of technology with areas I'm passionate about, including music, entertainment, and the creative economy.

I don't know exactly where this journey will take me.

But I know one thing:

A few months ago, I couldn't write a program.

Today, I'm building.

And tomorrow, I want to build things that matter.

If you're also starting your programming journey and feel like you're too far behind, here's what I'm learning:

You don't need to know everything before you start.

Start.

Get stuck.

Break things.

Ask questions.

Fix them.

Build again.

That's how you become a developer.

And this is only the beginning of my story.