DEV Community: Favor Charles Owuor

SOLID

Favor Charles Owuor — Mon, 12 Oct 2026 11:07:06 +0000

I'm not talking about a state or matter but a set of five design principles for object-oriented programming:

Single Responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion.

Introduced by Robert C. Martin, they describe how classes and modules should be structured so that code stays maintainable, extensible, and testable as it grows.

Each principle addresses a different aspect of class design — how much a class should do, how it should handle change, how sub-types should behave, how interfaces should be shaped, and how dependencies between modules should be organized.

Together they form a general vocabulary for describing what "good" object-oriented design looks like, and why certain structures tend to hold up better than others over time.

These principles are as follows:

1. Single Responsibility Principle

A class should have only one reason to change — meaning it should be responsible for a single part of the system's functionality.

Suppose you need to build a class that handles a customer's order: it validates the order, calculates the total price, and sends a confirmation email once the order is placed. Take this for example:

class Order {
  constructor(
    private items: { name: string; price: number; quantity: number }[],
    private customerEmail: string
  ) {}

  validate(): boolean {
    return this.items.length > 0 && this.items.every(item => item.quantity > 0);
  }

  calculateTotal(): number {
    return this.items.reduce((sum, item) => sum + item.price * item.quantity, 0);
  }

  sendConfirmationEmail(): void {
    const total = this.calculateTotal();
    console.log(`Sending email to ${this.customerEmail}: Your order total is $${total}`);
    // actual email-sending logic would go here
  }
}

const order = new Order(
  [{ name: "Keyboard", price: 50, quantity: 1 }],
  "customer@example.com"
);

if (order.validate()) {
  order.sendConfirmationEmail();
}

For a small system that's easy to write and easy to read.

Now suppose the business wants to switch email providers, or add a second notification channel like SMS. That logic lives inside Order, so changing it means editing the Order class directly. Anyone doing so is also touching the same class responsible for validation and price calculation — a change intended only for notifications now carries risk for unrelated logic.

The same problem appears in reverse: a change to how totals are calculated (say, adding tax) also happens inside a class that has nothing to do with tax rules conceptually, and everything to do with orders, emails, and validation all at once.

As Order grows, the probability of it getting bloated is 1.0. To prevent this, the various feature inside need to be placed separately as shown:

class Order {
  constructor(
    public items: { name: string; price: number; quantity: number }[],
    public customerEmail: string
  ) {}
}

class OrderValidator {
  validate(order: Order): boolean {
    return order.items.length > 0 && order.items.every(item => item.quantity > 0);
  }
}

class OrderCalculator {
  calculateTotal(order: Order): number {
    return order.items.reduce((sum, item) => sum + item.price * item.quantity, 0);
  }
}

class OrderNotifier {
  constructor(private calculator: OrderCalculator) {}

  sendConfirmationEmail(order: Order): void {
    const total = this.calculator.calculateTotal(order);
    console.log(`Sending email to ${order.customerEmail}: Your order total is $${total}`);
  }
}

const order = new Order(
  [{ name: "Keyboard", price: 50, quantity: 1 }],
  "customer@example.com"
);

const validator = new OrderValidator();
const calculator = new OrderCalculator();
const notifier = new OrderNotifier(calculator);

if (validator.validate(order)) {
  notifier.sendConfirmationEmail(order);
}

Order is now just a data structure. Validation, total calculation, and notification are each handled by a separate class, and each of those classes has exactly one reason to change: OrderValidator changes only if validation rules change, and the same is true for the others.

Each class is now easier to test in isolation — testing OrderCalculator no longer requires a valid email address or triggering an email send, since those concerns no longer live in the same object.

This is the core of the Single Responsibility Principle: not that a class should have only one method, but that everything inside a class should change for the same reason. When it doesn't, splitting the class along those reasons is usually the fix.

2. Open/Closed Principle

Software entities (classes, modules, functions) should be open for extension but closed for modification — you should be able to add new behavior without changing existing code.

