DEV Community: Favor Charles Owuor

How I Learn Any New Language or Framework

Favor Charles Owuor — Sat, 06 Jun 2026 03:01:50 +0000

When I pick up a new language or framework, I do not start with a course. I do not read documentation for hours. I learn the three things that every language shares, then I build five projects in a specific order.

This article breaks down exactly what to learn and what to build so you are not wasting time on things that do not matter yet.

The Foundation — Three Things First

Every language, whether it is Python, Go, Rust, or a framework like React, is built on the same three concepts. Learn these first.

Variables — how the language stores data. What types exist. Whether it is typed or not. How you declare something.

Data structures — how the language groups related data. Arrays, lists, objects, dictionaries — whatever it is called. This is how you model things in code.

Control structures — how you manage decisions and repeat work. If statements, loops, switches. The logic backbone.

That is the entire foundation. Once you can store data, shape it, and control the flow of your program, you understand enough to start building. Everything else — advanced typing, complex patterns, performance tricks — you can pick them up as you go.

The Five Projects

Here is the full arsenal. Each project introduces exactly one new concept. You never jump more than one layer at a time. By the end, you have covered the majority of what real-world development actually requires.

Project 1 — The Calculator

Image by rawpixel.com on Magnific

The calculator teaches you functions.

A calculator forces you to write reusable logic. You cannot just write everything in one chunk. You need to take inputs, do something with them, and give back a result. That is the mental model for every function you will ever write.

What you learn here:

How to define and use functions
How to handle inputs and return values
How to break logic into small, reusable pieces
Basic error handling — what happens when someone divides by zero

Keep it simple. Four operations. A working result. Add a simple interface if you are using a framework.

Project 2 — The Todo List

Image by Kampus on Magnific

The todo list is not about productivity apps. It is about managing data.

Almost every real application you will ever build does four basic things with data: create it, read it, update it, delete it. A social feed, a shopping site, a dashboard — they all do this.

What you learn here:

How to create new data and store it
How to read and display a list of items
How to change an existing item
How to remove something you no longer need
How data changes over time in your program

Once you can build a todo list, you can build the data layer of most simple apps.

Project 3 — The Weather App

Image by upklyak on Magnific

This is where most beginners hit a wall. The calculator and todo list are self-contained — they do not talk to the outside world. The weather app fixes that.

You call a real weather service. You handle data you did not create and cannot control. You will deal with waiting states, error states, and responses that sometimes do not look the way you expect.

What you learn here:

How to handle tasks that take time to finish
How to get data from an outside source
How to show loading, success, and error states
How to work with the data you receive and turn it into something useful

This single project unlocks more of real-world development than almost anything else you can build at this stage.

Project 4 — The Expense Tracker

Image by pikisuperstar on Magnific

The todo list taught you to manage data. The expense tracker teaches you to keep it.

This project adds memory — data that survives after you close the app. It also introduces summaries: totals, filters, categories. You are not just storing items anymore, you are doing something meaningful with them.

What you learn here:

How to save data so it is still there when you reopen the app
How to think about where your data actually lives
How to filter and add up values from a set of data
How a slightly richer list of items changes how you build your app

Build on your todo list. Same basic approach, but now the data stays and you do more with it.

Project 5 — Login and Protected Pages

Image by freepik

Most apps have two kinds of content: things anyone can see and things only certain people can access.

What you learn here:

How login works in practice
How to remember that someone has logged in
How to hide a page or feature from someone who should not see it
How to send someone to the login screen when they try to go somewhere they should not

You do not need to build a perfect, secure login system. You just need to understand the idea well enough that nothing surprises you when you see it on a real project.

Why This Works

Most learning resources teach you everything before you need it. You spend weeks on concepts that only make sense once you have run into the problem they solve. This approach flips that. You learn the minimum needed to start building, then learn the rest when the project demands it.

The three foundations get you reading and writing the language. The calculator teaches functions. The todo list teaches data management. The weather app teaches waiting for outside data. The expense tracker teaches memory and summaries. Login teaches access control.

Frameworks and Documentation

Frameworks

A framework is a set of pre-written code, guidelines, and tools that simplify software development[mimo framwork blog]. React gives you components. Django gives you a database tool and a way to organize pages. None of that changes the three foundations above.

When I learn a framework, I do the same thing I do with a language. I learn just enough to start building. That usually means learning three framework-specific things:

How to create a new screen or page
How to show dynamic data on that page
How to respond to a click or user action

That is it. Everything else — state management libraries, build tools, advanced routing — can wait until you need it.

Documentation

Documentation is a reference, not a textbook. You do not learn a language by reading every page. You learn by trying to do something, getting stuck, and then looking up the one small thing you need. Think of documentation like a dictionary. You would not learn English by reading a dictionary from cover to cover. You learn by speaking, then checking a word when you do not know it.

So skip the long reading sessions. Open the docs when you hit a specific problem. Find the answer. Close the docs. Keep building.

Conclusion

Here is the truth most tutorials will not tell you: you do not need to know everything before you build anything. You never will. Even experienced developers look things up constantly. The difference is they do not let that stop them.

The method here is simple. Learn three basics. Build five small projects in order. Use documentation only when you are stuck. That's it.

You will forget syntax. You will write messy code. You will get errors that make no sense. But that's part of the learning process. Every error you fix teaches you something that no video or article could ever teach.

So here is your challenge. Pick a language or framework today. Not next week. Today. Learn the three foundations. Build the calculator. Then the next one. Do not wait until you feel ready. You will never feel ready.

Silent Skills Every Developer Should Build

Favor Charles Owuor — Mon, 01 Jun 2026 17:06:20 +0000

"The coming generation of programmers are not those who know how to code, but those who have mastered soft skills."
Co-Executive Director - Caleb Nyoiro

When people start learning software development, most of the attention goes to programming languages, frameworks, and tools.

Which language should I learn? Should I learn React or Vue? Do I need Docker? What does docker even do?... These are common questions, and they're important. But after spending time around developers, I've noticed something interesting.

