Forem: Silva Chijioke Michael

The dying art of software engineering

Silva Chijioke Michael — Fri, 24 Apr 2026 23:08:44 +0000

There used to be something deeply human about good software.

You notice it in the tone of an API response — not just what it says, but how it says it. You notice it in the user interaction as you move your mouse across that green line on the paystack checkout as follows your mouse.

The difference between something cold and mechanical, and something that feels like it understands the person on the other end.

You feel it in the quiet, almost indescribable satisfaction of finally winning a bug. Not just fixing it — winning it! After hours of chasing shadows, second-guessing your logic, drilling deep into docs, testing out even the low voted and questioning everything… it clicks. And for a moment, it’s just you and the system, in complete alignment.

You find it in the small, almost forgotten artifacts:

// DO NOT REMOVE — fixes production issue from years ago

That comment isn’t just code. It’s history. Context. A whisper from another engineer who stood where you’re standing, trying to make sense of something just as confusing.

Software engineering used to feel like a craft, like carpentry to Jesus, painting to Picasso. It was Closer to art than assembly.

Like any form of art, it rarely starts perfect. A drawing begins as a rough sketch — loose lines, half-formed ideas, something closer to a v1 or a POC than a finished piece. Over time, as the artist understands the subject better, the lines sharpen. The composition settles. It’s redrawn, refined, sometimes completely reimagined.

Software used to follow that same rhythm.

You’d build something rough. Sit with it. Learn from it. Then refactor, redesign, rethink — until what started as a fragile idea became something structured, something scalable, something intentional.

And in that process, you could see the engineer.

Everyone’s code had a signature. You could read it.

You could see the rushed edges of an unrealistic timeline in one place, and in another, the quiet patience of a slow weekend poured into a beautifully crafted function. You could feel experience in the way a system was designed — in data structure choices, in patterns that showed up not because they were trendy, but because they were understood.

The code spoke, because someone had lived through it.

There was also the humbling part of the craft.

Learning a new stack, a new language, a new way of thinking — where suddenly all your experience feels like fluff. The quiet return of imposter syndrome. The frustration of losing your mind for hours, only to find it again in a low-voted Stack Overflow response that somehow says exactly what you needed.

That process wasn’t just about getting things to work. It was about becoming.

But somewhere along the way, things shifted.

What was once a thoughtful, iterative craft is increasingly becoming a system of outputs. The rise of commercialized tooling — and now AI — has made it easier than ever to produce working software. Faster. More efficient. More scalable.

But also… quieter.

That texture — the rough edges, the intentional decisions, the fingerprints of experience — is being flattened. Compressed into something that looks right, works well, passes checks… but says very little.

What used to be nuance has started to feel like fluff — something that can be distilled into a “really good prompt” and handed off to a model that returns industry-standard code on demand.

And it works.

But it doesn’t feel the same.

We don’t sit with problems as long. We don’t wrestle with them the same way. The friction that once forced understanding is slowly being removed, replaced by abstraction upon abstraction. Code still works, but it doesn’t always have blood in it.

And in that shift, something subtle is being lost.

Not our ability to build — we’re better at that than ever — but the authenticity. The unspoken poetry that lived in the work. The sense that behind every line was a person thinking, struggling, deciding ,all gone.

I’ve always been an artist. It’s never really been about the medium.

Whether it’s paint on canvas, spanner in hand, or code in an editor — the instinct is the same. To shape something. To understand it deeply. To leave a piece of myself in it.

And that’s what software used to feel like.

You could see the person in the work — in every line, every doubt, every small breakthrough. All of it is quietly documented in files that eventually compile down to something binary, but never really lose the human story that created them.

Now, more often than not, it just feels… generated, feels like plastic edo beads, useful but meaningless.

This isn’t a rejection of progress. It’s an observation.

Because maybe the art isn’t completely gone.

Maybe it’s just fading into the background — quieter, harder to notice, easier to skip past.

And maybe it still lives in the engineers who care about the tone of a response, who still feel something when they solve a problem, who leave comments not just to explain, but to connect.

I’ve felt both sides of this.

An imposter with coding skills and a false artist with a claude subscription.

Here I am optimizing this article with the GPT-5 model, I poured my heart and some pieces of my soul into couple lines of bad grammar and here you are at the end of a story that is too real to be fake and too plastic to be considered an original idea.

A contradiction of idea and identity.

— Silva Chijioke Michael,
your insincerely,.. I guess.

"depends_on" vs "wait-for-it.sh" in Docker Compose

Silva Chijioke Michael — Thu, 25 Sep 2025 05:21:08 +0000

When working with multi-container setups (for example, an application and a database), it’s important to understand the difference between container startup order and service readiness.

`depends_on`

Ensures a container starts before another.
Example: Your app won’t start until the database container has been launched.
Limitation: It does not guarantee the database is ready to accept connections.

