DEV Community: MANZI RURANGIRWA Elvis

Building SignalHQ: Engineering a Production-Grade Incident Management Platform from Scratch

MANZI RURANGIRWA Elvis — Sun, 26 Jul 2026 15:59:55 +0000

Most portfolio projects stop after implementing authentication and CRUD operations.

Production software doesn't.

Engineering teams need systems capable of handling operational failures under pressure. During an incident, dozens of engineers may collaborate simultaneously, permissions must be enforced correctly, every action must be recorded, and changes must propagate instantly across every connected client.

SignalHQ was built to explore those engineering challenges.

Instead of another task manager, the project focuses on modeling how modern organizations manage production incidents from detection to postmortem.

Modeling the Incident Lifecycle

One of the first architectural decisions was to treat an incident as a state machine rather than a collection of arbitrary status values.

Instead of allowing any transition, every change must follow predefined business rules:

Open
 ↓
Investigating
 ↓
Identified
 ↓
Monitoring
 ↓
Resolved
 ↓
Postmortem

Centralizing these rules inside a dedicated state machine eliminates duplicated logic, simplifies testing, and prevents invalid transitions from occurring anywhere in the application.

Authorization Beyond User Roles

Many applications stop at role-based permissions.

SignalHQ goes one step further.

Changing an incident's severity requires the appropriate role, while resolving an incident additionally requires ownership of that specific incident.

This combination of:

Authentication
Role-based authorization
Resource ownership creates layered security that closely resembles production systems.

Separating Operational History from Security History

SignalHQ intentionally maintains two independent historical records.

Incident Timeline

Records operational activity:

Comments
Status changes
Severity changes
File uploads

Audit Log

Records security-sensitive actions:

Login attempts
Permission changes
Escalations
Administrative actions

Separating these concerns keeps operational history useful for responders while providing administrators with an immutable security trail.

Real-Time Collaboration

Engineering incidents evolve rapidly.

Refreshing the browser every few seconds isn't acceptable.

SignalHQ uses authenticated Socket.IO connections to broadcast updates after database transactions complete successfully.

Every connected engineer immediately receives:

Status changes
Timeline updates
New comments
Attachments
Severity changes

The server remains the single source of truth - WebSockets never modify application state directly.

Search That Scales

Searching production incidents becomes increasingly expensive as data grows.

Instead of relying on:

ILIKE '%database%'
SignalHQ leverages PostgreSQL's native full-text search capabilities:

tsvector
GIN indexessq
Database triggers

The result is significantly faster searching while keeping indexing responsibilities inside the database rather than application code.

Building for Maintainability

Throughout development, the primary objective wasn't adding features - it was reducing future complexity.

The backend is organized into isolated modules with dependency injection, DTO validation, migrations, and reusable guards.

This makes individual components independently testable while allowing the application to evolve without accumulating tightly coupled code.

Lessons Learned

Building SignalHQ reinforced several software engineering principles:

Architecture matters more than frameworks.
Authorization is more nuanced than checking user roles.
State machines simplify complex workflows.
Real-time systems should remain server-authoritative.
Search should leverage database capabilities instead of application code.
Auditability is a first-class feature in production software.

SignalHQ demonstrates that production-ready applications aren't defined by the number of features they contain, but by the quality of the engineering decisions behind those features.

Live Site

Building a Movie Platform with Next.js and TMDB API

MANZI RURANGIRWA Elvis — Fri, 12 Jun 2026 08:34:50 +0000

As part of my journey toward becoming a better full-stack developer, I wanted to build something that would help me deepen my understanding of Next.js while also creating a project that people could actually use. That's how I ended up building Epic Screen, a movie discovery platform powered by the TMDB API.

Live Website: https://epic-screen.vercel.app

The goal wasn't just to display movie posters. I wanted to understand how modern web applications fetch data, handle dynamic routes, improve performance, and provide a great user experience.

Why I Built This Project

I learn best by building real-world applications, and movie platforms contain many concepts that are commonly used in production software:

API integration
Dynamic routing
Server-side rendering
Loading and error states
Responsive design
Search functionality
Theme switching
Performance optimization

Building this project gave me the opportunity to work with all of these concepts in one application.

Tech Stack

I used the following technologies:

Next.js
React
Tailwind CSS
TMDB API
JavaScript
Vercel

Getting Movie Data with TMDB API

One of the most interesting parts of the project was integrating the TMDB API.

Instead of hardcoding movie information, the application fetches real movie data directly from TMDB. This includes:

Popular movies
Trending movies
Movie descriptions
Ratings
Release dates
Cast information
Reviews
Related movies

Using APIs taught me how applications communicate with external services and how important it is to handle loading and error states properly.

Understanding Dynamic Routes

Next.js made it easy to create pages for individual movies.

For example:

/movie/550
/movie/157336
/movie/299536

Each route represents a specific movie.

This helped me understand how dynamic routes work and how data can be fetched based on URL parameters.

Server Components and Data Fetching

One thing I really enjoyed while building this project was learning about how Next.js handles data fetching.

Instead of fetching everything on the client side, I used server components where appropriate. This approach has several advantages:

Faster page loads
Better SEO
Less JavaScript sent to the browser
Improved performance

Since the server handles most of the data fetching, users receive content faster and search engines can easily index the pages.

Search Functionality

No movie platform would be complete without search.

I implemented search so users can quickly find their favorite movies.

Building this feature taught me:

How to manage state in React.
How to handle user input.
How to send search queries to an API.
How to update the UI dynamically.

Small features like this significantly improve the overall user experience.

Responsive Design

I wanted Epic Screen to look good on every device.

Using Tailwind CSS made responsiveness much easier.

The website adapts to:

Mobile phones
Tablets
Laptops
Large desktop screens

I focused on:

Flexible layouts
Responsive grids
Proper spacing
Consistent typography

Theme Switching

Another feature I enjoyed implementing was dark mode.

I wanted users to have the ability to switch between light and dark themes while maintaining a clean and modern interface.

This helped me understand:

Theme providers
Context management
Persisting user preferences
Creating consistent color systems

Performance Optimization

Performance was one of my priorities while building this project.

Some things I focused on included:

Optimized Images

Using Next.js image optimization helps reduce loading times and improve user experience.

Efficient Data Fetching

Fetching only the data needed prevents unnecessary API requests.

Component Reusability

Reusable components made the codebase cleaner and easier to maintain.

Responsive Layouts

The application remains fast and usable across different screen sizes.

Challenges I Faced

Like any real-world project, I encountered several challenges along the way.

Hydration Issues

I experienced hydration mismatch errors while working with theme switching.

This taught me more about the differences between server-rendered and client-rendered components.

API Errors

Occasionally, requests would fail or data would be missing.

I learned the importance of:

Error handling
Fallback states
Defensive programming

Component Structure

As the application grew, maintaining clean code became increasingly important.

I learned how valuable it is to:

Separate concerns.
Create reusable components.
Keep files organized.
Avoid unnecessary complexity.

Lessons Learned

This project taught me much more than simply displaying movie information.

It strengthened my understanding of:

Next.js
React
API integration
Dynamic routing
Server components
Responsive design
Performance optimization
State management
Reusable component architecture

Most importantly, it reinforced something I strongly believe:

The best way to learn software engineering is by building projects.

Tutorials are useful, but real understanding comes from solving problems and debugging issues yourself.

Future Improvements

There are still several features I would like to add:

Authentication
User profiles
Watchlists
Favorite movies
Recommendations powered by AI
Advanced filtering
Infinite scrolling
Ratings and comments

Final Thoughts

Epic Screen was more than just another portfolio project.

It gave me hands-on experience with concepts that are used in modern web applications and helped me become more comfortable with Next.js and API-driven development.

Every project I build teaches me something new, and Epic Screen was no exception.

I'm excited to continue improving it and applying these lessons to even bigger projects in the future.

Explore the Project

Website: https://epic-screen.vercel.app

Thanks for reading! Feel free to connect with me or check out some of my other projects as I continue learning and building.

Author: Elvis Manzi Rurangirwa

Building a Movie Platform with Next.js and TMDB API

MANZI RURANGIRWA Elvis — Fri, 12 Jun 2026 08:34:50 +0000

Live Website: https://epic-screen.vercel.app

The goal wasn't just to display movie posters. I wanted to understand how modern web applications fetch data, handle dynamic routes, improve performance, and provide a great user experience.