The developers who grow the fastest are not always the ones who know the most frameworks. They're usually the ones who have developed a set of quiet habits that most people don't notice.

One would call them soft skills. Others call them people skills. But I like calling these silent skills.

Effective Communication

At first, I thought communication just meant explaining what I did. But Good communication is about reducing confusion for others.

In a team, vague language creates delays. Saying: “The API is broken.” doesn’t help much. Instead, say: “The login endpoint returns 500 when the token is expired.” This helps someone fix the problem immediately.

That difference saves time. Communication is not about talking more. It’s about making things clear the first time.

And not just to tech savvy people but also to the other general public such as a client. Also knowing your audience and adjusting the way you pass information, can help them understand what you are doing.

It also shows that you want them to understand what you are doing which would allow them to trust you more.

Teamwork and Collaboration

Software development is rarely solo work. Even if you write code alone, your work connects to other people’s systems.

Early on, I treated my tasks like isolated assignments. My job was to finish my part. That mindset causes friction.

Real teamwork is about awareness. You think about how your changes affect QA, backend, frontend, and product decisions.

You also accept feedback without turning it into conflict. Good collaboration is simple. You should care about the shared goal more than being right.

Problem-Solving

Good problem-solvers slow down before they act. They ask: What exactly is wrong? When did it start? What changed? What is the smallest possible test case?

I’ve seen developers fix bugs in 10 minutes because they understood the problem properly. I've also been able to do it recently and It was a really nice feeling being able to solve a problem and explain the solution to others

Emotional Intelligence

This is the most ignored skill in tech. Code is logical. Teams are not.
You will work with stressed people, rushed deadlines, and conflicting opinions.

Emotional intelligence is about staying stable in that environment. It means: Not reacting emotionally to feedback. Not blaming others when things break. Understanding when someone is under pressure.

A calm developer keeps the team stable. A reactive one creates tension.

Adaptability and Flexibility

Nothing in tech stays still. Tools change. Requirements change. Even entire systems get replaced. Right now the big thing is AI and has replaced many roles

Adaptability is simple in idea but hard in practice. It means: You don’t panic when tools change. You don’t cling to one way of doing things.

You adjust and keep moving. The best developers are not the ones who know the most. They’re the ones who stay up to speed when things shift.

Time Management

Deadlines are real. Tasks stack up quickly. Without structure, work becomes chaos. Things can pile up and soon become overwhelming

Time management is not about working more hours. It’s about deciding what matters first. Some tasks move the product forward. Some only look urgent. A strong developer learns to separate the two.

They plan their day, break work into smaller parts, and finish what actually matters instead of what feels busy. This allows one to accomplish more in one day, than stay stuck on one thing and end up behind in other things.

Why These Skills Matter

Technical skills get you in the door. Silent skills decide how far you go.
You can write perfect code and still struggle in a team if communication is weak.

You can know many frameworks and still miss deadlines if time management is poor.

You can solve complex problems alone and still fail in a team if collaboration is missing.

These skills shape how people experience working with you. And in most companies, that matters more than people expect.

Conclusion

Silent skills are not optional extras. They are part of the job.
They decide how well you work with others, how you handle pressure, and how you grow over time.

Code solves technical problems. Silent skills solve everything around the code.

Start paying attention to them early. They will stay useful long after specific tools become outdated.

Git Licenses

Favor Charles Owuor — Mon, 01 Jun 2026 15:39:53 +0000

Image by djvstock on Magnific

When you upload a project to GitHub, do you ever stop to think that your project can be used elsewhere? The code is online. People can see it. People can fork it. So naturally, they can use it too... right? Not exactly.

The thing is, without a license, your code is still protected by default copyright laws. Other developers can look at it, but legally they can't just copy it, modify it, or redistribute it.

Let's try to understand why licenses exist. Let's talk about what they are and why every developer should know about them.

What Is a License?

A license is a legal document that tells other people what they are allowed to do with your code.

It answers questions like:

Can someone modify your code?
Can they use it in a commercial product?
Do they need to open-source their changes?
Can they redistribute it?

Without a license, those questions don't have clear answers. Adding a license removes the guesswork and gives everyone a clear set of rules to follow.

Why Licenses Matter

Many developers focus on writing code and forget about the legal side of software. The problem is that other developers often won't use a project if the licensing situation isn't clear.

Imagine finding an amazing open-source project that solves a problem you've been struggling with.

At that point, many developers will simply move on because they don't know what they're legally allowed to do with the code.

Most open-source licenses include liability clauses that prevent people from holding you responsible if something goes wrong while using your software.

Common Types of Licenses

When I first looked at licenses, the number of options felt overwhelming. Fortunately, most projects fall into a few common categories.

Permissive Licenses

Licenses like MIT and Apache 2.0 are very flexible. They allow people to use, modify, distribute, and even sell software built from your code.
In most cases, they simply require users to keep the original copyright notice and license information. The MIT License is one of the most popular choices on GitHub because it's simple and easy to understand.

Copyleft Licenses

Licenses such as GPL and AGPL take a different approach. They allow people to use and modify your code, but there's a condition. If someone distributes software based on your project, they must also make their source code available under the same license. This helps ensure that improvements remain open-source.

Proprietary Licenses

Sometimes you don't want people modifying or distributing your software. In that case, a proprietary license keeps all rights in your hands. Others must receive explicit permission before they can use, copy, or distribute the software. Most commercial software follow this model.

How to Add a License

Adding a license to a GitHub repository is surprisingly easy.
Create a file named LICENSE in the root of your project.
GitHub can generate license templates for you, making the process even simpler.
Choose the license that matches your goals, review the text, and commit the file.
Your repository now has clear legal terms attached to it.

Which License Should You Choose?

This is usually the first question people ask. The answer depends on what you want to achieve. If your goal is maximum adoption and you don't mind commercial use, MIT is often a good choice. If you want similar flexibility but also want patent protections, Apache 2.0 is worth considering.

If you want improvements to remain open-source, GPLv3 may be a better fit.

If you're building software that could be offered as a hosted service and you want modifications shared publicly, AGPLv3 provides stronger protections.