`wait-for-it.sh`

A lightweight shell script that makes one service wait until another is reachable (via TCP).
Example:

CMD ["wait-for-it", "db:5432", "--", "npm", "start"]

This ensures the app starts only after Postgres is ready.

Visual Comparison

Without wait-for-it.sh:

App ----> tries DB   [DB not ready]   → fails

With wait-for-it.sh:

App ----> waits ----> DB ready        → starts successfully

Why prefer `wait-for-it.sh` (or similar scripts)?

Prevents race conditions such as applications crashing on startup.
Works across any service (databases, caches, APIs).
Simple, portable, and avoids complex retry logic in your application code.

Summary

Use depends_on for container startup order.
Use wait-for-it.sh (or healthchecks) for service readiness.

This small distinction saves time, prevents bugs, and ensures smoother container orchestration.

Ensuring Idempotency in Distributed Systems – Lessons from Go & GCP

Silva Chijioke Michael — Mon, 25 Aug 2025 05:11:04 +0000

In distributed systems, failures happen — network glitches, retries, or even duplicate requests. Without proper handling, this can lead to unintended side effects like multiple charges, duplicated tasks, or inconsistent states.

This is where idempotency comes in.

Idempotency means that performing the same operation multiple times produces the same result, no matter how many retries occur. Think of pressing an elevator button — pressing it once or ten times doesn't make the elevator arrive faster; the action has the same effect.

Recently, we refactored parts of our system to ensure idempotency across critical operations. Using Go and Google Cloud Platform (GCP) services like Pub/Sub, we introduced queues and deduplication strategies that guarantee:

No duplicate processing: We track request IDs to ensure each request is processed only once.

Safe retries: If a worker crashes or a request times out, retries don't break consistency.

Deterministic outputs: The same inputs always produce the same result.

A few lessons learned:

Design for retries: Assume every call may happen more than once.

Use queues: use queues with at-least-once delivery (e.g., Pub/Sub) but build deduplication logic into your service.

Keep business logic deterministic: avoid side effects like random values unless controlled.

Implementing idempotency might feel like extra work, but it’s essential for building resilient, fault-tolerant systems, especially at scale.

Have you implemented idempotency in your APIs or distributed workflows? How did you handle retries and deduplication?

Solving simple time based problems with go lang.

Silva Chijioke Michael — Mon, 13 May 2024 11:25:33 +0000

so interestingly i was assigned a task i really enjoyed, this had to do with repeatedly looping over a set of documents in the db, making some transactions and finally updating documents based on certain conditions.
The first idea was to use a Cron Job(well obviously) everyone knows what a cron job does, but interestingly the problem was to be solved using Go Lang which is one of our stacks on my current team.

I shared the problem with the backend team and we discussed different methods to approach the problem and at the end of the day it boiled down to setting up a cron job that runs repeatedly at “x time” or using the Go timer package.

I used the go timer package and i used it mainly for two reasons:

Ease of use: it was already pre-installed, easy to use and provides a plethora of methods and properties that could be used to solve basically all the problems presented on a low level (it gives total control)
Less complexity: I was already using go lang, there was no real need to install a separate package to over engineer a somewhat simple problem.

Here’s a simple snippet of how to solve the same type of problem:

We define our timed funtion for this example we'll be using the go MongoDB and mux router

// assuming we want the function to run at 12am daily
func initTimer(conn *db.MongoDB, router *mux.Router) {
    currentTime := time.Now()

    // Calculate the duration until 12 AM
    desiredTime := time.Date(currentTime.Year(), currentTime.Month(), currentTime.Day(), 0, 0, 0, 0, currentTime.Location())
    if desiredTime.Before(currentTime) {
        // If 12AM has already passed today, schedule it for 12AM tomorrow
        desiredTime = desiredTime.Add(24 * time.Hour)
    }

    // Calculate the duration until the 12AM
    duration := desiredTime.Sub(currentTime)

    // Wait until it's time to execute the function
    <-time.After(duration)
    go ourTransaction(conn, router)
}

func ourTransaction(conn *db.MongoDB, router *mux.Router) {
   entity := pkg.InitTrxn(conn, router) //init package


    //initial transaction to counter build during updates (optional)
    go entity.RunTrxn()

    // re-run this function every 24hrs by setting up a new ticker using the "time.NewTicker" function
    var ticker *time.Ticker = time.NewTicker(24 * time.Hour)

    //repeat actions at intervals using the "ticker.C" field
    for tickTime := range ticker.C {
        go entity.RunTrxn() // a resource intensive function
        log.Println("i'm running at time:", tickTime)
    }
}

We initialize the timed functions in our main.go package

func main(){
// initialize 
    go initTimer(dbConn, router) // run on a separate thread 
}

In my case the the transaction needed me to make an update base on last action time (..actally i just want to show more stuff done with the go timer package 😏).

package packageName