Why I Built This Project

I learn best by building real-world applications, and movie platforms contain many concepts that are commonly used in production software:

API integration
Dynamic routing
Server-side rendering
Loading and error states
Responsive design
Search functionality
Theme switching
Performance optimization

Building this project gave me the opportunity to work with all of these concepts in one application.

Tech Stack

I used the following technologies:

Next.js
React
Tailwind CSS
TMDB API
JavaScript
Vercel

Getting Movie Data with TMDB API

One of the most interesting parts of the project was integrating the TMDB API.

Instead of hardcoding movie information, the application fetches real movie data directly from TMDB. This includes:

Popular movies
Trending movies
Movie descriptions
Ratings
Release dates
Cast information
Reviews
Related movies

Using APIs taught me how applications communicate with external services and how important it is to handle loading and error states properly.

Understanding Dynamic Routes

Next.js made it easy to create pages for individual movies.

For example:

/movie/550
/movie/157336
/movie/299536

Each route represents a specific movie.

This helped me understand how dynamic routes work and how data can be fetched based on URL parameters.

Server Components and Data Fetching

One thing I really enjoyed while building this project was learning about how Next.js handles data fetching.

Instead of fetching everything on the client side, I used server components where appropriate. This approach has several advantages:

Faster page loads
Better SEO
Less JavaScript sent to the browser
Improved performance

Since the server handles most of the data fetching, users receive content faster and search engines can easily index the pages.

Search Functionality

No movie platform would be complete without search.

I implemented search so users can quickly find their favorite movies.

Building this feature taught me:

How to manage state in React.
How to handle user input.
How to send search queries to an API.
How to update the UI dynamically.

Small features like this significantly improve the overall user experience.

Responsive Design

I wanted Epic Screen to look good on every device.

Using Tailwind CSS made responsiveness much easier.

The website adapts to:

Mobile phones
Tablets
Laptops
Large desktop screens

I focused on:

Flexible layouts
Responsive grids
Proper spacing
Consistent typography

Theme Switching

Another feature I enjoyed implementing was dark mode.

I wanted users to have the ability to switch between light and dark themes while maintaining a clean and modern interface.

This helped me understand:

Theme providers
Context management
Persisting user preferences
Creating consistent color systems

Performance Optimization

Performance was one of my priorities while building this project.

Some things I focused on included:

Optimized Images

Using Next.js image optimization helps reduce loading times and improve user experience.

Efficient Data Fetching

Fetching only the data needed prevents unnecessary API requests.

Component Reusability

Reusable components made the codebase cleaner and easier to maintain.

Responsive Layouts

The application remains fast and usable across different screen sizes.

Challenges I Faced

Like any real-world project, I encountered several challenges along the way.

Hydration Issues

I experienced hydration mismatch errors while working with theme switching.

This taught me more about the differences between server-rendered and client-rendered components.

API Errors

Occasionally, requests would fail or data would be missing.

I learned the importance of:

Error handling
Fallback states
Defensive programming

Component Structure

As the application grew, maintaining clean code became increasingly important.

I learned how valuable it is to:

Separate concerns.
Create reusable components.
Keep files organized.
Avoid unnecessary complexity.

Lessons Learned

This project taught me much more than simply displaying movie information.

It strengthened my understanding of:

Next.js
React
API integration
Dynamic routing
Server components
Responsive design
Performance optimization
State management
Reusable component architecture

Most importantly, it reinforced something I strongly believe:

The best way to learn software engineering is by building projects.

Tutorials are useful, but real understanding comes from solving problems and debugging issues yourself.

Future Improvements

There are still several features I would like to add:

Authentication
User profiles
Watchlists
Favorite movies
Recommendations powered by AI
Advanced filtering
Infinite scrolling
Ratings and comments

Final Thoughts

Epic Screen was more than just another portfolio project.

It gave me hands-on experience with concepts that are used in modern web applications and helped me become more comfortable with Next.js and API-driven development.

Every project I build teaches me something new, and Epic Screen was no exception.

I'm excited to continue improving it and applying these lessons to even bigger projects in the future.

Explore the Project

Website: https://epic-screen.vercel.app

Thanks for reading! Feel free to connect with me or check out some of my other projects as I continue learning and building.