And if you truly don't care what happens to the code, options like Unlicense or CC0 place it as close to the public domain as possible.

There isn't a universally correct answer. The best license is the one that aligns with your goals.

What Happens Without a License?

Many new developers assume that no license means complete freedom. The reality is the opposite. Without a license, your code is protected by default copyright law.

That means other developers have very limited legal rights to use it. As a result, people may avoid your project entirely.

You also lose the opportunity to clearly define how others should interact with your work. A missing license creates uncertainty, and uncertainty tends to push contributors away.

Conclusion

A license might seem like a small detail compared to writing features and fixing bugs. I used to think the same thing. The more I looked at open-source projects, the more I realized that a license is one of the most important files in a repository.

It tells people how they can use your work, protects you from unnecessary liability, and creates a clear framework for collaboration.
Before pushing your next project to GitHub, take a few minutes to choose a license.

Git Commit Messages

Favor Charles Owuor — Mon, 01 Jun 2026 13:29:19 +0000

A well-written commit message is one of the most underrated skills in software development. It turns a chaotic git history into a readable, searchable record of every decision you have ever made. This will guide in writing structured.

Step 1: Understand the Standard Structure

The industry standard is the Conventional Commits specification, paired with the 50/72 length rule. Together they make your history easy to read for humans and easy to parse for automated tools.

A complete commit message follows this template:

<type>(<optional scope>): <short description in imperative mood>

[optional body — explains the what and why behind the change]

[optional footer — references issue trackers or declares breaking changes]

Here is a real example:

feat(auth): add multi-factor authentication check

Introduce an intermediate step in the login pipeline to check for a
valid TOTP token. This protects user accounts against credential stuffing.

Closes JIRA-8422

Step 2: Know the Parts of a Commit Message

Type A lowercase prefix that categorizes the nature of your change (e.g., feat, fix, docs).

Scope (optional) A modifier in parentheses that gives context on which part of the codebase is affected (e.g., auth, api, ui).

Description A short summary of what the commit accomplishes — written as a command, not a past-tense statement.

Body (optional) Extended paragraphs explaining the problem being solved and the motivation behind your fix. Focus on why, not how.

Footer (optional) Metadata used to reference issue IDs (e.g., Closes JIRA-8422) or declare breaking changes.

Step 3: Learn the Core Formatting Rules

For the subject line

Keep it under 50 characters for optimal display in GitHub and terminal interfaces.
Use the imperative mood — write it as a command (use add not added or adding).
Drop the trailing period — never end your subject line with a full stop.
Keep the type lowercase — feat: not Feat: or FEAT:.

For the body

Leave one blank line between the subject and the body.
Wrap lines at 72 characters to avoid truncation in terminal windows.
Explain why, not how — the code shows how; the message should explain why the old state was a problem.

Step 4: Learn the Standard Commit Types

You don't need to memorize all of these on day one, but this is the full reference:

Type	When to use it
`feat`	Introduces a brand-new feature
`fix`	Corrects a bug or unintended behavior
`refactor`	Restructures code without changing its behavior
`chore`	Routine maintenance, config tweaks, or package updates
`docs`	Changes made exclusively to documentation or markdown files
`style`	Formatting or whitespace adjustments that leave logic unchanged
`test`	Adding missing tests or repairing broken test suites
`perf`	Performance optimizations designed to increase speed or efficiency

Step 5: Start Small — Master Three Types First

Don't try to memorize all eight types immediately. For your first few weeks, use only these three:

feat: — when you add something new (e.g., feat: add submit button)
fix: — when you repair something broken (e.g., fix: correct broken nav link)
docs: — when you write or update documentation (e.g., docs: update setup guide)

Once these feel automatic, layer in the others one at a time.

Step 6: Use the Imperative Mood Test

Write your subject line so it logically completes this sentence:

"If applied, this commit will [your message]."

Correct: feat: add login page → "If applied, this commit will add login page."
Incorrect: feat: added login page or feat: adding login page

If it doesn't complete that sentence naturally, rewrite it.

Step 7: Commit Small and Often

The hardest habit for beginners to build is committing frequently. The rule is simple: make one commit for every one completed task.

Don't write code for three hours and then commit fix: everything.
Do commit every time you finish a single small task — one component, one bug fix, one style correction.

Small commits are easier to review, easier to revert, and tell a much clearer story to your team.

Step 8: Automate the Rules With Commitizen

Once you want to enforce the format consistently, use Commitizen — a command-line tool that guides you through writing a conventional commit with interactive prompts. You can run it immediately with npx without any complex setup:

npx commitizen init cz-conventional-changelog --save-dev --save-exact

From then on, instead of writing git commit -m "...", run git cz and answer the prompts. The tool assembles the correctly formatted message for you.

Conclusion: Build the Habit Now

Mastering commit messages is about transitioning from a messy, hard-to-read history to a structured, predictable one that your whole team can rely on.

Three things to take away:

Consistency trumps perfection. It matters less which exact types you use and more that you and your team use the same format every single time.
Keep it short and purposeful. Under 50 characters for the title, imperative mood, and use the body to explain the why.
Start small, then automate. Begin with just feat, fix, and docs. Commit frequently. Then bring in Commitizen to handle the formatting automatically.

The best time to start writing better commit messages is on your very next commit.

Testing Discipline: A Beginner's Guide

Favor Charles Owuor — Mon, 01 Jun 2026 12:45:22 +0000

Image by upklyak on Magnific

Run an application. Click a few buttons. If the terminal doesn't have errors, then everything is working. Right?

What's the point of writing tests if all seems to be fine. Let's explore testing discipline and why it's a habit every developer should build early.

What is Testing Discipline?

Testing discipline is the habit of verifying that your code works. It's not something you do at the end of a project.
It's something you build into your development process.

The goal is simple. Catch bugs as early as possible. A bug found while writing code usually takes minutes to fix.

The same bug found in production can take hours to investigate, reproduce, and resolve.

The earlier you find problems, the less expensive they become.

Different Types of Tests

When people talk about testing, they're usually referring to three categories.

