DEV Community: Henry Anayo

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

Henry Anayo — Tue, 28 Jul 2026 17:05:39 +0000

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.

Building an ASCII Art Generator in Go: What My First CLI Project Taught Me

Henry Anayo — Tue, 30 Jun 2026 08:22:15 +0000

When I started learning Go, I wanted more than just solving coding exercises. I wanted to build something that would force me to understand how different parts of the language work together.

That's how I ended up building an ASCII art generator—a command-line application that converts ordinary text into large, stylized ASCII characters.

At first, it looked like a simple project. It wasn't.

Along the way, I learned about file handling, command-line arguments, error handling, data structures, and the importance of writing clean, maintainable code.

In this article, I'd like to share what I built, how it works, and the lessons I learned along the way.

What is ASCII Art?

ASCII art is text that's arranged to create images or stylized letters using standard keyboard characters.

Instead of printing:

Hello

the program can output something much larger and more decorative using a predefined font stored in a text file.

The application reads these character patterns from banner files and combines them to display the final output.

*Breaking the Problem Down
*
One lesson I learned early was that large problems become much easier when they're divided into smaller ones.

Instead of trying to build everything at once, I focused on individual tasks:

Reading user input.
Loading the correct banner file.
Finding each character's ASCII representation.
Printing each line in the correct order.
Handling invalid input gracefully.

Solving one problem at a time made the overall project much less intimidating.

Go Concepts That Finally Clicked

Working on this project helped several Go concepts make much more sense.

Reading Files

Before this project, reading from files felt abstract.

Now I understood why applications need to read configuration files or other external resources instead of hardcoding everything.

Loading the banner file was one of the most important parts of the project.

Error Handling

Go encourages developers to handle errors explicitly.

Rather than assuming everything would work, I learned to check whether:

the banner file exists,
the user's input is valid,
the selected banner is supported,
and the application can continue safely.

Good error handling doesn't just prevent crashes—it also makes applications much friendlier to users.

Loops

ASCII art is built line by line.

That meant looping over characters, then looping again over each line of every character pattern.

This gave me a much deeper appreciation for nested loops and why they matter in real-world programs.

Maps and Slices

The project also reinforced how useful slices are for storing collections of data and how important indexing becomes when processing structured text.

Instead of simply memorizing syntax, I finally understood why these data structures exist.

Challenges Along the Way

Not everything worked the first time.

Some of the issues I encountered included:

Characters printing out of alignment.
Missing lines in the output.
Incorrect handling of newline characters.
Invalid banner selections.
Debugging logic that looked correct but produced unexpected output.

These moments were frustrating, but they also taught me that debugging is part of software development—not a sign that you're doing something wrong.

Every bug forced me to better understand my own code.

The Biggest Lesson

The biggest lesson wasn't about ASCII art.

It was about thinking like a software engineer.

Instead of asking:

«"How do I write this program?"»

I started asking:

«"How should I break this problem into smaller pieces?"»

That change in mindset made programming feel much more manageable.

What's Next?

Building this project gave me confidence to tackle larger applications.

I'm now exploring backend development with Go while also learning more about cloud technologies and DevOps tools such as Terraform.

Each project teaches something new, and every challenge makes the next one a little less intimidating.

Final Thoughts

Looking back, this project wasn't just about generating ASCII art.

It was about learning how to approach problems, read unfamiliar code, debug patiently, and keep improving one step at a time.

If you're learning Go, don't be afraid to build projects that seem slightly beyond your current ability.

They'll probably teach you more than another tutorial ever could.

Happy coding!