Author: Elvis Manzi Rurangirwa

How to Escape Tutorial Hell (For Real This Time)

MANZI RURANGIRWA Elvis — Thu, 26 Feb 2026 09:49:51 +0000

Let’s assume something.
If you’re reading this, you already know you’re stuck.
You don’t need another dramatic explanation of tutorial hell.
You’ve lived it.

You’ve:

Finished courses
Built projects that only work with the instructor
Started over three times
Questioned your intelligence

So this isn’t going to be motivational fluff.
This is the plan I wish someone gave me earlier.

Step 1: Stop Quitting Tutorials(Finish One Properly)

Here’s the mistake most people make:
They jump from tutorial to tutorial.

React → Node → TypeScript → Next.js → “Maybe I should learn Python.”

Stop.
Pick one.
Finish it.
No skipping.
No hopping.

But here’s the twist:
You’re not finishing it to memorize it.
You’re finishing it to extract the patterns.

Ask:

Why did they structure it like this?
Why this folder layout?
Why this logic order?

You’re studying thinking, not syntax.

Step 2: Rebuild It Without Looking

This is where 90% of people panic.
After finishing a tutorial, close it.
Now rebuild the same project.
No copying.
No split-screen.
Just you and your memory.

It will feel awful.
Good.
That discomfort is where real learning starts.

When you get stuck:

Think first
Try something
Then search specifically

Not:
“How to build a full authentication system”

But:
“How to validate email input JavaScript”

Specific search = active learning.

Step 3: Build Something Slightly Different

Now change one thing.

If the tutorial built:
A to-do app

You build:
A habit tracker

If it built:
A blog

You build:
A notes app

Same concepts.
Different decisions.

Now your brain can’t rely on memory.
It has to think.

And thinking builds skill.

Step 4: Make Peace With Ugly Code

This part matters.

Your first independent project will look messy.
That’s normal.

Beginners often return to tutorials because their own code doesn’t look “clean.”

Clean code comes from:

Experience
Refactoring
Repetition

Not from watching someone else type beautifully structured code.

Messy code you understand is better than clean code you copied.

Step 5: Reduce Tutorial Time to 20%

Here’s a rule that changed everything for me:

20% learning.
80% building.

Not the other way around.

Tutorials are reference.
Building is training.

You don’t get stronger watching gym videos.

Step 6: Track What You Build, Not What You Watch

This is subtle but powerful.

Instead of saying:
“I finished 3 courses this month.”

Say:
“I built 2 working projects this month.”

Your identity shifts.

From:
Consumer.
To:
Builder.

Step 7: Expect Slower Progress (But Faster Growth)

Here’s the honest part:

You will feel slower.
You will doubt yourself.

You will think:
“I was progressing faster with tutorials.”

You weren’t!
You were progressing in comfort.
Now you’re progressing in competence.

And competence feels slower, but it lasts.

What Actually Changes When You Escape

You start:

Opening blank files without fear
Googling confidently
Debugging without panic
Thinking in systems, not steps

You don’t feel “ready.”
You just feel capable.

That’s different.

Final Truth

There is no dramatic escape from tutorial hell.

No single moment.

It’s a quiet shift:

From watching to building.
From copying to deciding.
From comfort to discomfort.

Over and over.
Until one day, you realize…
You haven’t opened a full tutorial in weeks.
And you didn’t even notice.

If you’re serious about escaping:

Close one tutorial today.
Open a blank file.
And start imperfectly.

That’s the way out.

Tutorial Hell Is a Billion-Dollar Problem

MANZI RURANGIRWA Elvis — Mon, 23 Feb 2026 17:10:53 +0000

Let me say something that might make people uncomfortable:

Tutorial hell is not an accident.
It’s a system.
And it’s making a lot of money.

I Thought I Was Learning

I remember the feeling.

New course.
New playlist.
New roadmap.

“This time,” I told myself, “I’m going to master it.”

The instructor was clear.
The project worked.
The code ran.

I felt productive, Intelligent, On track.

Then I closed the video.

Opened a blank file.

And my brain went completely silent.

No ideas.
No structure.
No confidence.

Just a blinking cursor.

The Addiction Nobody Talks About

Tutorials feel like progress.

They give you:

Direction
Momentum
Clarity
Small wins

But here’s the uncomfortable truth:

You’re not solving problems.

You’re watching someone else solve them.

Your brain isn’t building decision-making muscle.
It’s building recognition.

And recognition feels like understanding, until you’re alone.

Why It’s a Billion-Dollar Problem

Online learning platforms thrive on one thing: "Retention".

Not mastery.
Not independence.
Retention.

If you finish a course and immediately feel capable of building your own projects without coming back…

You don’t need another course.

But if you finish and feel like:

“I think I get it… but maybe I should watch one more tutorial.”

You stay.

You subscribe.
You enroll.
You keep consuming.

Nobody is evil here.
But the system rewards keeping you learning, not releasing you.

And that difference changes everything.

The Quiet Damage

Tutorial hell doesn’t just waste time.

It damages confidence.

You start to think:

“Maybe I’m just slow.”
“Maybe I’m not smart enough.”
“Other people are getting this faster.”
“Why can’t I build anything alone?”

You don’t realize the problem isn’t you.

It’s that you’ve trained yourself to follow, not to decide.

And programming is mostly decisions.

The Moment It Hit Me

The shift for me didn’t happen during a tutorial.

It happened during frustration.

I tried building something small.
It broke.
I had no guide.
No step-by-step.
No instructor voice telling me what to type next.

It was uncomfortable.
Messy.
Slow.

And weirdly… that’s when I learned the most.

Because I had to think.

Not copy.
Not follow.
Not predict what line came next.

Think.

And thinking is exhausting.

Which is why tutorials feel easier.

Why This Cycle Is So Hard to Escape

Tutorial hell is comfortable.
Building alone is uncomfortable.
Humans avoid discomfort.

So when your project gets hard, you do what feels productive:

You open YouTube.
You search:
“How to build X in React.”

And suddenly everything feels structured again.

But structure borrowed is not structure built.

The Brutal Truth

You don’t escape tutorial hell by watching a tutorial about escaping tutorial hell.

You escape it by:

Closing the video
Building something slightly wrong
Getting stuck
Googling intentionally
Fixing it
Repeating

It feels slower.
It feels uglier.
It feels less impressive.

But it builds something tutorials don’t: "Ownership".

The Real Cost

The cost of tutorial hell isn’t money. It’s years.

Years of:

Almost being ready
Almost feeling confident
Almost building something real

You don’t need another roadmap!

You need discomfort.

Not overwhelming chaos.
Just enough friction to force thinking.

This Isn’t Anti-Tutorial

Tutorials are tools.

But tools are dangerous when they become crutches.

Use them to:

Understand concepts
See patterns
Learn structure

Then leave.
Don’t live there.

If This Feels Personal…

Good.

It felt personal when I realized it too.

If you’ve ever:

Built something perfectly with a video
Failed to rebuild it alone
Questioned your intelligence
Bought “just one more course”

You’re not broken.

You’re just stuck in a system that rewards watching more than building.

And the only way out isn’t dramatic.

It’s small.

Build one imperfect thing without guidance.

Then another, then another.

And eventually, you’ll look back and realize:

You don’t need someone telling you what to type anymore.

Tutorial hell isn’t about laziness.
It’s about comfort.
And comfort is expensive.

If you want to actually grow,
you’ll have to choose discomfort on purpose.

Not forever.

Just long enough to start thinking for yourself.

Why Discipline Beats Passion in Programming

MANZI RURANGIRWA Elvis — Mon, 23 Feb 2026 16:08:57 +0000

Let’s be honest.

Passion is amazing…
for about three days.

Day one:
You’re watching tutorials at 2AM.
You’re telling everyone you’re “learning to code.”
You feel unstoppable.

Day seven:
You open your laptop.
You stare at the screen.
You suddenly remember you also wanted to learn guitar.

Welcome to reality.

The Problem With Passion

Passion feels powerful because it’s emotional.

It’s that rush when:

You finally understand something.
Your code runs without errors.
You imagine yourself building cool apps. But here’s the part nobody says loudly enough:

Passion is inconsistent.

It shows up when things are exciting.
It disappears when things get boring.

And programming gets boring.

Not because it’s bad.
But because growth includes:

Debugging for 40 minutes
Reading documentation
Refactoring code that “worked fine”