The first is unit testing. A unit test checks a single piece of functionality, usually a function or method. These tests are fast and easy to write, making them the best place for beginners to start.

Next are integration tests. These verify that different parts of your application work together correctly. For example, does your service communicate properly with the database?

Finally, there are end-to-end tests. These simulate a real user interacting with the application from start to finish. They provide the most realistic results but are usually slower and more complex.

As a beginner, I recommend that you should focus on unit tests first.

Different Testing Approaches

As you continue learning, you'll come across different testing methodologies.

One of the most popular is Test-Driven Development, often called TDD.

The idea is simple. Write the test first. Watch it fail. Write enough code to make it pass.

Many developers like this approach because it forces them to think about requirements before writing implementation details.

You may also hear about Behaviour-Driven Development, or BDD.

This approach focuses on describing behaviour in a way that both technical and non-technical people can understand.

Then there is static testing and dynamic testing.

Static testing involves reviewing code without running it. Code reviews and linters fall into this category.

Dynamic testing involves running the application and verifying its behaviour.

Both have their place in a healthy development process.

Writing Tests in Go

One thing I like about Go is that testing support is already built into the language. You don't need to install any package just to write your first test.

There are a few rules to remember.

Test files must end with _test.go.
Test functions must begin with Test.
They must also accept a *testing.T parameter.

For example:

func TestCalculateDiscount(t *testing.T) {
    // test logic
}

Once you follow those rules, Go automatically recognizes your tests.

A Simple Example

Imagine you're building an e-commerce application.

You have a function that calculates discounts based on order value.

Your code works for normal orders, but what happens if someone enters a negative amount?
What happens at the discount threshold?
What happens for large purchases?

These are the kinds of questions tests help answer.

A common pattern in Go is called table-driven testing.

Instead of writing separate tests for every scenario, you place inputs and expected outputs into a table and loop through them.

This allows you to test multiple situations without repeating large amounts of code.

It's one of the most common testing patterns you'll see in Go projects.

Running Tests

Once you've written a test, running it is simple.

To run all tests:

go test

To see detailed output:

go test -v

To check test coverage:

go test -cover

When you're starting out, go test -v is usually the most helpful because it shows exactly which tests passed and which failed.

Making Testing Part of Your Workflow

Writing a few tests is useful. Whenever you add a feature, write tests for it.
Whenever you fix a bug, consider adding a test that prevents the same bug from returning.

Over time, your test suite becomes a safety net.
You can refactor code, improve performance, and add features with much more confidence because the tests will alert you if something breaks.

This becomes even more important when using CI/CD pipelines.
Tests can run automatically whenever code is pushed, helping catch issues before they reach production.

Why Testing Matters

I know testing can feel slow at first.
When you're excited about building features, writing tests can seem like extra work.

But after spending hours debugging issues that a simple test could have caught in seconds, my perspective changed.

Tests give you confidence.
They make refactoring safer.
They help identify bugs quickly.
They also act as documentation by showing exactly how a function is expected to behave.
Most importantly, they help you deliver software that actually works.

Conclusion

Many beginners see testing as something they'll learn later.
The truth is that testing is one of the habits that helps you grow from a beginner into a reliable developer.
You don't need to test everything immediately.

Pick a function you've already written and create a few test cases for it.
Test the normal case.
Test an edge case.
Test an error case.
Run the tests and see what happens.

The more often you do this, the more confidence you'll have in your code and the less time you'll spend chasing bugs in production.

Working in Branches

Favor Charles Owuor — Mon, 01 Jun 2026 12:12:56 +0000

When I first started using Git, I did everything on the main branch. It seemed easier. I would make changes, commit them, push them, and move on. For solo projects, it didn't seem like a problem.

I failed my first ever interview. I had the first round which was good, then moved on to the second round which was a home assignment. I was tasked to create a simple Django English-Swahili translator. It was simple enough. I created it, and submitted. To me I felt like I had passed.

I sought feedback as to why I failed. There were a bunch of reasons but one of them was that I only worked on the main branch.

From that experience, I decided to start working in branches for every significant and sometimes non-significant task.

What Are Branches?

A branch is an isolated version of your codebase. It allows you to work on a feature, bug fix, or experiment without affecting the main code that everyone relies on.

Think about building a login page. Instead of changing the main branch directly, you create a separate branch and do all your work there. If something breaks, only the branch is affected. The main branch remains safe.

Once the feature is complete and tested, you merge it back into the main branch.

A Typical Branch Workflow

Most development work follows a simple process.

First, make sure your local repository is up to date.

git checkout main
git pull

This ensures you're working from the latest version of the project.

Next, create a branch for your task.

git checkout -b feature-login-page

Now you're working in your own isolated environment.

Make your changes, then check what has been modified.

git status

When you're ready, stage and commit your work.

git add .
git commit -m "Add login page"

The branch still exists only on your machine at this point.

To publish it to GitHub, push it to the remote repository.

git push -u origin feature-login-page

Once the branch is online, you can open a Pull Request.

A Pull Request allows other developers to review your work before it becomes part of the main codebase.

After approval, the branch can be merged into main.

Why Use Branches?

At first, branches can feel like extra work. Creating them, switching between them, and opening Pull Requests adds a few more steps to your workflow.

The benefits outweigh that small effort. The biggest advantage is safety. If a feature breaks, the main branch remains untouched.

Users continue using a stable version of the application while you fix the issue. Branches also make teamwork much easier.

Imagine three developers working on different features at the same time. Without branches, everyone would constantly overwrite each other's changes.

With branches, each person can work independently and merge their work when it's ready.

Another benefit is cleaner code reviews. Instead of reviewing weeks of mixed changes, reviewers can focus on one feature or bug fix at a time. That makes mistakes easier to spot and feedback easier to give.

Branches and CI/CD

If you're using a CI/CD pipeline, branches become even more useful. Whenever code is pushed to a branch, automated tests can run before the code reaches production.

This helps catch problems early.Finding those issues before deployment saves a lot of headaches.

Useful Commands