Suppose the order system needs to support two payment methods: credit card and PayPal.

class PaymentProcessor {
  processPayment(method: string, amount: number): void {
    if (method === "credit_card") {
      console.log(`Charging $${amount} to credit card`);
      // credit card charging logic
    } else if (method === "paypal") {
      console.log(`Charging $${amount} via PayPal`);
      // PayPal charging logic
    } else {
      throw new Error("Unsupported payment method");
    }
  }
}

const processor = new PaymentProcessor();
processor.processPayment("credit_card", 100);
processor.processPayment("paypal", 50);

This handles both payment methods correctly, and adding a condition for a new one seems simple enough on the surface.

Now the business wants to add cryptocurrency as a payment option. The easiest fix is another else if branch inside processPayment, right?. That means opening a class that already works, editing a method that already handles two other payment types correctly, and hoping the new branch doesn't interact badly with the existing ones.

As more payment methods get added, this method keeps growing, and every addition means modifying code that has nothing to do with the new payment type but sits in the same function. A typo or an unintended side effect in the new branch also risks breaking the branches already in production, since they all now live in the same block of conditional logic.

PaymentProcessor isn't closed to modification — every new payment method requires changing it directly.

interface PaymentMethod {
  pay(amount: number): void;
}

class CreditCardPayment implements PaymentMethod {
  pay(amount: number): void {
    console.log(`Charging $${amount} to credit card`);
  }
}

class PayPalPayment implements PaymentMethod {
  pay(amount: number): void {
    console.log(`Charging $${amount} via PayPal`);
  }
}

class CryptoPayment implements PaymentMethod {
  pay(amount: number): void {
    console.log(`Charging $${amount} via cryptocurrency`);
  }
}

class PaymentProcessor {
  processPayment(method: PaymentMethod, amount: number): void {
    method.pay(amount);
  }
}

const processor = new PaymentProcessor();
processor.processPayment(new CreditCardPayment(), 100);
processor.processPayment(new PayPalPayment(), 50);
processor.processPayment(new CryptoPayment(), 25);

PaymentProcessor no longer contains any knowledge of specific payment types. It depends only on the PaymentMethod interface and calls .pay(), regardless of which implementation it receives. Adding a new payment method — say, bank transfer — means writing a new class that implements PaymentMethod, without touching PaymentProcessor or any of the existing payment classes at all.

This is what "open for extension, closed for modification" means in practice: the system gains new behavior through new code, not through edits to code that already works. Each payment method is also isolated from the others, so a bug in CryptoPayment has no way of affecting CreditCardPayment or PayPalPayment, since they no longer share a function body.

The mechanism enabling this is polymorphism — processPayment operates on the PaymentMethod interface rather than on concrete classes, which is also the seed of Dependency Inversion, covered later in this article.

3. Liskov Substitution Principle

Objects of a subtype must be usable anywhere the base type is expected, without breaking the correctness of the program. A subclass should honor every guarantee its parent class makes.

Suppose the order system needs to support refunds. Standard orders can be refunded, and a gift card order is a special kind of order that gets created the same way and flows through the same system.

Initial code

class Order {
  constructor(public id: number, public total: number) {}

  refund(): void {
    console.log(`Order ${this.id} refunded: $${this.total}`);
  }
}

class GiftCardOrder extends Order {
  refund(): void {
    throw new Error("Gift card orders cannot be refunded");
  }
}

function processReturns(orders: Order[]): void {
  for (const order of orders) {
    order.refund();
  }
}

const orders: Order[] = [
  new Order(1, 80),
  new GiftCardOrder(2, 50),
  new Order(3, 120),
];

processReturns(orders);

GiftCardOrder is an Order as far as TypeScript is concerned, so it fits into the array without complaint, and the code compiles.

Running processReturns refunds order 1, then throws on order 2, and order 3 is never processed. The function was written against Order, and Order promises that refund() works. GiftCardOrder accepts the type but breaks the promise.

