git reset --hard origin/master
rm -rf node_modules # The JS guys need this for good luck

Then go touch grass. Because what you’re about to do is the software industry’s version of yelling “Hold my beer” right before natural selection happens.

The Sacred Law

There’s an unwritten law in software engineering

Thou shall not deploy on Friday after 2p.m unless thou hatest the entire team on-call

This law is older than Docker, older than microservers, even older than companies that have their root branch as “main”. It was written in stone right after “Do not rewrite the entire backend in Rust the week before Black Friday.”

The Five Stages of a Friday Deployment

1. Optimism (2:13p.m)

   “It’s just a one-line change. Literally one line. The tests passed. I can even merge this in my sleep.”

2. Hubris (2:27 pm)

   “This is small, let me make the change ASAP. The evening meeting will swing in my favour. My portrait will hang in the office kitchen, right next to the water dispenser.” or so you tell yourself while patting yourself on the back.

3. The Incident (3:02 p.m)

   Production is now returning 502s. The database is speaking in tongues. The monitoring dashboard looks like a Christmas tree that swallowed a rave. Slack is on fire. The engineering manager is typing “what did you do” with increasing aggression.

4. Bargaining(4.45 p.m)

   You’re about to start the usual “But it’s working fine on my locallhost”. You’re promising the world you’ll now read the “Terms and Conditions” before clicking ‘Agree’ if the logs would give you a clue. You consider sacrificing an intern to the DevOps gods.

5. Weekend through the roof (6:00 p.m - Sunday 11:59 pm)

   You are now legally married to PagerDuty. Your significant other has left you for someone who has weekends. Your cat misses you. Your plants are dead. You haven’t seen sunlight since the release of that first AI-generated video of Will Smith eating spaghetti.

Quotes from Developers who deployed on Friday

• “It was literally a typo in the config” - Famous last words, June 2022

• “The CI passed, why wouldn’t production be fine?” - Man who now sleeps in office, since mid 2025

Rational excuses to avoid Friday deploys

• Sudden religious conversion (you now observe “No-Deploy Jumu’ah”)

• Your cat is having an existential crisis and needs emotional support

• Mercury is in retrograde and Jenkins is moody lately

My thoughts

1. If it can wait until Monday, it must wait until Monday.

2. “it’s just a one-liner” is how every war crime in software history started

3. Schedule the deploy for Monday 9:05a.m. Then immediately book a “dentist appointment” for 9:00-11:00a.m. You’re welcome.

Deploying on Friday isn’t brave. It isn’t dedication to the craft. It’s just performance art titled “How to convert weekend plans into PTSD”. And if you absolutely must deploy on Friday, atleast update your LinkedIn to “Open to Work” first.

Thank you very much for your attention to this matter. Now go forth and sin no more…

I have been a backend guy for some time now, dealing with APIs, queues, databases, and the usual grind that keeps systems running. Now I’m on a deliberate mission to level up my entire stack starting with foundation technologies that many people skip, then build all the way up to production-grade machine learning.

This blog is my live journal of that journey.

No polished courses, no fake expert vibes, just me figuring it out step by step, sharing some notes, dumb mistakes, and the “Hmm, that actually worked” moments when they happen.

What You’ll See Here

I am tackling this in a very intentional order:

1. Cloud Networking:

I realised most cloud problems like latency, costs, outages, security etc, trace back to networking. So I’m going hard on VPCs, peering, load balancers, firewalls, private service access, hybrid connectivity, and all the invisible plumbing that makes or breaks production cloud environments. Expect lots of “why is this taking so long?” Posts, terraform configs that finally fixed my egress bills, and stories from when I accidentally open-sourced my entire subnet (no, it won’t happen😂).

2. Cloud Computing:

Once networking feels rock-solid, I’ll move into the broader cloud picture. I’ll take on the real horror stories of IAM, observability, cost optimisation, serverless vs GKE vs VMs, disaster recovery, and how to actually design systems that don’t explode at 3 a.m. This is where I’ll start connecting the dots between backend habits and cloud-native thinking.

3. AI/ML and MLOps:

After I’m confident in the infrastructure, I will go all-in on machine learning and MLOps. I want to build production-ready pipelines on Vertex AI, Kubeflow, feature stores, model monitoring, and everything that makes AI actually shippable and not just Jupyter notebooks. By the time I get there, I’ll have the networking and cloud foundation to understand why things break in production, not just how to train a model.

What to expect along the way

• Spontaneous updates: I’ll post when I learn something, not when the calendar says so.

• First-person battle stories: If I run into something and I find it interesting after solving it, I am definitely sharing that one.

• Code, configs, and commands: Copy-paste ready snippets with explanations of what I tried and failed before.

• Zero fluff: I have no intention of selling courses, and I’m not pretending to have all the answers. I am just documenting my past so you can skip the same pain.

Why I’m sharing this publicly

• Writing forces me to understand the material.

• If my mistakes and breakthroughs can save even one person the same late-night Google rabbit holes, it’s worth it

• I want to look back in a year and see how far I’ve come

How to follow the Journey

• New posts will drop whenever something worth sharing happens (no fixed schedule).

• I’ll cross-post or share summaries on LinkedIn, X, dev.to, or Reddit

• If you want to ride along, subscribe here, on X or LinkedIn so you can know as soon as I drop something

Now that this is known, let me get cooking. See you in the next one