As you work with branches, a few commands become part of your daily routine.

List local branches:

git branch

List local and remote branches:

git branch -a

Switch to an existing branch:

git checkout branch-name

Temporarily save uncommitted work:

git stash

Delete a local branch:

git branch -d branch-name

You don't need to memorize every Git command. These few commands are enough to handle most day-to-day branch management.

What Happens Without Branches?

Many beginners skip branching because they work alone. The problem appears when projects start growing.
A single mistake on the main branch can introduce bugs into working features.

Testing becomes harder because unfinished work gets mixed with stable code.
Eventually, you're afraid to make changes because every update feels risky.

Branches solve that problem by creating a safe space for development.
You can experiment, test ideas, and fix bugs without putting the primary codebase at risk.

Conclusion

Working in branches is one of the habits that separates small projects from professional development workflows.

It keeps your main branch stable, makes collaboration easier, and gives you the freedom to experiment without fear of breaking existing functionality.

If you're still making all your changes directly on main, try creating a branch for your next feature. Make it a habit. It will boost your productivity and make you more confident in exploring what your projects can do without fear of failure.

Proper Variable Naming

Favor Charles Owuor — Mon, 01 Jun 2026 11:09:07 +0000

When I started programming, naming variables was the last thing on my mind. I would use the variables given in YouTube tutorials, that was enough for me.

I would use names like x, temp, data, num, etc. The code ran, so I didn't see the problem.

I would come back to the same project later and spend several minutes trying to remember what those variables actually stored.

That's when I realized variable names are not for the computer. They're for the people reading the code.

Why Variable Naming Matters

A variable is a named storage location in a computer's memory that holds data or values which can change during program execution. To a computer there is no difference when you name a variable x or total_price. To the compiler, both are just labels pointing to data.

The opposite is true for Humans. Imagine opening a project you worked on six months ago and finding something like this:

if balance > amount {
    withdraw = true
}

What are x, y, z, and a? Without context, it's difficult to tell.

Now compare that to:

if account_balance > withdrawal_amount {
    is_withdrawable = true
}

The second example tells a story. You immediately understand what the code is trying to do.

Good variable names improve readability, reduces confusion, and makes maintenance much easier. They also help when debugging.

When an error appears, it's much easier to trace a problem through variables named user_id, total_price, or transaction_date than through variables named id, price, and date.

This becomes even more important when working with other developers. A clear variable name can save several minutes of explanation every time someone reads your code.

Common Naming Mistakes

One mistake many beginners make is choosing names that are too short.

For example:

tp := 1500

What does tp mean?

It could mean total price, transaction processed, temporary product, or something else entirely.

A more descriptive name removes the guesswork:

total_price := 1500

Another common mistake is leaving out important context.
Imagine you have a timeout value:

timeout := 30

Thirty what? Seconds? Minutes? Hours?
Adding the unit makes the meaning clear:

timeout_seconds := 30

Small details like this prevent mistakes that can be surprisingly difficult to track down.

Naming Boolean Variables

Boolean values deserve special attention.

Since they can only be true or false, it's usually best to name them like questions.

For example:

is_logged_in := true
has_permission := false

When these variables are used in conditions, the code becomes easy to read:

if is_logged_in {
    // continue
}

The statement almost reads like plain English.
Compare that to:

if status {
    // continue
}

What does status mean? You have to inspect more code before you understand it.

Consistency Matters

One thing that's often overlooked is consistency.

Most programming languages and teams have naming conventions.

Some use camelCase:

userAge
totalPrice

Others prefer snake_case:

user_age
total_price

The choice matters less than being consistent.
Mixing different styles throughout a project makes the code look messy and harder to follow.

A Simple Rule

When naming a variable, ask yourself: "If someone else reads this six months from now, will they immediately understand what it contains?"

If the answer is no, choose a better name. You don't need extremely long variable names. You simply need names that clearly communicate the purpose.

Conclusion

Proper variable naming seems like a small detail when you're focused on building features. The longer I spent working on projects, the more I realized that poorly named variables create confusion, slow down debugging, and make maintenance harder than it needs to be.

Good names make your code easier to read, easier to understand, and easier to work with. The next time you're creating a variable, spend a few extra seconds choosing a meaningful name.

UI/UX in Design

Favor Charles Owuor — Mon, 01 Jun 2026 10:37:29 +0000

Image by freepik

"Design is not just what it looks like and feels like. Design is how it works."

— Steve Jobs, Co-founder of Apple

When I started building projects, my process was simple. Open VS code, create a database, build features, then figure out the interface later.

It worked. At least that's what I thought.

The problem came when I wanted to add new features or change existing ones. It happened when I was creating a personal finance tool. I created a simple database, and the backend was solid, but I only thought of the core features, not the full scope. So I kept adding features and complicating my workflow.

That's when I realized I had skipped an important step: planning the experience before writing the code.

Let's talk about UI/UX and why it matters.

What is UI/UX?

UI/UX stands for User Interface and User Experience.

User Experience (UX) focuses on how a product works. It answers questions such as:

What problem are we solving?
What does the user want to achieve?
What steps will they take?

User Interface (UI) focuses on how the product looks. This includes layouts, colors, typography, buttons, and other visual elements.

A simple way to think about it is this:

UX makes up the structure.

UI makes up the appearance.

Both work together to create a product that is useful and easy to use.

Why UI/UX Matters

Many developers jump straight into coding. After all, writing code feels like progress.

The issue is that code is expensive to change once a project grows.

Imagine spending weeks building a feature only to realize users cannot find it or do not understand how it works. Now you have to revisit your database, backend logic, frontend pages, and tests.

A simple wireframe could have exposed that problem in minutes.

Good UI/UX helps you:

Find usability problems before development begins.
Build features users actually need.
Reduce development time.
Create a clear roadmap for the project.
Choose technologies based on requirements instead of assumptions.

The Initial Design Process

When planning a product, there are several stages that help turn an idea into something usable.

1. Discovery and Research

Before designing anything, you need to understand the problem.

Who are the users?

What challenges do they face?

How are competitors solving the same issue?