The compiler offers no help here, since the signatures match exactly. The failure only appears at runtime, and only when a gift card order happens to be in the list. The usual workaround is to add a check inside processReturns, such as if (order instanceof GiftCardOrder) continue;. That fixes the symptom but puts knowledge of a specific subtype into code that was supposed to work with any Order. Every new non-refundable order type would need another check.

Changed code

class Order {
  constructor(public id: number, public total: number) {}
}

interface Refundable {
  refund(): void;
}

class StandardOrder extends Order implements Refundable {
  refund(): void {
    console.log(`Order ${this.id} refunded: $${this.total}`);
  }
}

class GiftCardOrder extends Order {
  // no refund method: it makes no promise to refund
}

function processReturns(orders: Refundable[]): void {
  for (const order of orders) {
    order.refund();
  }
}

const standardOrders: Refundable[] = [
  new StandardOrder(1, 80),
  new StandardOrder(3, 120),
];

processReturns(standardOrders);

const giftCardOrder = new GiftCardOrder(2, 50);
// processReturns([giftCardOrder]); // compile error: not Refundable

The original design made a promise in the base class, refund() works on every Order, and then broke it in a subclass. The refactor stops making that promise at the Order level. Refunding is now a capability described by the Refundable interface, and only classes that can actually refund implement it.

processReturns now accepts Refundable[], so it can only receive objects that honor the contract. Passing a GiftCardOrder is a compile-time error rather than a runtime crash, and the function needs no instanceof checks. Any new refundable order type works with it automatically, and any non-refundable one is excluded by the type system.

This is the Liskov Substitution Principle: wherever a type is expected, any of its subtypes must work without surprises. A subclass that throws on an inherited method, returns nonsense, or silently does nothing is a signal that the inheritance hierarchy is modeling the wrong relationship. The fix is usually to move the behavior out of the base type and into a narrower abstraction that only the compliant types share.

4. Interface Segregation Principle

No class should be forced to implement methods it does not use. Interfaces should be small and focused, so that implementers only depend on what is relevant to them.

Suppose the order system needs to handle two kinds of orders: physical orders, which are validated, paid for, shipped, and confirmed by email, and digital orders, such as software downloads, which go through the same flow except that there is nothing to ship.

interface OrderProcessor {
  validate(): boolean;
  chargePayment(): void;
  shipOrder(): void;
  sendConfirmation(): void;
}

class PhysicalOrder implements OrderProcessor {
  validate(): boolean {
    return true;
  }

  chargePayment(): void {
    console.log("Charging payment for physical order");
  }

  shipOrder(): void {
    console.log("Shipping physical order");
  }

  sendConfirmation(): void {
    console.log("Sending confirmation for physical order");
  }
}

class DigitalOrder implements OrderProcessor {
  validate(): boolean {
    return true;
  }

  chargePayment(): void {
    console.log("Charging payment for digital order");
  }

  shipOrder(): void {
    throw new Error("Digital orders cannot be shipped");
  }

  sendConfirmation(): void {
    console.log("Sending confirmation for digital order");
  }
}

function fulfill(order: OrderProcessor): void {
  if (order.validate()) {
    order.chargePayment();
    order.shipOrder();
    order.sendConfirmation();
  }
}

fulfill(new PhysicalOrder());
fulfill(new DigitalOrder());

DigitalOrder satisfies the interface, so it compiles and can be passed anywhere an OrderProcessor is expected.

OrderProcessor describes everything an order might do, and DigitalOrder is forced to accept a method that has no meaning for it. The only options are to leave shipOrder() empty, which hides the fact that nothing happened, or to throw, as above. Calling fulfill on the digital order charges the payment and then crashes before the confirmation is sent.

The interface also creates a dependency that serves no one. Any code that only needs to charge payments, for example, still has to accept an object carrying shipOrder(), and any change to the shipping signature ripples out to every class implementing the interface, including those that never ship anything.