Passion doesn’t love those moments.

Discipline Doesn’t Care How You Feel

Discipline is different.

Discipline says:

“You said you’d code today. So code.”

Even when:

You’re tired
You’re confused
You’d rather scroll social media
Nothing is clicking Discipline shows up quietly.

No fireworks.
No dramatic music.
Just consistency.
And consistency wins.

The Lie About “Loving What You Do”

We’re told:

“If you love it, you’ll never work a day in your life.”

That sounds nice.

But even if you love programming, there will be days when:

You doubt yourself
You feel behind
You don’t want to look at another error message

Love doesn’t eliminate difficulty.
It just makes it meaningful.

Discipline is what carries you through the difficult parts.

The Real Difference Between Beginners and Pros

It’s not intelligence.
It’s not talent.
It’s not some secret brain upgrade.

It’s this:

Beginners code when they feel motivated.
Professionals code when it’s scheduled.

That’s it.

The person who codes 30 minutes every day for a year
will outperform the person who codes 6 hours once a week when inspired.

Quiet effort beats emotional bursts.
Every time!

The Days That Actually Matter

The days that change you aren’t the exciting ones.

They’re the ones where:

You didn’t want to start… but you did.
You didn’t understand… but you tried anyway.
You felt slow… but you didn’t quit.

Those days stack.

And stacking days builds confidence.

The Shift That Helped Me

I stopped asking:

“Do I feel like coding today?”

And started asking:

“What’s the smallest thing I can complete?”

Not a full project.
Not a massive feature.

Just one small win.

Momentum doesn’t come from passion.
It comes from movement.

Passion Starts You. Discipline Finishes You.

Passion is the spark.
Discipline is the engine.

You need both.
But only one works when things get hard.

And programming gets hard.

That’s not a warning.
That’s a promise.

Conclusion:

If you’re waiting to “feel ready” or “feel motivated”,
you’ll be waiting a long time.

But if you build the habit of showing up anyway?

You won’t need motivation.
You’ll have momentum.

And momentum is way more powerful.
If you’re learning to code right now,
be honest:

Are you relying on passion… or building discipline?

Why You Forget Code You Learned Last Week

MANZI RURANGIRWA Elvis — Wed, 21 Jan 2026 03:14:39 +0000

Let me guess.

Last week, you finally understood something.
It clicked.
You felt smart. Dangerous, even.

Then this week… you opened your editor and thought:

“Wait. Why does none of this look familiar?”

Congratulations. You’re not broken.
You’re officially learning to code.

The Lie We’re All Told

Somewhere along the way, we’re made to believe that learning to code works like this:

Learn something → remember it forever → move on.

That might work for memorizing song lyrics.
It does not work for programming.

If forgetting code was a sign you’re bad at it, there would be approximately zero developers left on Earth.

Your Brain Is Not a USB Drive

This was a hard pill for me to swallow.

I used to think:

“If I forget this, it means I didn’t really learn it.”

No. It means your brain is doing what brains do.

Code isn’t facts.
It’s patterns, logic, and decisions.

If you don’t use it, your brain quietly says:

“Wow. Not important. Deleting.”

Ruthless. Efficient. Slightly rude.

Tutorials Make This Worse (Sorry)

Tutorials are great… until they aren’t.

When you follow along:

The decisions are already made
The structure is given
The problems are pre-solved

Your brain is basically on passenger mode.

So when the tutorial ends and you try to build something alone, your brain panics:

“Wait, we were just watching. Why are we driving now?”

That’s why everything disappears.

Forgetting Is Not Failure. It’s a Signal

This part changed how I see learning.

Forgetting usually means:

You didn’t struggle enough
You didn’t make decisions
You didn’t break anything

The things you remember best are the ones that:

Took you forever
Made you angry
Broke three times before working

Pain = memory.
Sadly.

The Moment I Stopped Panicking

I remember opening a project and realizing I couldn’t remember how I did something I literally wrote.

Past me had betrayed present me.

Instead of panicking, I tried something new:
I reread my own code.

And suddenly it came back.

Not because I memorized it, but because I understood why it existed.

That’s when I realized:

The goal isn’t to remember code.
The goal is to remember how to figure it out again.

What Good Developers Actually Remember