This stage helps prevent building solutions nobody will use.

2. User Flows

Once you understand the problem, map out how users will interact with the product.

For example, if someone wants to create an account, what happens first?

Open website
Click sign up
Enter details
Verify account
Access dashboard

Seeing the entire journey helps identify unnecessary steps early.

3. Wireframing

A wireframe shows individual screens.

Wireframes focus on structure rather than appearance. They answer questions like:

Where should navigation go?
Where should important information appear?
What actions should be most visible?

Tools like Figma and Miro are commonly used for this stage.

4. Interactive Prototyping

Image from clay.global/blog/ux-guide/prototyping

A prototype shows how those screens creating in wireframing are connected.

Users can click through the design and simulate real interactions before any code is written.

This makes testing ideas much faster and cheaper.

5. Visual Design and Handoff

After validating the structure, visual elements are added.

This includes:

Colors
Typography
Icons
Buttons
Spacing

Why Developers Should Learn UI/UX

You do not need to become a professional designer. But understanding UI/UX makes you a better developer.

I've made projects with excellent code but poor usability. Technically they worked, but users struggled to achieve basic tasks.

Learning design helps you think from the user's perspective rather than the system's perspective.

Some benefits include:

Higher Demand

Companies want products that people enjoy using. Developers who understand users bring additional value to a team.

Less Rework

A few hours spent designing can save days of rewriting code later.

Stronger Portfolio Projects

Employers are often interested in how you think, not just what you build.

Showing research, wireframes, and user flows demonstrates problem-solving ability.

Useful Across Industries

Design thinking applies to technology, business, marketing, and product development.

Easy to Start

You can begin learning UI/UX without writing a single line of code.

Conclusion

I used to think that design is only meant for the designers and front end developers. Now I'm not an expert because I only recently leant this, but I realized that planning before coding saves a lot of time and frustration.

A good design helps you understand the problem, organize your ideas, and create products people can actually use. It also allows one to view the scope of what's possible and what's not.
Before starting your next project, try spending some time on research, user flows, and wireframes first.

You might be surprised by how much simpler your work will be even before writing your first line of code.

Why you should Deploy early and often

Favor Charles Owuor — Fri, 29 May 2026 14:15:19 +0000

Image by freepik

Create a project and ensure it has all the features first then and only then can I deploy it. That's something most of us have done, right? Though you may have not thought or said the same thing word for word, but it's something that just happens sub-consciencely. Basically like habit and it does not seem to have any issues. So why would you change your current normal balance to now start deploying work that's incomplete? Let's explore this question together.

Deploy early and often

This is a software development philosophy that prioritizes frequent, smaller releases over long, feature-heavy development cycles. This approach creates a rapid, tight feedback loop with users while eliminating the risk of building software no one actually wants. It's also known as RERO: Release Early, Release Often

The thing is, your project might work fast and efficiently in your local host environment. Where there is one user, the hardware would be dedicated to that task alone at the time of testing, and no major issues. But when you deploy there's differences in latency, infrastructure and the users.

I heard from another developer that he once deployed a website and minutes later the site crashed. Reason being, one of the users had sent many requests in a short period of time. Another one's account creation failed because they added an emoji to their user name.

These are all variables that would not be considered in a local environment. Putting your work out there as you develop it allows you to identify weak points and problems you normally wouldn't experience alone.

Why Deploy Early and Often?

Faster Feedback Loops: Getting a Minimum Viable Product (MVP) to users early ensures customer preferences guide the product, saving hundreds of hours of guesswork. They can also show errors and issues that the product may have that you may not have seen in the planning or creation process
Easier Debugging: Deploying smaller batches of code makes tracking down and fixing bugs easier, as there are fewer variables and lines of code changed at any given time.
Reduced Release Stress: Long periods between releases generate pressure, making deployments risky and complicated. Making deployments a normal, frequent occurrence turns them into a routine, and low risk. When you have many features at hand and want to release them all at once the likely hood of one of them failing silently is high. I once deployed a project and there were many silent errors in different parts, but when looking at the code, there were no error indicators anywhere.
Higher Quality: It shifts the mindset from chasing "full-featured perfection" to continuous improvement and user-defined validation. It's better to work step by step and "perfect" features as you go. Since you will be sure of the working features, your attitude towards the project rises as stress reduces since you have the time and effort dedicated to making the next thing.

How to Implement It Effectively

Deploying isn't just one and done. You need to implement and use the proper tools and practices to ensure a smooth development journey. If done right It will allow you to focus on creation and innovation.

Automation:
Use a CI/CD (Continuous Integration/Continuous Deployment) pipeline that automatically builds, tests, and deploys code changes. This makes it so that you always deploy projects that are stable and work according to spec
Feature Flags:
Utilize feature flags (toggles) to merge features into the main branch but hide them from users until they are officially ready. This allows continuous deployment without exposing incomplete features. You may have select users as testers. They will ascertain if the features that you have pushed work as intended.
Solid Rollback Plans:
When automating deployments, ensure your infrastructure allows you to quickly roll back to the previous stable version if something breaks. This is more frequent than one might realize. You might push a feature to production, then it breaks everything. It's important to note that having versions that are close in terms of times they were developed makes it easier to restore. That's why having updates that are few and far between can really hurt when the rollback happens.

Conclusion

A product that “works but", fails at the critical moment is of eploy early and often help you frustrating, and most developers have experienced it. That’s why the ideaa bitter experience I'm sure most of us have experienced. But having the concept of "Deploy early and often” matters. It" though long can helps you catch issues sooner, improve reliability, and keep your system ready for real use at any timebuild better and working systems always ready for action. If you haven’t started doing this yet, now is a good time as any. It'll save you a lot of stress and worries in the long run.

Beginner steps into CI/CD

Favor Charles Owuor — Tue, 26 May 2026 09:28:22 +0000

Image by freepik

Most people me included, just use Github as kind of like an online store for code. But this application has more to it than meets the eye.

What is CI/CD