This has the same symptom as the previous section, a subtype breaking a promise, but a different cause. There the inheritance hierarchy was modeling the wrong relationship. Here the interface itself is too broad, bundling capabilities that not every implementer has.

Changed code

interface Validatable {
  validate(): boolean;
}

interface Payable {
  chargePayment(): void;
}

interface Shippable {
  shipOrder(): void;
}

interface Notifiable {
  sendConfirmation(): void;
}

class PhysicalOrder implements Validatable, Payable, Shippable, Notifiable {
  validate(): boolean {
    return true;
  }

  chargePayment(): void {
    console.log("Charging payment for physical order");
  }

  shipOrder(): void {
    console.log("Shipping physical order");
  }

  sendConfirmation(): void {
    console.log("Sending confirmation for physical order");
  }
}

class DigitalOrder implements Validatable, Payable, Notifiable {
  validate(): boolean {
    return true;
  }

  chargePayment(): void {
    console.log("Charging payment for digital order");
  }

  sendConfirmation(): void {
    console.log("Sending confirmation for digital order");
  }
}

function charge(order: Validatable & Payable): void {
  if (order.validate()) {
    order.chargePayment();
  }
}

function ship(order: Shippable): void {
  order.shipOrder();
}

function confirm(order: Notifiable): void {
  order.sendConfirmation();
}

const physical = new PhysicalOrder();
const digital = new DigitalOrder();

charge(physical);
ship(physical);
confirm(physical);

charge(digital);
confirm(digital);
// ship(digital); // compile error: DigitalOrder is not Shippable

The single OrderProcessor interface has been split into four, each describing one capability. DigitalOrder implements only the three that apply to it, so it no longer carries a shipOrder() method that it cannot honor. Attempting to ship a digital order is now a compile-time error instead of a runtime exception.

Each function also declares only what it needs. ship accepts anything Shippable and knows nothing about payment or confirmation, while charge requires Validatable & Payable and nothing more. A change to the shipping interface affects only the classes that actually ship.

This is the Interface Segregation Principle: clients should not be forced to depend on methods they do not use. In practice, an empty method, a method that throws "not supported," or an implementation that ignores half of its interface are all signs that the interface is bundling more than one role. The fix is to split it along those roles and let each class implement only the ones that describe it.

5. Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.

Suppose the order system needs to charge customers through Stripe when an order is placed, and the logic that coordinates placing an order lives in an OrderService class.

Initial code

class StripeGateway {
  charge(amount: number): void {
    console.log(`Charging $${amount} via Stripe`);
    // call to Stripe's API would go here
  }
}

class OrderService {
  private gateway = new StripeGateway();

  placeOrder(amount: number): void {
    this.gateway.charge(amount);
    console.log("Order placed");
  }
}

const service = new OrderService();
service.placeOrder(100);

OrderService creates its own StripeGateway and uses it directly. The code is short and does exactly what was asked.

Now suppose the business moves to a different payment vendor. OrderService is the class that decides how an order gets placed, yet it contains a hard reference to one specific vendor's class. Switching vendors means editing OrderService, and so does every future switch. If the new vendor's method is named differently or takes different arguments, the call site inside OrderService has to change as well.

Testing has the same problem. placeOrder cannot be run without triggering StripeGateway, because the dependency is created inside the class and there is no way to replace it. In a real system that means a test either hits Stripe's API or cannot exist.

The dependency direction is the issue: the high-level class that holds the business flow depends directly on a low-level class that holds vendor details.

Changed code

interface PaymentGateway {
  charge(amount: number): void;
}

class StripeGateway implements PaymentGateway {
  charge(amount: number): void {
    console.log(`Charging $${amount} via Stripe`);
  }
}

class NewVendorGateway implements PaymentGateway {
  charge(amount: number): void {
    console.log(`Charging $${amount} via NewVendor`);
  }
}

class FakeGateway implements PaymentGateway {
  charged: number[] = [];

  charge(amount: number): void {
    this.charged.push(amount);
  }
}