func (t trxnStruct) RunTrxn() {
       items, err := t.GetAllItems()
       if err != nil{
          log.Panicf("Error at getting items %s", err)
          }

       for _, item := range items {

       // get time difference between last transaction time  and current time using the "time.since" function
         timeDifferenceSinceLastTrxn = time.Since(item.LastTransactionTime)

        inActiveDays := int(timeDifferenceSinceLastTrxn.Hours() / 24) //convert to days
        item.InActiveDays = inActiveDays
         maxdaysofInactivity := 10 

        if item.InActiveDays > maxdaysofInactivity{
           item.Status = constants.INACTIVE 
          }

        t.UpdateItem(item.ID, item) // repo funtion to update DB Record

      }
   return
}

In conclusion, the go timer package is a robust and yet easy to use package with a lot of useful tools to help solve your time based based problems. you can find more info from the docs [https://pkg.go.dev/time]

How I built a multiplayer game with no backend

Silva Chijioke Michael — Tue, 05 Dec 2023 19:48:50 +0000

Crafting Multiplayer X and O Game: A WebSuckit Adventure

Abstract

Join me on a journey into the world of multiplayer online games as we dive into creating a WebSocket-powered tic-tac-toe game. This article aims to demystify the process and provide a hands-on guide for building a real-time gaming experience.

Introduction

Picture this: You built a game about two, three years ago as a yearly vanilla javascript refresher. This was a simple tic-tac-toe game that manipulated arrays, objects, and the browser Dom and this was forgotten somewhere in your GitHub with a "To Do" comment that read "Make this a multiplayer Game".

Fast forward a couple of months into 2023, you reached out to a couple of friends and you get to find out they've been working on a duplex communication platform for developers and there's a need for example projects, and voila! out of the plethora of unfinished chat apps, you remember the "To Do" comment this was almost as perfect as Lee laying that first kick on Gara's head in the season 1 of the Naruto series.

Let's Set the Scene

Before we jump into the coding magic, let's set the stage. Why WebSocket, you ask? Well, WebSocket enables seamless communication between clients and servers, making it ideal for creating responsive and interactive multiplayer games but then I had no intentions of setting up a backend server for the project, I didn't even run a 'node init'.

The Challenge

There were three major challenges, the first was setting up a connection to the native websocket server, the second was managing the logic for the first connection between the initializer and others joining using his URL, and finally managing and communicating disconnections.

The Tech Behind the Magic

WebSuckit 101

First things first, let's get familiar with the star of the show: WebSuckIt. This section serves as your crash course, so buckle up.

Setting Up the Playground

Time to get our hands dirty. We'll set up the environment, initialize the game engine, and lay the foundation for our multiplayer masterpiece.

firstly we introduced our package in our HTML file

    <script src="https://unpkg.com/@websuckit/js/dist/websuckit.umd.js"></script>

Next, we instantiate a websuckit class, to do this we simply had to create an account on websuckit.

navigated to our profile and copied out the necessary credentials required to initialize our class.

const config = {
  PUBLIC_KEY: "your public key",
  USER_ID: "your user ID",
  ACCESS_KEY: "your access key",
};

//ws - Our websuckit class 
const ws = new Websuckit({
  userId: config.USER_ID,
  accessKey: config.ACCESS_KEY,
  publicKey: config.PUBLIC_KEY,
});`

The Gameplay

With the stage set and the tech in place, let the gameplay commence. We'll break down the technical details into bite-sized chunks, exploring each aspect of our game.

Player X vs. Player O

Delve into the intricacies of player interactions. How does the game react when Player X makes a move? How about Player O? We've got it covered.

The Thrill of Victory, the Agony of Defeat

Explore the logic behind determining a winner or declaring a draw. After all, every game needs a champion.

Bringing It to Life

Enough theory; let's bring our creation to life. Follow along as we implement the game, step by step. By the end, you'll have a functioning multiplayer tic-tac-toe game to call your own.

What's in It for You?

Wondering why you should embark on this WebSocket adventure? We'll uncover the benefits, the skills you'll gain, and the sheer joy of seeing your creation in action.

Challenges and Lessons

Every adventure comes with its challenges. We'll navigate through potential pitfalls and share the lessons learned along the way.

Conclusion

As our WebSocket journey comes to an end, take a moment to reflect on the incredible world of real-time gaming you've just stepped into. Cheers to the countless multiplayer adventures that lie ahead!

Join the Fun

Ready to embark on your WebSocket journey? Dive into the code, explore the nuances, and bring your own twist to this multiplayer gaming saga. Let the games begin!

About the Author

Meet [Your Name], a passionate developer with a knack for turning complex concepts into engaging adventures. Connect on [LinkedIn/Twitter/GitHub] for more coding escapades.

Feel free to personalize and adapt this template to match your style and the specific details of your WebSocket gaming experience. Happy writing!