Continuous Integration (CI): Is the of automation of the process of merging code changes. It's typically trigged on every push or pull request, running automated tests and builds to detect bugs early.
Continuous Deployment/Delivery (CD): Automatically prepares or pushes tested code to a production environment once the CI checks pass

These series of events can help cut down on the time and effort spent on the manual tasks. They can be summarized in the image below.

How you can do it

Step 1: Create your workflows

In CI, there's four key concepts one should know i.e. trigger, workflow, job and step.

A trigger is what will cause the CI process to start
Workflow is the automation file(.yml)
Job is a group of steps on one machine
Step is a single command or action

To begin we first create a .github directory. Inside we create a workflows folder. Inside we create out ci.yml file. The structure should look like this:

Step 2: Define triggers

For this instance we want the process to start when someone performs a pr but you can set it to push as well

name: CI Pipeline

# TRIGGERS
on:
    push:
        branches: [main]
    pull_request:
        branches: [main]

Step 3: Define Jobs

Jobs work in Isolated Environments. Every job runs inside its own fresh virtual machine (called a runner), such as Ubuntu, Windows, or macOS.
If your workflow has multiple jobs, GitHub runs them at the same time to save time.
A job groups together a series of sequential tasks (steps) that handle the actual work.

# JOBS
jobs:
    test:
        runs-on: ubuntu-latest # The machine to use

        steps:
            ...

Step 4: Define Steps

Steps are the individual, sequential tasks that execute inside a single job. They run one after another, in the exact order they are listed in the YAML file.
All steps in a single job run on the same virtual machine instance. If Step 1 creates a file or installs a package, Step 2 can use it.
In case any step fails (returns an error code), the job stops immediately, and the remaining steps are skipped.

steps:
      # Step 1: Get the code
      - name: Checkout Github code
        uses: actions/checkout@v4

      # Step 2: Set up Node.js
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
        ...

That there was a simple CI pipeline now of to the CD.

Step 5: Deployment cycle

Similar to the CI structure, the CD is also made in the same structure but the steps differ.
They go from tests, if they pass then to the build. Upon successful build the project is then staged and finally pushed to production.

name: Deploy

on:
  push:
    branches: [main]

# Prevent multiple deployments at once
concurrency:
  group: deployment
  cancel-in-progress: false

jobs:
  # First: Run tests
  test:
    name: Run Tests
    ...

  # Second: Build the project
  build:
    name: Build
    runs-on: ubuntu-latest
    needs: test
    steps:
      ...

  # Third: Deploy to staging
  deploy-staging:
    name: Deploy to Staging
    runs-on: ubuntu-latest
    needs: build
    environment: staging        # Requires environment approval (optional)

    steps:
      ...

  # Fourth: Deploy to production (manual approval)
  deploy-production:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: deploy-staging
    environment: production     # Can require manual approval in GitHub settings

    steps:
      ...

But this is just an example, to better understand see the video here or see this github repo. It will provide a wider view and context

Why do this

Short answer: Speed. Organizations that have mastered the CI/CD, build and deploy products faster than others. Since products are always being rated and feedback being provided. Developers commit smaller changes more often, hence keeping up with customer demands.
With ongoing feedback, developers are constantly making small changes.
Automated continuous testing ensures that the codebases remain stable and ready for deployment at all times. Since the manual tasks are taken care of with this automation, developers can focus on creation, innovation, and other important tasks

Conclusion

I'm also still learning about this concept and implementing it into my own workflow. It's a core skill that I believe every developer should enforce in their workflows especially junior developers. It's a major time saver and also ensures you always have working code ready for production.

Logs in code

Favor Charles Owuor — Mon, 25 May 2026 11:44:00 +0000

Image from thumbs.dreamstime.com

When writing code, many developers especially junior level, don't understand the importance of having logs in their code. I was also a victim of this. This article will delve a bit into the importance of logs in your development cycle and how you can implement them.

The Importance

So recently I've been developing a personal finance tool. When trying to do add a transaction performed it brings errors but they don't state where the issue is.

This is what is be displayed on the website:

It shows there's an issue in the way the time is being parsed. The bigger issue is that the error message is being displayed to the user which is a mistake on my part. Still, this would be better shown in the logs. As for the logs, this is what is displayed:

The image just shows that there was a bad request and nothing else, no context. So I didn't even know where to begin with in terms of fixing my code.

Back to the matter at hand, the importance of adding logs to your code. So what exactly is logging?

Logging can be defined as writing text describing what’s been happening in your program to a file or other storage system. Logging is essential for debugging and troubleshooting. When there's a bug, you need to find out which specific part of the program is broken, because it’s often not the part that’s visibly acting weird. This is often the first step in addressing a new bug after reproducing it, or even part of figuring out how to reproduce it.

In fact, logs can be helpful at every stage of the debugging process. You have to confirm your assumptions on what parts are known to work. After all, the whole program is supposed to work, and often times, the thing that’s broken is something that you would’ve assumed definitely worked.

How to implement it

So I got to work and added a few lines of code to see the actual reason why the transactions were not being created.:

The code initially just returned the err, but the slog.Error code allows for a more detailed error to be shown in the logs. Like so:

The line in red is:

{
"time":"2026-05-25T10:47:02.872094934Z",
"level":"ERROR",
"msg":"CreateTransactions failed",
"user_id":"a7e2fa58-712c-4fed-9783-35272ea7e2a1",
"account_id":"1ad6e60e-b104-4dc4-91d7-b22de26ee972",
"amount":2300,
"type":"expense",
"error":"Type can only be income or exepense"
}

As you can see in the logs, the error is more detailed and I can see that the error is a typo in my own code base, since it is an error 500(internal). So Upon closer inspection of my code I realized, that I wrote something entirely different.

Instead of expense I wrote:

That's an error on my part(coding while tired). but I wouldn't have known to go back to my code and check, if I didn't have that error message.

So for you the reader you:

1. Choose a Standard Library or Framework

Avoid using print() for permanent logging, as it lacks control over levels and destinations. Use established tools for your language:

Python: The built-in logging module.
Java: Log4j2 or Logback via SLF4J.
Node.js: Winston or Bunyan.
Go: Log
Rust: The log crate facade