class OrderService {
  constructor(private gateway: PaymentGateway) {}

  placeOrder(amount: number): void {
    this.gateway.charge(amount);
    console.log("Order placed");
  }
}

// production
const service = new OrderService(new StripeGateway());
service.placeOrder(100);

// switching vendors: no change to OrderService
const switched = new OrderService(new NewVendorGateway());
switched.placeOrder(100);

// testing: no network, and the result can be inspected
const fake = new FakeGateway();
new OrderService(fake).placeOrder(100);
console.log(fake.charged); // [100]

OrderService now depends on the PaymentGateway interface and nothing else. It does not know which vendor sits behind it, and it does not create the gateway itself. The gateway is passed in through the constructor, a technique called dependency injection, and the decision about which implementation to use moves out to the code that builds the service.

The dependency arrows have flipped. Before, OrderService pointed at StripeGateway. Now both point at PaymentGateway: OrderService uses it, and StripeGateway implements it. The abstraction is owned by the high-level side, shaped by what the business flow needs, and the vendor classes conform to it. That reversal is where the name comes from.

Switching vendors becomes a one-line change at the point where the service is constructed, and OrderService is untouched. Testing becomes straightforward too, since FakeGateway can stand in for a real vendor and record what was charged without any network call.

This is the Dependency Inversion Principle: business logic should be written against abstractions, with concrete details supplied from outside. It is also the principle that makes the others pay off in practice. The PaymentMethod interface from Section 2 follows the same pattern, and injecting it into a service would complete the picture.

Conclusion

These five principles describe different parts of class design, but they aren't independent of one another. Single Responsibility splits code along the lines of what changes together. Open/Closed lets new behavior arrive as new code rather than edits. Liskov Substitution and Interface Segregation keep the contracts between types honest, one at the level of inheritance and the other at the level of interfaces. Dependency Inversion points the dependencies at abstractions, so the other four can hold up as the system grows.

In practice they overlap. The PaymentMethod interface from the Open/Closed section is also an abstraction in the Dependency Inversion sense, and the Refundable interface from the Liskov section is a narrow interface in the Interface Segregation sense. A single refactor often satisfies two or three of them at once, which is why they tend to show up together.

They are also guidelines rather than rules. Applied to a small script, splitting every class and adding an interface for every dependency produces more files and indirection than the problem warrants. A reasonable approach is to apply a principle when the code gives a concrete reason: a class that keeps changing for unrelated reasons, a conditional that grows with every new variant, a subtype that throws on an inherited method, an interface with methods some implementers can't honor, or a dependency that makes testing impossible. Used that way, SOLID works as a shared vocabulary for describing design problems and their fixes, and the examples above are meant to make that vocabulary easy to recognize in real code.

For further reading, Robert C. Martin's Agile Software Development: Principles, Patterns, and Practices is where the principles were laid out in full.

Why Documentation Matters More Than You Think

Favor Charles Owuor — Sun, 26 Jul 2026 22:38:19 +0000

"Programs must be written for people to read, and only incidentally for machines to execute." — Donald Knuth

You finally finish your project.

After hours of debugging, Stack Overflow tabs, and one bug after another, it works. You push it to GitHub, close your laptop, and move on.

A few months later, you come back to add a new feature.

You open the repository. Dozens of files. A few variables with names that made perfect sense at the time. Now they don't. You scroll through your own code, trying to remember why you chose this approach over that one.

Eventually you ask the question almost every developer asks:

"Who wrote this?"

You did.

If that sounds familiar, you've already discovered why documentation matters. You don't write it for your teacher, your manager, or your teammates. You write it for your future self — the one who's forgotten everything you know right now.

Photo by Alicia Christin Gerald on Unsplash

The Biggest Myth About Documentation

Most developers treat documentation as something you write after a project is done. That mindset is exactly how projects end up with no documentation at all — "later" rarely comes.

Documentation isn't the final chapter. It's part of building the thing.