Here’s a secret.

Good developers don’t remember:

Exact syntax
Every method name
Every edge case

They remember:

How to think
How to break problems down
Where to look when they forget

They Google. Constantly. Confidently. Shamelessly.

How to Forget Less (Without Trying Harder)

Here’s what actually helps:

1. Build Something Small After Learning

Even a tiny thing.
Especially a tiny thing.

Your brain remembers decisions, not explanations.

2. Revisit Old Code (Yes, It’s Ugly)

Reading your past code feels like reading old diary entries.

Cringe.
But powerful.

3. Explain It to an Imaginary Person

If you can explain it without code, you understand it.
If you can’t, that’s okay! Now you know what to revisit.

The Reframe That Saved Me

Now, when I forget something, I don’t think:

“I’m bad at this.”

I think:

“Okay. I’ve seen this before. Let’s reconnect the dots.”

Learning to code is not about building a perfect memory.

It’s about building familiarity.

And familiarity comes back faster every time.

Final Thought

If you’re forgetting code you learned last week, you’re not behind.

You’re not stupid.
You’re not failing.

You’re just doing something hard, and doing it honestly.

And that’s exactly how real developers are made.

If this article felt a little too real, you’re my people.

What’s the last thing you forgot that made you question everything? 😄

Things No One Tells You About Learning to Code

MANZI RURANGIRWA Elvis — Wed, 21 Jan 2026 02:56:18 +0000

Most people talk about learning to code like it’s a straight road:

Learn a language → build projects → get a job → succeed.

That’s not how it actually works.

If you’re learning to code right now, there are a lot of things no one tells you which are things I wish I knew earlier. This article is for beginners, self-taught developers, and anyone who feels stuck, confused, or behind.

Let’s talk honestly.

1. Feeling Stupid Is Part of the Process

No one warns you about this.

You’ll watch a tutorial, feel confident, then try to build something alone — and suddenly nothing works. Errors everywhere. Concepts you thought you understood feel foreign.

This doesn’t mean you’re bad at coding.
It means your brain is adapting to a new way of thinking.

Every good developer you admire has felt this. Repeatedly.

If you’re confused, you’re not failing — you’re learning.

2. Tutorials Can Trap You

Tutorials feel productive. You follow along, the app works, and you feel smart.

But here’s the uncomfortable truth:

Watching tutorials doesn’t mean you can build.

You only really learn when:

You close the tutorial
You break things
You fix them yourself

Tutorials should be training wheels, not your destination.

The moment you start building your own messy, imperfect projects, that’s when growth accelerates.

3. You’ll Learn Slower Than You Expect (And That’s Normal)

Social media makes it look like everyone is:

Learning React in a week
Building startups at 16
Becoming a “10x developer” overnight

Reality is slower. Much slower.

Learning to code is more like going to the gym:

Progress is invisible at first
Consistency beats intensity
Skipping days hurts more than you think If you show up regularly, even when motivation is low, you will win.

4. Copying Code Is Not Cheating

Beginners often feel guilty copying code from:

Stack Overflow
GitHub
Docs

Here’s the truth:

Every developer copies code.

The key difference:

Bad copying = paste and move on
Good copying = paste, then understand, modify, and reuse

Learning to code isn’t about memorization.
It’s about recognizing patterns and knowing where to look.

5. Projects Matter More Than Languages

People obsess over:

“Which language should I learn?”
“Is X better than Y?”

Most of the time, it doesn’t matter.

What matters is:

Can you build something?
Can you explain how it works?
Can you improve it?

A simple project you understand deeply is more valuable than 5 languages you barely know.

6. You’ll Break Things. A Lot.

Your code will:

Crash
Refuse to run
Work yesterday but not today

This is normal.

Debugging is not a side skill! It is the skill!

Every error you fix:

Makes you more confident
Trains your problem-solving ability
Separates you from people who quit

7. Progress Is Not Linear

Some days you’ll feel unstoppable.
Other days you’ll forget things you learned last week.

That doesn’t mean you’re going backward.

Learning to code looks like:

Confusion
Small breakthroughs
Bigger confusion
Clarity

Over time, the confusion becomes more manageable.

8. You Don’t Need to Know Everything

Beginners think real developers:

Memorize syntax
Know every framework
Never Google That’s false.

Real developers:

Google constantly
Read documentation
Ask questions

Learn just enough to solve the problem

You don’t need to know everything. You need to know how to learn.

Final Thought

Learning to code is hard.
Not because you’re incapable, but because it forces you to think differently.

If you’re struggling, that’s a good sign.
It means you’re doing real work.

Keep building. Keep breaking things. Keep going.

If you’re learning to code right now:
What’s the hardest part for you?

The Hidden Skill Every Good Developer Has (That No One Taught Me)

MANZI RURANGIRWA Elvis — Wed, 21 Jan 2026 02:36:37 +0000

When I first started learning to code, I thought I was doing everything right.

I watched tutorials.
I followed along line by line.
My code worked — at least in the video.

Then I tried to build something on my own.

And everything fell apart.

The Moment I Realized Something Was Missing

I remember staring at my screen, completely stuck.

Not because I didn’t know the syntax.
Not because I hadn’t “learned enough.”

But because I didn’t know where to start.

The task felt simple on the surface, yet overwhelming in reality. My brain was trying to solve UI, logic, data flow, and edge cases all at once. I kept asking myself:

“What code do I write here?”

That question kept leading me nowhere.

What I didn’t realize at the time was that I wasn’t missing a language, a framework, or a tutorial.

I was missing a skill.
The Skill No One Mentions

Ask people what makes a good developer, and they’ll usually say:

Knowing many languages
Writing clean code
Understanding algorithms
Learning fast

Those things matter, but they’re not the foundation.

The hidden skill every good developer has is problem decomposition.

The ability to take a messy, overwhelming problem and break it into small, manageable pieces.

Once I understood this, everything changed.

Good Developers Don’t Start With Code

Beginners (including past me) think like this:

“How do I code this feature?”
Good developers think like this:

“What problem am I actually solving?”

Before writing a single line of code, they ask:

What should happen?
In what order?
What are the inputs?
What could go wrong?
What does “done” even mean?

They don’t rush.
They clarify.

Why Everything Felt So Hard Before

Back then, I wasn’t bad at coding.

I was trying to solve the entire problem in my head at once.

For example, instead of thinking:

“Let me first show the form”
“Then validate the input”
“Then store the data”
“Then handle errors”

I thought:

“I need to build the whole system.”

That mental overload is why learning to code feels impossible for many beginners.

Not because the problem is too big, but because it hasn’t been broken down yet.

The Shift That Changed How I Code

At some point, I stopped asking:

“What code should I write?”

And started asking:

“What’s the smallest piece of this I can solve right now?”

That one change:

Reduced overwhelm
Made debugging easier
Increased confidence
Helped me actually finish projects

I wasn’t becoming smarter.
I was becoming more methodical.

Why This Skill Matters More Than Any Language

Here’s the part most beginners don’t hear enough:

Programming languages change.
Frameworks come and go.
Tools evolve constantly.

But the ability to:

Analyze problems
Break them into steps
Solve one piece at a time

That skill transfers everywhere.

A developer with strong problem decomposition can pick up new technologies faster than someone who only memorizes syntax.

Debugging Is Proof This Skill Works

When something breaks, beginners panic.

Experienced developers pause and ask:

What was supposed to happen?
What actually happened?
Where could the difference come from?

Debugging is just problem decomposition in reverse.

You’re narrowing the problem until the real cause reveals itself.

That’s why good developers don’t fear bugs — they treat them like puzzles.

How I Practice This Skill Now

I still do this consciously:

1. I Explain the Problem in Plain English
If I can’t explain what I’m building without code, I’m not ready to code it yet.

2. I Build the Simplest Version First
Not the best version.
Not the cleanest.
Just the version that works.

Then I improve it.

3. I Focus on the Next Small Win
Not:

“How do I finish this project?”

But:

“What’s the next tiny thing I can make work?”

Momentum beats motivation every time.

Final Thought

Great developers aren’t magic.
They’re not faster learners.
They don’t know everything.

They’re just really good at breaking problems down.

If learning to code feels hard right now, don’t assume you’re failing.

You might just be learning the most important skill — the one no tutorial explicitly teaches.

What’s a problem you’re currently stuck on, and how are you breaking it down?