2. Define Severity Levels

Categorizing messages will allow you to filter logs in different environments (e.g., show only errors in production but everything in development).

DEBUG: Detailed information for diagnosing problems during development.
INFO: Confirmation that things are working as expected (e.g., service started).
WARNING: Indication that something unexpected happened, but the software is still working.
ERROR: Serious problems where a specific function failed to execute.
CRITICAL: Fatal errors indicating the program itself may be unable to continue.

3. Configure Loggers, Handlers, and Formatters

A strong setup has three main components:

Loggers: The entry point where your code sends messages (e.g., logger.info("Starting process")).
Handlers (Appenders): Determine where the logs go—such as the console, a local file, or a remote server.
Formatters: Define the layout of the log message. A standard format includes: [Timestamp] [Level] [Source/Module] [Message].

4. Best Practices for Better Logs

Structured Logging: Use JSON or key-value pairs instead of plain text to make logs easily searchable by machines.
Include Context: Log useful identifiers like user_id or transaction_id, but never log sensitive data like passwords or credit card numbers.
Log Exceptions: In try-except blocks, use logger.exception() to automatically capture the full stack trace.
Use UTC Timestamps: Standardizing on UTC avoids confusion when working across different time zones.
Centralize Configuration: Configure logging once at the project's entry point (e.g., your main.py or App.java) rather than in every individual file.

Conclusion

Working with logs has saved me a lot of time in debugging and looking for errors where none can be seen. In development its easier to spot issues but in production it can be a nightmare. I encourage every developer especially the beginners to start using logs as early as your current project. It'll save you a lot of time and make your development journey a little bit easier.

Understanding Back-End Project Structures in Go: A Guide to Separate Concerns

Favor Charles Owuor — Wed, 11 Mar 2026 10:11:18 +0000

Code on laptop with hands typing in the dark Free Photo

When I first started writing Go to make a back-end API, I did what most people do — threw everything into one file. The handler, the business logic, the database calls, all of it crammed together. It worked, until it didn't. The moment I tried to refactor or write tests, three things broke. Sound familiar?

The fix isn't complicated, but it does require a bit of upfront thinking about how you organize your code. In this article I'll walk through a project structure that I learned recently. Companies like Uber and Netflix use similar patterns to manage large systems. It allows for scaling while remaining resilient to failures.

Why Bother Separating Concerns?

Most developers have all written messy code at some point. But once things are separated, the breathing room allows for testing, changes and reuse.

The idea behind separation of concerns is simple: each part of your code should have one job and one job only. When your handler is doing database queries and business logic, changes and tests can get tedious

The Four Layers

For this project we use four layers:

Model — the data structure
Repository — database access
Service — business logic
Handler — HTTP request handling

The payoff is that the same core logic runs with different routers (standard net/http, Gin, or Chi) and different databases (SQLite or MongoDB) without touching the middle layers at all.

1. Model

This is just the shape of your data. No HTTP, no database — just a structure, or skeleton.

type Todo struct {
    ID        string
    Title     string
    Completed bool
    CreatedAt time.Time
}

Everything else in the app revolves around this.

2. Repository

The repository is the only layer that talks to the database. Everything above it just calls repository methods.

You define an interface first:

type TodoRepository interface {
    Create(todo Todo) error
    GetByID(id string) (Todo, error)
    GetAll() ([]Todo, error)
    Update(todo Todo) error
    Delete(id string) error
}

Then you implement it for each database. Want to switch from SQLite to MongoDB? Write a new implementation, swap it in — nothing else changes.

3. Service

This is where your actual business logic lives. The service interact with whatever database being used, and it has nothing to do with HTTP. It just takes inputs, does something meaningful with them, and returns a result.

type TodoService struct {
    Repo TodoRepository
}

func (s *TodoService) Create(title string) (Todo, error) {
    todo := Todo{
        ID:        uuid.New().String(),
        Title:     title,
        Completed: false,
        CreatedAt: time.Now(),
    }
    err := s.Repo.Create(todo)
    return todo, err
}

Notice it only knows about the repository interface. That's the point.

4. Handler

Handlers sit at the edge of the application and deal with HTTP. They decode requests, call the service, and write responses.

func (h *TodoHandler) Create(w http.ResponseWriter, r *http.Request) {
    var req struct {
        Title string `json:"title"`
    }

    json.NewDecoder(r.Body).Decode(&req)

    todo, err := h.Service.Create(req.Title)
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(todo)
}

Because handlers only talk to the service (not the database), you can write different handlers for different routers — standard net/http, Gin, Chi — and they all call the exact same service methods underneath.

How It All Fits Together

Here's the flow when a request comes in:

HTTP Request → Handler → Service → Repository → Database

And back:

Database → Repository → Service → Handler → HTTP Response

Each layer only knows about the one directly below it. The handler doesn't know about the database. The service doesn't know about HTTP. The repository doesn't know about business logic. No bleed-through.

In practice, wiring it all together in main.go looks like this:

repo    := repository.NewSQLiteRepo(db)
service := service.NewTodoService(repo)
handler := handler.NewStdHandler(service)
router  := router.NewStdRouter(handler)

Want MongoDB instead? Change one line:

repo := repository.NewMongoRepo(collection)

Want Gin instead of net/http? Change one line:

handler := handler.NewGinHandler(service)
router  := router.NewGinRouter(handler)

The service layer doesn't move. The repository interface doesn't move. Only the edges change.

This is the resulting file structure:

├── cmd
│   └── main.go
├── internal
│   └── handlers
│   └── models
│   └── repository
│   └── services

Wrapping Up

This structure might feel like extra work upfront compared to dumping everything in one file and it is. This is true only for small projects. But the moment you need to write a test, switch a database, or hand the project to someone else, you'll be glad you did it.

I built the full working example of this with a Todo List API — complete with SQLite and MongoDB repositories, and handlers for net/http, Gin, and Chi. Take a look if you want to see all the pieces in place.

Start with this structure even on small projects. It's a habit that pays off fast.