You wouldn't wait until a house is finished to draw the blueprint — the blueprint guides the construction. Documentation does the same job for code: it records your decisions and explains your reasoning as you go, not after the fact.

GitHub's own guidance backs this up: a README should explain what your project does, why it exists, how to get started, where to get help, and who maintains it — because for most visitors, it's the first thing they see and it shapes their whole impression of the project.

What Documentation Actually Is

Say "documentation" and people picture a massive technical manual. Sometimes it is that. More often, it's much smaller:

A README
Installation instructions
A comment explaining tricky logic
A troubleshooting note
A changelog

Documentation is just information that helps someone understand your software — where "someone" might be you in six months, a teammate, a contributor, or a recruiter skimming your GitHub. Good documentation answers questions before people have to ask them.

Why Most of Us Skip It And What It Costs

Documentation isn't exciting. Watching your app finally run is exciting. Writing a README is not. So beginners tell themselves "I'll document it later," and later rarely comes.

By the time you return to the project, you've forgotten why you chose that library, what a function actually returns, which environment variables it needs, and which command fixed yesterday's bug. You end up solving the same problem twice — time you could've spent building something new.

GitHub Star Monica Powell calls personal documentation a "second brain": instead of re-searching for the same answer every time, you write it down once, in a way that makes sense to you, and reuse it. That alone is worth the five minutes it takes.

The Hidden Cost of Poor Documentation

Picture two repositories.

Repo A:

project/
├── README.md
├── src/
├── docs/
└── package.json

The README explains what it does, how to install it, how to run it, how to contribute. You clone it and you're running the project in five minutes.

Repo B:

project/
├── src/
└── package.json

That's it. No instructions, no examples, nothing.

Which one feels more trustworthy? Which one would you actually contribute to?

Researchers who studied thousands of GitHub repositories found that the README is often what shapes a developer's first impression of a project and whether they can figure out how to use it at all. Documentation builds trust before anyone even opens your code.

It Also Makes You a Better Developer

It's easy to assume documentation is purely for other people. It isn't. Writing it forces you to answer questions like:

What problem does this actually solve?
Why this approach, and not another?
What am I assuming the reader already knows?

If you can't explain your project clearly, you probably don't understand it as well as you think you do. Writing it down is a forcing function for organizing your own thinking.

Good Documentation Is Short, Not Exhaustive

The other common misconception: good documentation means a lot of documentation. It doesn't. It means the right information.

GitHub's documentation team recommends writing in plain language, staying concise, and structuring content so people can scan for what they need — not covering every possible edge case. One clear paragraph or a single code example often teaches more than three pages of prose. Quantity isn't the goal; clarity is.

A Habit You Can Start Today

Every time you solve a problem that takes more than five minutes, write down four things:

## Problem
The application crashed after deployment.

## Cause
The environment variables weren't configured.

## Solution
Added the missing variables to the production environment.

## Prevention
Add an environment variable checklist before deployment.

That's it. That's documentation. Do this consistently and you'll build a personal knowledge base that gets more valuable every month — your own second brain, one entry at a time.

Beyond the README

A README is the entry point — both GitHub's and Google's engineering style guides treat it that way — but it's not the whole picture. Documentation also lives in:

Code comments
Architecture diagrams
API references
Troubleshooting guides
Changelogs and design decisions

Each one saves someone (probably future you) from having to reverse engineer your reasoning from scratch.

Key Takeaways

Documentation is written for people, not computers.
Your future self is usually your first reader.
Small notes written consistently beat one giant document written at the end.
A good README shapes first impressions and builds trust before anyone reads your code.
Documentation is part of development — not something that happens after it.

Next time you finish a piece of code, don't just ask "is it done?" Ask: "Would someone else know how to use this?"

If the answer is no, your next line shouldn't be code. It should be documentation.

In Part 2, we'll build your first documentation habits; the small routines experienced developers follow without even thinking about them.

How I Learn Any New Language or Framework

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

Image by starline on Magnific

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.