DEV Community: Christian Mbah

Claude Fable 5 Is Here. Here's What Actually Matters for Developers 👨🏾‍💻

Christian Mbah — Tue, 09 Jun 2026 23:22:06 +0000

Anthropic dropped two models today.
Most people are focused on the wrong one.

What launched:

Fable 5 — the public-facing Mythos-class model. Available on Pro, Max, Team, and Enterprise right now. Stronger than anything Anthropic has released publicly.

Better at long-context, agentic coding, vision, and knowledge work. The longer and more complex the task, the bigger the gap between Fable and previous models.

Mythos 5 — same architecture, fewer restrictions. Going out through Project Glasswing to a small group of security providers and government institutions only. You're not getting access to this one. Neither am I.

The catch nobody's leading with:

Fable 5 is free on your subscription until June 22. On June 23 it moves to usage credits.

Pricing is $10/million input tokens and $50/million output tokens — double what you're paying now for Opus.

You have 12 days to hammer it before it costs real money.

What's actually different for developers:

The safeguard fallback is interesting architecture. Sensitive queries — cybersecurity, biology, chemistry — silently fall back to Opus 4.8.

Anthropic says this triggers in under 5% of sessions. If you're building in those domains, test your workflows now because your production behaviour may shift depending on which model actually responds.

For agentic work the jump is real. I build automation workflows with n8n and Claude and the longer the chain, the more Fable pulls ahead. Multi-step reasoning, document processing, complex conditionals — noticeably sharper.

What I'm actually testing this week:

Multi-agent loops on my n8n stack
Long-context RAG retrieval quality vs Opus 4.7
Vision tasks on mixed document types

The bigger picture:

Mythos-class capability is now public. With guardrails, yes — but the ceiling just moved up significantly. The question isn't whether Mythos ever ships publicly. It's how fast this capability tier becomes the default baseline.

Use the next 12 days well.

What are you testing Fable 5 on first? Drop it in the comments.

Build an AI-Powered Lead Follow-Up System with n8n and OpenAI 🚀

Christian Mbah — Mon, 08 Jun 2026 21:52:08 +0000

Let's build an AI-powered lead follow-up system today on n8n.

A webhook captures the lead. OpenAI writes a personalized email.
Gmail sends it. Google Sheets logs it.

Four nodes that runs in under 10 seconds with zero humans in the loop.

By the end of this post you'll have a fully working workflow you can import directly into n8n with the JSON export is at the bottom.

What you'll learn:

How to capture lead data via a webhook trigger
How to use OpenAI (gpt-4o-mini) to write personalised follow-up emails
How to send automatically via Gmail
How to log every lead and email sent to Google Sheets

What You're Building

Here's the flow:

Webhook → OpenAI (personalize email) → Gmail (send) → Google Sheets (log)

A lead submits a form anywhere — your website, Tally, Typeform, whatever. The webhook fires, OpenAI reads their data and writes a personalized follow-up email, Gmail sends it automatically and finally Google Sheets logs the lead and the email that was sent, so you have a record.

No human in the loop. The whole thing runs in under 10 seconds.

Prerequisites

n8n account (cloud or self-hosted — either works)
OpenAI API key
A Gmail account connected to n8n
A Google Sheet to log leads to

Step 1 — The Webhook Trigger

Create a new workflow in n8n. Add your first node: Webhook.

Set the HTTP Method to POST. n8n will generate a unique URL for you. Copy it — this is what your form will POST to.

Your webhook will receive a payload that looks something like this:

{
  "name": "Chris Mbah",
  "email": "chris@example.com",
  "company": "Endy Studios",
  "role": "Founder",
  "message": "Looking for help automating our lead pipeline"
}

The field names will match whatever your form sends. Keep that in mind when configuring the nodes below — you'll reference these fields by name.

Test it: Click "Listen for test event" in n8n, then send a test POST request using Postman or a simple curl command. Once n8n receives it, the data shows up in the node output and you can reference it downstream.

curl -X POST https://your-n8n-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"name":"Chris Mbah","email":"chris@example.com","company":"Endy Studios","role":"Founder","message":"Looking for help automating our lead pipeline"}'

Step 2 — OpenAI (Write the Personalised Email)

Add an OpenAI node. Connect it to the Webhook node.

Set the resource to Message and the operation to Complete.

In the Model field, use gpt-4o-mini. It's fast, cheap, and more than capable for email writing.

In the Prompt field, this is where the personalisation happens. Use n8n's expression syntax to pull in the webhook data:

You are an AI assistant helping a freelance AI automation consultant follow up with new leads.

Write a short, professional follow-up email to a lead with the following details:

Name: {{ $json.name }}
Company: {{ $json.company }}
Role: {{ $json.role }}
Message they sent: {{ $json.message }}

Guidelines:
- Keep it under 120 words
- Sound human, not like a template
- Acknowledge what they said specifically
- End with a clear CTA to book a 20-minute call
- Do not use subject lines or greetings like "Dear" — start directly
- Return only the email body, nothing else

Set Max Tokens to 300. That's plenty for a short follow-up email and keeps your API costs low.

The node output will be a single string — the email body. You'll reference it in the next step as {{ $json.message.content }}.

Step 3 — Gmail (Send the Email)

Add a Gmail node. Connect it to the OpenAI node.

Set the operation to Send.

Configure the fields:

Field	Value
To	`{{ $('Webhook').item.json.email }}`
Subject	`Re: Your enquiry — let's talk automation`
Message	`{{ $json.message.content }}`
Send As	HTML or Plain Text (your preference)

The To field references the original webhook data directly — not the OpenAI output — so make sure you're pulling from the right node. In n8n, you can reference any previous node's output using $('Node Name').item.json.fieldName.

One thing worth noting: the subject line above is generic. You can make it dynamic too. Ask OpenAI to return a subject line alongside the body by adjusting your prompt to output JSON:

Return a JSON object with two fields:
- "subject": a short, specific subject line (max 8 words)
- "body": the email body
Return only valid JSON. No markdown. No backticks.

Then parse it in n8n with a Code node before passing to Gmail:

const response = JSON.parse($input.item.json.message.content);
return { subject: response.subject, body: response.body };

Step 4 — Google Sheets (Log the Lead)

Add a Google Sheets node. Connect it to the Gmail node.

Set the operation to Append Row.

Select your spreadsheet and sheet. Then map the columns:

Column	Value
Name	`{{ $('Webhook').item.json.name }}`
Email	`{{ $('Webhook').item.json.email }}`
Company	`{{ $('Webhook').item.json.company }}`
Role	`{{ $('Webhook').item.json.role }}`
Message	`{{ $('Webhook').item.json.message }}`
Email Sent	`{{ $('OpenAI').item.json.message.content }}`
Timestamp	`{{ $now }}`

This gives you a running log of every lead and exactly what was sent to them. Useful if you ever need to review what went out, or hand things off to a client.

The Full Workflow

Here's what the complete canvas looks like:

[Webhook] → [OpenAI] → [Gmail] → [Google Sheets]

Four nodes. Linear. No branching required for this version.

If you want to add branching later — for example, only email leads who mention a specific intent, or route high-value leads to a Slack notification — you'd add an IF node between Webhook and OpenAI and split the flow from there.

Activating the Workflow

Once everything is tested and working, toggle the workflow to Active in the top right.

From this point on, every POST request to your webhook URL triggers the full sequence automatically. No need to keep the n8n editor open.

If you're self-hosting, make sure your n8n instance is always running. If you're on cloud, it handles that for you.

What This Costs to Run

At current OpenAI pricing, gpt-4o-mini costs roughly $0.15 per million input tokens and $0.60 per million output tokens.

A single lead follow-up — prompt + response — uses around 300–400 tokens total.

That's roughly $0.0001 per lead. You could process 10,000 leads for about $1.

Gmail is free. Google Sheets is free. n8n cloud has a free tier that covers this comfortably.

This entire system runs at near-zero cost.

Full JSON Export

Import this directly into n8n. Go to your workflow, click the menu (⋯), select Import from JSON, and paste this in. Swap in your own credentials and webhook URL.

{
  "name": "AI Lead Follow-Up System",
  "nodes": [
    {
      "parameters": {
        "httpMethod": "POST",
        "path": "lead-followup",
        "responseMode": "onReceived",
        "options": {}
      },
      "id": "webhook-node",
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 1,
      "position": [250, 300]
    },
    {
      "parameters": {
        "resource": "chat",
        "operation": "complete",
        "model": "gpt-4o-mini",
        "messages": {
          "values": [
            {
              "role": "user",
              "content": "You are an AI assistant helping a freelance AI automation consultant follow up with new leads.\n\nWrite a short, professional follow-up email to a lead with the following details:\n\nName: {{ $json.name }}\nCompany: {{ $json.company }}\nRole: {{ $json.role }}\nMessage they sent: {{ $json.message }}\n\nGuidelines:\n- Keep it under 120 words\n- Sound human, not like a template\n- Acknowledge what they said specifically\n- End with a clear CTA to book a 20-minute call\n- Do not use subject lines or greetings like \"Dear\" — start directly\n- Return only the email body, nothing else"
            }
          ]
        },
        "options": {
          "maxTokens": 300
        }
      },
      "id": "openai-node",
      "name": "OpenAI",
      "type": "@n8n/n8n-nodes-langchain.openAi",
      "typeVersion": 1,
      "position": [500, 300]
    },
    {
      "parameters": {
        "operation": "send",
        "toList": "={{ $('Webhook').item.json.email }}",
        "subject": "Re: Your enquiry — let's talk automation",
        "message": "={{ $json.message.content }}",
        "options": {}
      },
      "id": "gmail-node",
      "name": "Gmail",
      "type": "n8n-nodes-base.gmail",
      "typeVersion": 2,
      "position": [750, 300]
    },
    {
      "parameters": {
        "operation": "append",
        "documentId": {
          "value": "YOUR_GOOGLE_SHEET_ID"
        },
        "sheetName": {
          "value": "Sheet1"
        },
        "columns": {
          "mappingMode": "defineBelow",
          "value": {
            "Name": "={{ $('Webhook').item.json.name }}",
            "Email": "={{ $('Webhook').item.json.email }}",
            "Company": "={{ $('Webhook').item.json.company }}",
            "Role": "={{ $('Webhook').item.json.role }}",
            "Message": "={{ $('Webhook').item.json.message }}",
            "Email Sent": "={{ $('OpenAI').item.json.message.content }}",
            "Timestamp": "={{ $now }}"
          }
        },
        "options": {}
      },
      "id": "sheets-node",
      "name": "Google Sheets",
      "type": "n8n-nodes-base.googleSheets",
      "typeVersion": 4,
      "position": [1000, 300]
    }
  ],
  "connections": {
    "Webhook": {
      "main": [[{ "node": "OpenAI", "type": "main", "index": 0 }]]
    },
    "OpenAI": {
      "main": [[{ "node": "Gmail", "type": "main", "index": 0 }]]
    },
    "Gmail": {
      "main": [[{ "node": "Google Sheets", "type": "main", "index": 0 }]]
    }
  }
}

Where to Take This Next

This is the foundation. Once it's running, there are a few natural extensions:

Add lead scoring. Ask OpenAI to rate the lead 1–10 based on their message and role before writing the email. Route low-score leads to a different, shorter email. Route high-score leads to also ping your Slack.

Add a delay. If you want the email to feel less instant (some people find immediate auto-replies suspicious), add a Wait node between OpenAI and Gmail. Set it to 10–15 minutes.

Connect it to your CRM. Swap Google Sheets for a HubSpot or Airtable node. Same logic, cleaner data management.

But start with what's here. Get it running. See leads come in and emails go out automatically.

That's the point of automation — not the complexity. The simplicity.

Building more of these publicly. Follow along if you want to see what comes next.

n8n #automation #openai #tutorial #nocode #webdev #javascript #productivity

n8n Tutorial: How to Build Your First No-Code Automation Workflow in 2026

Christian Mbah — Sat, 06 Jun 2026 19:22:03 +0000

You know that feeling when you're doing the same task over and over again, and you think "there has to be a better way"?

That's exactly what n8n solves. If you've been wondering how to automate tasks without writing code, or you're curious about business automation platforms, you're in the right place.

A few months ago, I would've told you that real automation required code. I was wrong. n8n changed how I think about solving problems, and I want to walk you through it.

This post is for anyone—whether you code or not—curious about automation but unsure where to start.

What is n8n? A No-Code Automation Platform Explained

Think of n8n like a middleman that helps different apps talk to each other and do work automatically.

Let me give you a real example. Say you run a business and you get leads through a Google Form. Right now, here's what happens:

Someone fills out the form
You manually check it
You copy the information to your CRM
You send them a welcome email
You log it somewhere for follow-up

That's five separate steps. Every single time. All day.

With n8n, that entire sequence happens automatically the moment someone fills out the form.

Form submission → CRM entry → Welcome email → Log created → Done.

No one has to touch it. The workflow just runs in the background.

What makes n8n special is that it's not just "connect this to that." It can think. It can ask questions like "Is this a hot lead or a cold lead?" and send people different directions. It can transform data, wait for responses, send multiple messages—all without you writing a single line of code.

How to Think About n8n Automation: Workflows, Nodes, and Triggers

Before we get technical, understand how automation actually works. It's three simple ideas:

Workflows

A workflow is just a plan. Your plan for what should happen and when.

"When a form is submitted, add to CRM and send an email" is a workflow. It's the thing you want to automate.

Nodes

A node is a single step in that plan. "Add to CRM" is one node. "Send an email" is another node.

You build workflows by connecting nodes together. Each node does one job.

Think of it like a recipe. A workflow is the entire recipe. Nodes are the individual steps (mix flour, add eggs, bake, etc.).

Triggers

A trigger is the "when" that starts everything.

"When a form is submitted" is a trigger. "When someone replies to an email" is a trigger. "Every morning at 8 AM" is a trigger.

Without a trigger, nothing happens. The trigger is what wakes up your workflow.

Getting Started: Setting Up Your n8n Account

Before you build anything, you need to get into n8n. The good news? It takes about 5 minutes.

Step 1: Sign up

Go to n8n.cloud and click "Sign up."

You'll need:

Email address
Password
That's it. No credit card required.

n8n offers a free 14-day trial on their cloud version. After that, free tier plans exist, but you have room to explore without paying.

Step 2: Verify your email

Check your inbox. n8n sends you a verification email. Click the link, and you're in.

Step 3: Meet your dashboard

After verification, you'll land on your n8n dashboard. It loads in seconds. You'll see:

Your workspace name (you can change this later)
A big button that says "Create Workflow" or "Start from Scratch"
A list of pre-built templates (you can ignore these for now)

That's it. You're ready to build.

Build Your First n8n Workflow: A Step-by-Step Tutorial

Now let me show you something you can actually build in 10 minutes.

Imagine: Every time someone fills out a contact form on your website, you get a Slack message.

Here's how you'd think about it:

Trigger: Someone submits a form
Action: Send a Slack message

That's it. Two steps. In n8n, that's two nodes connected together.

Step 1: Create your workflow

Click "Create Workflow" (or "Start from Scratch").

You'll see a blank canvas. It's intimidating at first, but it's just empty space waiting for you to add things.

Step 2: Add your trigger (the form)

Click the + button in the center of the canvas.

Search for your form provider. Let's say you use Tally for your contact form.

Click "Tally"
Click "On Form Submit" (this is your trigger)
A node appears on your canvas labeled "Tally"

Step 3: Authenticate Tally

Click the Tally node.

On the right side, you'll see a panel that says "Authenticate." Click it.

n8n opens a popup asking you to log into Tally
You log in
You authorize n8n to access your Tally account
The popup closes. You're authenticated.

Back on the canvas, the Tally node now shows you a list of your Tally forms. Select the form you want to monitor.

Step 4: Add your action (Slack notification)

Click the + button again, this time to the right of the Tally node.

Search for "Slack."

Click "Slack"
Click "Send Message" (this is your action)
A node appears next to Tally labeled "Slack"

Step 5: Authenticate Slack

Click the Slack node.

On the right side, click "Authenticate."

n8n opens a popup asking you to log into Slack
You log in
You authorize n8n
The popup closes.

Step 6: Configure the Slack message

Still in the Slack node panel, you'll see options:

Channel: Select the Slack channel where you want the message (try #general or #notifications)
Message: Type what you want the message to say. For now, something simple like "New form submission received!"

You can make it dynamic later (pulling the person's name from the form, etc.), but keep it simple for now.

Step 7: Connect the nodes

This is the fun part. On the canvas, you should see your Tally node on the left and your Slack node on the right.

On the right side of the Tally node, there's a small dot. Click and drag a line from that dot to the left side of the Slack node.

You'll see a connection line. This tells n8n: "When Tally triggers, send to Slack."

Step 8: Test your workflow

At the top of the canvas, click "Test Workflow" (or "Execute Workflow").

n8n will pretend someone filled out your form and see if it can send the Slack message.

If it works, you'll see:

A green checkmark on both nodes
A message in Slack (in your chosen channel)

If something breaks, n8n will show you an error. It usually tells you exactly what went wrong.

Step 9: Activate your workflow

Once the test passes, click "Activate" at the top right.

Your workflow is now live. Every time someone fills out your Tally form, n8n automatically sends a message to Slack.

And yes, it really is that straightforward.

What Makes n8n Powerful: Real Use Cases for No-Code Automation

Here's the thing that blew my mind: once you understand these basics, you can build almost anything.

You can:

Qualify leads automatically. The form comes in → n8n asks ChatGPT to score it → sends hot leads to your CRM and cold leads somewhere else
Send personalized follow-ups. New customer → pull their info → send custom email → log it
Keep everything in sync. Update Spreadsheet A → automatically updates Spreadsheet B, your CRM, and a backup
Create alerts. When something specific happens → notify the right person on Slack or email

The automation isn't limited to simple "if X then Y" logic. n8n can handle complexity. It's just that most businesses don't need complexity—they need consistency.

And that's where the real value is.

Getting Started (Actually)

Here's your action plan:

Sign up at n8n.io (free cloud version is perfect to learn)
Pick one repetitive task you do manually every week
Break it into steps: What's the trigger? What are the actions? What apps are involved?
Build it. Add nodes, connect them, test, activate
See what happens. Let it run for a week

You'll be surprised how much time it saves.

The hardest part isn't building automation in n8n. The hardest part is identifying what should be automated in the first place.

Once you know what problem you're solving, n8n is just the tool to solve it.

One More Thing

A lot of people think automation means you won't have to work. That's not true.

Automation means you don't have to do repetitive work. You get to focus on the actual problems—the thinking, the strategy, the relationships.

The boring stuff? Let n8n handle it.

I'm building workflows constantly now. Some work perfectly. Some need tweaking. Some teach me something new about how the apps I'm using actually work.

I'll be sharing those learnings here. Workflows I've built, problems I've solved, mistakes I've made.

But the foundation? It's what you've just read.

Start small. Build something. See it work.

Everything else flows from there.

Have questions? Ask in the comments. I'm learning this alongside you, so let's figure it out together.

How Developers Flatline Their Careers — And How to Avoid It

Christian Mbah — Sat, 06 Dec 2025 18:59:27 +0000

Software engineering is one of the most interesting career paths in the world today. In an ecosystem where technologies like artificial intelligence are becoming mainstream every day, it’s no wonder you probably ventured into it out of curiosity, learned tirelessly, and began building a career. Yes, it’s exciting and full of possibilities, but it can also be surprisingly stagnating if you don’t know the right steps to take.

Why? Because software engineering is simply a path, and how you navigate it determines how far you go. For some, it may be a smooth upward slope, steadily rising toward impact and financial freedom. For others, a series of peaks and valleys, a rollercoaster of wins and failures. But for some, there’s an initial rise… followed by a long, flat line.

In medical terms, flatlining means death; in software engineering, it means stagnation. The good news is stagnation isn’t permanent and with awareness, deliberate action, and the right mindset, growth is always possible. So here are 5 ways developers unintentionally flatline their careers, and how to avoid them:

1. Avoiding Communication

You might be able to write bug-free code that works flawlessly, but if you can’t explain your decisions, ask the right questions, or even collaborate effectively, no one will notice. Soft skills aren’t optional in this field; they are the piece that turns programmers into problem solvers with a meaningful impact.

Brilliant engineers can stagnate for years simply because they couldn’t articulate their thoughts or navigate team dynamics because they lack communication skills. I could even argue being invisible in a team is worse than making a mistake, because mistakes are noticed, corrected, and learned from, meanwhile if you're invisible, you're invisible. If you want to stunt your career progress, then reduce communication as much as possible.

2. Relying on AI to Think for You

AI is powerful — insanely powerful, but the truth is that AI only accelerates people who already think well. If you lack fundamentals, AI will become a crutch, not a jetpack.

Rely on AI for every decision and your problem-solving muscles slowly deteriorate. You stop breaking down problems, thinking about design, and understanding why things work. Before you know it, you can generate code, but you can’t debug it… you can ship features, but you can’t explain them.

AI should be your partner, not your brain’s replacement. So if you want your growth to flatline instantly, fully outsource your thinking to AI.

3. Avoiding Project Ownership

There’s a reason people can write code for years and still be seen as “junior.” It’s not skill. It’s not intelligence. It’s ownership. Developers who grow take responsibility for outcomes, not just tasks. They speak up, form opinions, and challenge decisions respectfully. They propose solutions instead of waiting for instructions.

But refusing ownership? That’s the fastest path to staying invisible. You become the person who “just does what they’re told,” and you get treated accordingly.

So if your goal is to remain small forever, avoid ownership at all costs. If not, start taking responsibility.

4. Not Understanding the Business

You don't get employed to write code, you get employed to create an impact by writing code. Engineers who grow fast understand one thing: the business drives everything. Who are we building this for? What problem does it solve? Why does it matter? How does it affect revenue, users, cost, performance, or experience?

Once you understand why something matters, your decisions get sharper, your communication gets clearer, and your contributions get noticed. Seniority is basically the ability to connect code to outcomes.

On the other hand, if you want to remain easily replaceable, focus only on the code and ignore everything else.

5. Never Reflecting or Asking the Hard Questions

You cannot improve if you never pause to see where you are, where you want to go, and what you need to get there. Many developers go year after year without reflecting on what worked, what didn’t, and what they could do differently. Reflection is what turns experience into wisdom. Without it, you’re just moving in circles, accumulating years, but not skills.

Reflection forces you to confront your blind spots, the bugs in your mindset and workflow that no tutorial can fix. It’s uncomfortable, but discomfort is where growth actually lives. So, that being said, if you want to flatline indefinitely, never reflect on your growth.

Conclusion

Growth is about thinking, creating, leading, and connecting. It’s about tackling uncomfortable challenges, building real projects, practicing consistently, communicating clearly, understanding the business, and taking ownership of your impact. Ignore any of these, and you’ll never move forward. Follow them, and even in a year, you’ll look back and be amazed at how far you’ve come. If you think coding harder alone will make you climb up the ranks? Think again.

If you’ve made it this far, ask yourself: are you doing these things, or are you doing what’s easy? Because the difference between being a “developer” and being a “developer who grows” comes down to the choices you make every day.

How to Survive AI as a Programmer

Christian Mbah — Mon, 01 Sep 2025 10:11:37 +0000

As a software engineer you've probably wondered at least once about the impact of Artificial Intelligence (AI) on your long-term career.

Everywhere you look, AI tools are popping up that can write code, fix bugs, and even generate an entire app from scratch in seconds.

At first, it feels cool seeing how much artificial intelligence is growing and how much better it helps you solve coding tasks, but then the bigger question creeps in: if AI keeps getting better, will it eventually replace me in the long run?

Will AI replace software engineers?

Well, yes and no.

AI is already replacing some software engineers and that trend isn’t slowing down, but it won’t replace all of us. That’s the part worth paying attention to and we’ll get into why in a moment, but first let’s acknowledge the obvious: this shift isn’t shocking.

As engineers, we’ve always built tools to replace old ways of working. This is just another wave of disruption, only now we’re the ones in the hot seat. Ironic, isn’t it? Building our own replacement.

And if you think about it, this isn’t a new story. We build new things to improve or replace the old. Spotify reshaped the music industry, Netflix transformed how we watch movies, and Uber changed the way we think about taxis.

But here’s the good news: those older industries didn’t completely disappear. I still went to the cinema last week, taxi drivers migrated to Uber, and people still buy songs. The world changed, but it didn’t end, and the same will be true for software engineering.

Which brings us to the real question: how do you survive, adapt, and stay valuable as a software engineer in the age of AI?

The Engineer Who Stands Out

Fact: Artificial Intelligence can code like crazy.

You already know this so let's build on it. If AI can code, why not think beyond coding, broaden your perspective and use your technical skills together with knowledge from other fields to create real impact.

Let's take a case study of 2 software engineers:

Software Engineer 1: Can code.

Software Engineer 2: Can code, but doesn't stop there. He's built range in multiple domains like product management, design, marketing, sales, or business strategy.

Now picture this: both engineers are asked to build a feature for an e-commerce app.

Engineer 1 delivers clean, working code. The feature is technically solid, but that’s about it.
Engineer 2 also writes the code, but because they understand product and user experience, they suggest a small tweak to improve checkout speed. Thanks to their grasp of business strategy, they highlight how this tweak could increase conversions. And with their communication skills, they explain the impact clearly to both the design and business teams.

Both wrote code. But only one created impact. And that’s the engineer AI can’t easily replace.

So if AI is already good at coding, which of these two engineers do you think will stand out in the long run? Exactly, the second one. The guy who connects technical skills with multiple domains and consistently drives outcomes that actually matter.

The Edge Engineer 2 Has Over AI

AI is insanely good at narrow, well-defined tasks. Ask it to optimize a query, generate boilerplate code, or refactor a function and it’ll crush it every time. But here’s the catch: AI doesn’t do well once you step outside of those boundaries. It can remix existing patterns, but it struggles to combine ideas from different domains to create something new.

Engineer 2’s edge is exactly that: they don’t just code, they think. They pull from product, design, business, and even psychology to build things that actually matter. They understand customer pain points, connect dots across fields, and create value AI can’t see because it’s trained on the average of what’s already been done.

The truth is, impact comes from originality and empathy, two areas where humans still have the upper hand. AI can code. Engineer 2 can create outcomes that change the game.

How to Become Engineer 2

Becoming Engineer 2 means you stop being defined only by your ability to code and start stacking skills that make you indispensable. Here’s how:

1. Strengthen Your Core Technical Depth

AI can write code, but it doesn’t truly understand systems. Your technical foundation should be unshakable; architecture, scalability, debugging, and performance optimization are areas where depth matters.

2. Learn to Think Like a Product Manager

Understand why features are built, what problems they solve, and how they tie into business goals. Engineers who think beyond their tickets have a strategic edge.

3. Adopt Design Thinking

You don’t need to be a designer, but knowing the principles of UX, UI, and user research will make your work far more impactful.

4. Understand Business and Growth

Learn how companies make money, how products are sold, and what drives revenue. Engineers with business insight become trusted decision-makers.

5. Invest in Soft Skills

Communication, persuasion, and empathy are career multipliers. They determine how much influence you can have, no matter your technical strength.

6. Master AI Instead of Fearing It

Learn how AI works, where it shines, and where it fails. Engineers who can use AI effectively will outperform those who ignore it.

7. Collaborate Across Functions

Spend time with teams outside engineering like marketing, sales, design, operations. This is how you connect technical skill with real-world impact.

Engineer 2’s advantage isn’t just their skills; it’s how they approach problems. The multi-spired engineer doesn’t see themselves as “just a programmer”; they see themselves as a builder of value. And that mindset is what separates those who succeed in an AI-driven world from those who get left behind.

Having a Future-Proof Mindset

The engineers who stay relevant in the age of AI aren’t the ones who cling to what they already know, they’re the ones who stay curious and adaptable.

Curiosity is your edge. Keep exploring new tools, frameworks, and concepts, and never settle for just “doing your job.” Look past tickets and deadlines and learn the bigger picture: what your product does, who it serves, and why it matters.

The tech world will always shift, and those who grow with it will stay valuable. Sharpen your communication and leadership skills because engineers who can guide, influence, and connect ideas are rare. Stop seeing yourself as “just a programmer.” Start seeing yourself as a builder of real value.

The Road Ahead

AI will write more code than any single engineer ever could and there's nothing we can do about it. But code alone does not create value. The software engineers who succeed will be the ones who decide what to build and why it matters.

Don’t wait for layoffs or industry disruptions to force you into change. Start now:

Learn a skill outside engineering.
Shadow a different team.
Take on a project that challenges you.

The future belongs to engineers who can see beyond the code. Stack your skills, connect the dots across disciplines, and become the person no tool can fully replace.

Dev, Staging, and Production Environments in Software Development

Christian Mbah — Sat, 23 Aug 2025 10:49:38 +0000

Every software product always goes through multiple processes before it’s ready for real users. One of the most important of these processes is testing and validating the code in different environments.

Instead of writing code on your computer and immediately releasing it to the world (which would be risky), software engineers use a structured flow: first development, then staging, and finally production. Each of these environments serves a unique purpose, helping teams catch bugs that were missed, improve performance, and essentially ensures the final product is reliable for users.

Think of it like you're a musician preparing for a big performance:

The development environment is where musicians practice individually

The staging environment is the rehearsal with the whole band where they go through their performance and how good they sound together.

The production environment is the live concert, with the audience watching.

Now we've gotten all that cleared up, let's talk in detail about each of these stages, how they differ and how important each of them are in building a solid software product.

Development environment

This is where all the building and experimenting happens and it's usually set up in your computer. It’s the space where your code is written and initially tested before it’s seen by anyone outside the team.

Here, developers have the freedom to try out new features, fix bugs, or make changes without worrying about breaking the actual application that users depend on. It’s usually connected to a local database or dummy data so that testing doesn’t interfere with real information.

The main players of this stage are the software developers themselves.

Staging environment

Once you’ve got your code working in development, the next stop is the staging environment and you can think of this as your _“final rehearsal” _ before going live.

In staging, your app runs on a server that’s set up to be as close as possible to production. This means it uses almost the same configuration, services, and dependencies that your real users will eventually rely on but since it’s still a safe space, if something breaks here, it won’t affect actual customers.

The main players of this stage are the Quality Assurance (QA) testers. They’re the ones stress-testing your work, hunting bugs, and making sure it’s polished before it goes live (sometimes a bit of a headache for us developers 😅)

Production environment

This is it, the main event. In this environment, your app finally goes live and real users interact with it. Everything that happens here matters because it’s tied to actual customers, real data, and in many cases, real money.

Unlike development or staging, production isn’t very forgiving. If something breaks here, your users will notice, and that can mean frustrated customers, lost revenue, or even security issues. That’s why teams are extra careful about what gets deployed into production.

In this environment, you’ll see practices like gradual rollouts (where updates are released to a small group of users first), blue-green deployments, or canary releases. These strategies let you push updates with less risk, so if something goes wrong, you can roll it back before too many people are affected.

Monitoring and security are also a huge deal here. You’ll want logging, alerts, and backup systems in place so you can react quickly if there’s ever a problem.

The main players are the users themselves. At this stage, it’s no longer about the developer or QA but giving your users the smoothest, most reliable experience possible.

Conclusion

So, to sum it all up:

Development is your playground where you build, test, and break things.

Staging is your dress rehearsal; the space to polish, demo, and catch problems before going live.

Production is the big show, where your users are watching, and everything needs to run smoothly.

Understanding these environments isn’t just for developers. It also helps product managers, designers, and even stakeholders appreciate the path from idea to a reliable product in users’ hands. At the end of the day, it's what keeps your software reliable, your team sane, and your users happy.

What's the Difference between NPM and NPX

Christian Mbah — Sat, 24 May 2025 17:22:21 +0000

Every developer working with JavaScript has likely used one or both of these tools: NPM and NPX. But while they’re often used together, they serve very different purposes, and that can be confusing, especially for beginners. In fact, many developers use them without fully understanding what each one does or why they're using it.

Let’s break it down in the simplest way possible.

What is NPM?

NPM stands for Node Package Manager. It’s the default package manager for Node.js mainly used for:

Installing packages (libraries, tools, etc.) into your project.
Managing and updating dependencies in your package.json file.
Running scripts defined in package.json.

For example:

npm install react

This command installs React and adds it to your node_modules folder and package.json.

What is NPX?

NPX stands for Node Package eXecute. It’s a tool that lets you run any package directly from the NPM registry, without needing to install it globally or keep it in your project.

For example:

npx create-react-app my-app

This runs the create-react-app command without requiring a global install. It temporarily downloads and executes it, then cleans up after itself.

When to Use NPM vs NPX

Use NPM when you want to add a package to your project and manage it over time.

Use NPX when you want to run a tool or command temporarily, like a one-time script.

Why Does It Matter?

Knowing the difference helps you avoid cluttering your system with global installs and keeps your development environment cleaner.

So if you're not sure whether to use npm or npx, ask yourself:

Do I need this tool installed in my project permanently?
If yes, use npm.
If no, or just for a quick command, use npx.

What Does Simple Addition Look Like in 10 Programming Languages?

Christian Mbah — Sat, 10 May 2025 10:27:10 +0000

When starting with a new programming language—whether through tutorials or courses—one of the first tasks we do is usually performing a basic calculation. It’s a simple but effective way to get familiar with the syntax and language rules.

I got curious and decided to see how different languages handle basic calculation. Here, I’ll perform the simple addition operation “5 + 3” in 10 different programming languages, and the goal here is to explore how each language syntax differs in readability. I'll also note their compile and/or runtime and provide a rating out of 10 based on the readability of their syntax as well as list them in descending order.

For consistency, I used the online coding platform JDoodle, so you can easily try out the examples yourself. Please note that the runtime is based on the JDoodle environment and doesn’t necessarily reflect how fast each language would run in a native or optimized environment. It just serves as a way to compare the languages in a controlled setup.

Now that’s all cleared up, let's begin!

1. Python

x=5
y=3
z=x+y

print ("sum of x+y =", z)

Python makes it so easy: assign the values in variables x and y⁣, store the added values in variable ⁣z and use the print() function to display the result. It doesn’t get easier than this. Clean, simple, and easy to read.

Runtime:

0.902 sec(s)

Rating:

9.5

To the surprise of no one, Python is at the top of the list. It’s simplicity and readability make it an ideal choice for beginners; it allows them to focus on learning without being overwhelmed by complex syntax.

Note: Some runtimes show "N/A" because of limitations in JDoodle's runtime environment.

2. JavaScript

let x = 5
let y = 3
let z = x + y
console.log(z);

JavaScript console.log does the job here. It uses the let keyword in assigning variables, stores the added value in a variable, and simply prints it out in the browser’s console. It’s simple, easy to read, versatile, and very useful for debugging.

Runtime:

N/A

Rating:

9.0

It's syntax is clean and straightforward, making it a popular choice for both beginners and experienced developers.

3. C

#include<stdio.h>

int main() {
    int x= 5;
    int y= 3;
    int z=x+y;
    printf("Sum of x+y = %i", z);
}

C requires a bit more setup compared to Python and JavaScript, but that’s what makes learning low-level languages important. It helps you understand the mechanics of memory management and how operations work at a deeper level.

Runtime:

1.132 sec(s)

Rating:

8.0/10

C provides more control over system resources but requires more boilerplate code, making it less beginner-friendly for simple tasks like addition.

4. PHP

<?php

    $x=5;
    $y=3;
    $z=$x+$y;

    $msg = 'Sum of x+y = ';

    print($msg.$z);

?>

PHP is a widely used scripting language designed for web development. It’s simple, user-friendly, and readable, especially when dealing with basic operations. While PHP may not be as fast or strict as some compiled languages, it's great for web scripting and server-side applications.

Runtime:

N/A

Rating:

7.5/10

The syntax is simple and straightforward but could be more structured and robust for larger, more complex applications

5. Go

package main

import "fmt"

func main() {
    x:= 5
    y:= 3
    z:= x + y

    fmt.Printf("Sum of x + y = %d", z)
}

Go’s syntax is very straightforward and is designed for efficiency and scalability, especially in concurrent programming.

Runtime:

N/A

Rating:

7.0/10

Although the syntax is simple and effective for concurrent and scalable programming, the extra imports and verbosity for output reduce its overall simplicity compared to the previous languages.

6. C++

#include <iostream>

using namespace std;

int main() {
    int x=5;
    int y=3;
    int z=x+y;

    cout<<"Sum of x+y = " << z;
}

C++ syntax is relatively clear, but it requires more boilerplate than languages like Python or JavaScript. The need for header files and the use of cout for output might make the code feel a bit more complex, though it allows for greater control over performance and memory management.

Runtime:

1.052 sec(s)

Rating:

6.8/10

The syntax is straightforward but adds verbosity with its use of header files and manual output handling. While powerful, it may feel complex for beginners looking for quick and simple calculations.

7. C

using System;

class Program
{
    static void Main() {
        int x = 5;
        int y = 3;
        int z = x + y;

        Console.Write("Sum of x + y = "+ z);
    }
}

C# follows a structured approach, but the need for defining a class and using specific methods such as Console.Write makes it more verbose compared to higher-level languages. The syntax is clear, but it’s less beginner-friendly and involves more boilerplate code for a simple task.

Runtime:

12.075 sec(s)

Rating:

6.5/10

Although the code is easy to read, it introduces more complexity due to the necessity of class structures and method calls. The added boilerplate reduces the efficiency for a simple calculation.

8. Java

public class MyClass {
  public static void main(String args[]) {
    int x= 5;
    int y= 3;
    int z=x+y;

    System.out.println(z);
  }
}

Java requires defining a full class structure, which feels excessive for a simple calculation. Its strict syntax ensures reliability and performance but adds complexity, making it less intuitive for beginners.

Runtime:

1.402 sec(s)

Rating:

6.0/10

The need for a class structure and the strict syntax makes Java feel cumbersome for a simple task like addition, although it’s powerful and efficient once you get familiar.

9. Objective-C

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[])
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    int x = 5;
    int y = 3;

    NSLog(@"Sum of x + y = %i", (x+y));

    [pool drain];
    return 0;
}

Objective-C adds object-oriented features to C, but the syntax is much more verbose, especially for simple tasks like addition. It’s powerful but requires more boilerplate code that isn’t easily readable, making it less beginner-friendly compared to other languages like C++ or even Java.

Runtime:

7.846 sec(s)

Rating:

5.5/10

The verbose syntax and additional boilerplate make it harder to write and understand for simple tasks, though it is still powerful and flexible for complex applications.

10. Assembly

section .text

global _start

_start:

    mov     eax, [x]
    sub     eax, '0'
    mov     ebx, [y]
    sub     ebx, '0'
    add     eax, ebx
    add     eax, '0'

    mov     [sum], eax

    mov     ecx, msg
    mov     edx, len
    mov     ebx, 1
    mov     eax, 4
    int     0x80

    mov     ecx, sum
    mov     edx, 1
    mov     ebx, 1
    mov     eax, 4
    int     0x80

    mov     eax, 1
    int     0x80

section .data
    x db '5'
    y db '3'
    msg db  "sum of x and y is "
    len equ $ - msg

segment .bss

    sum resb 1

Assembly language is extremely low-level and requires extensive code even for simple operations like addition. Although it offers maximum control over system hardware and performance, the complexity and verbosity make it unsuitable for simple tasks and less beginner-friendly than higher-level languages.

Runtime:

0.876 sec(s)

Rating:

4.0/10

It’s no surprise that this gets last place. It’s too verbose, prone to errors, and definitely not practical for simple tasks.

Reflection

I find it interesting how something as simple as adding two numbers can be expressed in so many different ways. But one thing that’s certain is that although each language has its own unique syntax and rules, they all ultimately achieve the same result. Some languages may have simpler syntax, while others are more complex, but at the end of the day, each of them has their strengths and weaknesses, and they’re all just tools for solving problems.

So which of these languages do you prefer for simple tasks? Feel free to share your thoughts!

How to Build a simple REST API with Node, Express and MongoDB

Christian Mbah — Fri, 09 May 2025 11:30:49 +0000

APIs have always been an important component of modern technology. Whenever we interact with a computer or system to retrieve information or perform a function, Application Programming Interfaces (APIs) are what help us communicate what we want to the system so it can understand and fulfill those requests. Among these, REST APIs are a popular choice because they are simple to use and can handle a lot of different tasks.

In this article we will be building a simple todo list REST API for managing tasks using Express and MongoDB. You’ll cover everything from setting up your project to building the endpoints that handle CRUD (Create, Read, Update, Delete) operations, and by the end you’ll have the foundational skills to create your own APIs with Express and MongoDB.

Prerequisites

Before you begin, ensure you have:

Node.js Installed: Make sure Node.js is installed on your computer. You can download it from nodejs.org.
MongoDB Setup: Either install MongoDB locally and access it with the GUI MongoDB Compass or create a free account on MongoDB Atlas for a cloud-based database.
API Testing Tool: Install Postman, Insomnia, or Thunder Client to test the endpoints.

Setting Up Your Project

Start by creating a folder with any name you like. For this guide, I’ll advise you to use rest-api to keep things consistent. After that, open it in your preferred IDE. If you’re unsure, Visual Studio Code is a great choice.

Open the terminal in your VS Code or any IDE of your choice, navigate to the folder, and run the following command:

npm init -y

This will create a package.json file with default settings to manage your project dependencies.

Next, install the following packages by running the command:

npm install express mongoose nodemon dotenv

You’ll be making use of the packages:

express: For building the server.
mongoose: To interact with MongoDB.
nodemon: For automatically restarting the server during development.
dotenv: To manage environment variables securely.

To make development easier and prevent manually restarting the server after every change, add a start script in your package.json

"scripts": { 
    "start": "nodemon index.js" 
 }

This allows you to start your server with the command npm start . Your package.json file should look like this:

{
  "name": "rest-api",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "nodemon index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "description": "",
  "dependencies": {
    "dotenv": "^16.4.7",
    "express": "^4.21.2",
    "mongoose": "^8.9.4",
    "nodemon": "^3.1.9"
  }
}

Connecting to MongoDB

Now that your project is all set up, the next step is to connect to your database, MongoDB.

Start by creating a .env file at the root of your folder. This is where you’ll store your MongoDB connection URI. This way, you can keep credentials safe and easily configurable.

Inside the .env file, store your connection URI in a variable, like this:

MONGO_URI=your_mongodb_connection_string

If you are using MongoDB Atlas, you can get the connection string from your Atlas dashboard. For local MongoDB with MongoDB Compass, it might look like this:

MONGO_URI=mongodb://localhost:27017/rest-api

Now, create a new file at the root of your project called db.js to manage the MongoDB connection.

Inside db.js, add the following code:

// db.js
const mongoose = require('mongoose');

require('dotenv').config(); // Load environment variables

const connectDB = async () => {
  try {
    await mongoose.connect(process.env.MONGO_URI);
    console.log('MongoDB connected');
  } catch (error) {
    // Catch error if connection fails
    console.error('Error connecting to MongoDB:', error.message);
  }
};

module.exports = connectDB;

This is a simple function for connecting your server to MongoDB with your connection URI.

Now create a index.js file that would be your main file. Then require and invoke the connectDB function to establish a connection to your database.

Example index.js

// index.js
const express = require("express");
const connectDB = require("./db");

const app = express();

connectDB(); // Connect to database
app.use(express.json()); // Middleware to parse JSON requests

// Define a simple route
app.get("/", (req, res) => {
  res.send("Hello World!!");
});

const PORT = process.env.PORT || 5000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Run the server with the command npm run start in your terminal. If everything is set up correctly, you should see the message MongoDB connected in the terminal.

Well, congratulations! You just started your node server.

Defining the data model

The next step is to create a model to define the structure of the data stored in MongoDB. For this tutorial, you’ll create a model for managing a collection of "tasks" in the to-do app.

Inside your project create a models folder to keep your models organized. Inside the models folder, create a Task.js file to define the schema.

Define the Task Schema

To define the model of each task, add the following code to Task.js:

const mongoose = require('mongoose');

// Define the Task schema
const TaskSchema = new mongoose.Schema({
  title: {
    type: String,
    required: [true, 'Title is required'],
  },
  description: {
    type: String,
  },
  completed: {
    type: Boolean,
    default: false,
  },
});

// Create and export the Task model
const Task = mongoose.model('Task', TaskSchema);

module.exports = Task;

Explaining the schema fields

To keep things simple, you’ll be using just a few fields in your schema, with each field having:

title: A required string field to store the task's title.
description: An optional string field to store additional details about the task.
completed: A boolean field indicating whether the task is done. By default, it’s set to false.

With this schema defined, you can now use the Task model to interact with the tasks collection in MongoDB.

Building the API Endpoints

The next step is to create API endpoints for handling CRUD operations in the todo app. These endpoints will allow you to interact with the tasks collection in MongoDB through requests.

Setting up routers

The first step is to set up routers, which creates the routes that define endpoints. Create a folder named routes and a file named task.js inside it. Add the following code to your

// routes/task.js
const express = require('express');
const Task = require('../models/Task'); // Import the Task schema

const router = express.Router(); // Initialize the router

// Endpoints goes here

// Export the router for use in other files
module.exports = router;

The next step is to make your requests with the router.

Creating a Task

Creating a task is done using a POST request, which is typically used to send data to the server to create a new resource.

// Creating a new task
router.post('/', async (req, res) => {
  try {
    const task = new Task(req.body);
    await task.save();
    res.status(201).json(task);
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

Here’s a quick explanation of the code:

The router.post('/', ...) function that handles the POST request sent to /api/tasks You used / here because the router will be mounted under /api/tasks in the main app file.

The new Task(req.body) creates a new task instance using the data from the request’s body and task.save() saves the task to the tasks collection in your database.

If successful, the server responds with a status code 201 (Created) and the saved task data, but if there’s an error, a 500 status code is sent with an error message.

Fetching Tasks

The next endpoint you’ll implement allows the client to fetch a list of all tasks stored in the database. This is done using a GET request, which is typically used to fetch data from the server.

// Get all tasks
router.get("/", async (req, res) => {
  try {
    const tasks = await Task.find(); // Fetch all tasks from the database
    res.status(200).json({ tasks }); // Return the list of tasks
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

To retrieve tasks, the router.get('/', ...) function is used to handle GET requests sent to /api/tasks. This endpoint will fetch all tasks from the database using the Task.find() method.

Once all the tasks are retrieved, the server responds with a status code 200 and sends the tasks in JSON format. If an error occurs during this process, the server responds with a 500 status code and an error message to help diagnose the problem.

Updating a Task

The PUT request allows you to update an existing task in the database. You’ll handle this by using the task's ID⁣ to locate it, and then you’ll update the fields that are passed in the request.

// Update a task
router.put("/:id", async (req, res) => {
  try {
    const { title, description, completed } = req.body;
    const { id } = req.params; // Extract the task ID from the URL

    // Find the task by ID and update it
    const updatedTask = await Task.findByIdAndUpdate(
      id,
      { title, description, completed },
      { new: true } // Return the updated task
    );

    // If no task is found, return an error
    if (!updatedTask) {
      return res.status(404).json({
        message: "Task not found",
      });
    }
    // Respond with the updated task
    res.status(200).json({ data: updatedTask });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

Here, the router.put('/:id', ...) function handles PUT requests sent to /api/tasks/:id, where :id is a placeholder for the task’s unique identifier. This endpoint is responsible for updating an existing task with the specified ID.

The new task data is extracted from req.body, while req.params.id contains the ID of the task to be updated. Using Task.findByIdAndUpdate(id, updateData, options), the task is located and updated with the provided data. The { new: true } option ensures that the updated task is returned in the response.

If the task with the specified ID isn’t found, the server responds with a 404 status and a message indicating that the task doesn’t exist. For any other errors, a 500 status is sent along with the error message to help debug the issue.

Deleting a Task

The DELETE request allows you to delete a specific task from the database using its ID.

// Delete a task
router.delete('/:id', async (req, res) => {
  try {
    const { id } = req.params; // Extract the task ID from the URL
    // Find and delete the task by ID
    const deletedTask = await Task.findByIdAndDelete(id);
    // If no task is found, return an error message
    if (!deletedTask) {
      return res.status(404).json({
        message: 'Task not found',
      });
    }
    res.status(200).json({
      message: 'Task deleted successfully',
    });
  } catch (error) {
    res.status(500).json({
      error: error.message,
    });
  }
});

The router.delete('/:id', ...) function handles DELETE requests sent to /api/tasks/:id, where :id represents the unique identifier of the task to be deleted. This endpoint is designed to remove a specific task from the database.

The task ID is extracted from the URL using req.params.id. The Task.findByIdAndDelete(id) method is then used to find and delete the task with the specified ID. If the task doesn’t exist, the server responds with a 404 status and a message indicating that the task couldn’t be found.

After the task has been deleted, the server returns a 200 status along with a success message. In case of any errors during this process, the server catches the error and responds with a 500 status and the corresponding message.

Summary

In summary, your routes/tasks.js file should finally look like this:

// routes/task.js
const express = require("express");
const Task = require("../models/Task"); // Import the Task schema

const router = express.Router(); // Initialize the router

// Creating a new task
router.post("/", async (req, res) => {
  try {
    const task = new Task(req.body);
    await task.save();
    res.status(201).json(task);
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

// Get all tasks
router.get("/", async (req, res) => {
  try {
    const tasks = await Task.find(); // Fetch all tasks from the database
    res.status(200).json({ tasks }); // Return the list of tasks
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

// Update a task
router.put("/:id", async (req, res) => {
  try {
    const { title, description, completed } = req.body;
    const { id } = req.params; // Extract the task ID from the URL

    // Find the task by ID and update it
    const updatedTask = await Task.findByIdAndUpdate(
      id,
      { title, description, completed },
      { new: true } // Return the updated task
    );

    // If no task is found, return an error
    if (!updatedTask) {
      return res.status(404).json({
        message: "Task not found",
      });
    }
    // Respond with the updated task
    res.status(200).json({ data: updatedTask });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

// Delete a task
router.delete('/:id', async (req, res) => {
  try {
    const { id } = req.params; // Extract the task ID from the URL
    // Find and delete the task by ID
    const deletedTask = await Task.findByIdAndDelete(id);
    // If no task is found, return an error message
    if (!deletedTask) {
      return res.status(404).json({
        message: 'Task not found',
      });
    }
    res.status(200).json({
      message: 'Task deleted successfully',
    });
  } catch (error) {
    res.status(500).json({
      error: error.message,
    });
  }
});

// Export the router for use in other files
module.exports = router;

Don’t forget to call your router in your index.js file after creating the endpoints

// index.js
const tasksRouter = require('./routes/tasks');

// Using the tasks router
app.use('/api/tasks', tasksRouter);

Finally, your folder structure should look a lot like this:

Testing the Endpoints

You can use tools like Postman, Thunder Client, or any API testing tool to test the endpoints.

1. Creating a Task

HTTP Method: POST
URL: http://localhost:5000/api/tasks

Body: Add a JSON body with the task data:

{
  "title": "Buy groceries",
  "description": "Milk, bread, and eggs",
  "completed": false
}

Expected Result: The response should include the newly created task with a status code of 201.

2. Get All Tasks

HTTP Method: GET
URL: http://localhost:5000/api/tasks
Expected Result: The response should include a list of all tasks. If there are no tasks, you’ll see an empty array ([]).

3. Update a Task

HTTP Method: PUT
URL: http://localhost:5000/api/tasks/:id

(Replace :id with the actual ID of the task you want to update.)

Body: Add the updated task data in the JSON format:

{
  "title": "Updated Task Title",
  "description": "Updated task description",
  "completed": true
}

Expected Result: The response should include the updated task with a status code of 200.

4. Delete a Task

HTTP Method: DELETE
URL: http://localhost:5000/api/tasks/:id

(Replace :id with the actual ID of the task you want to delete.)

Expected Result: A confirmation message such as:

{
  "message": "Task deleted successfully"
}

These tests make sure that your endpoints are functioning as expected. If any test fails, check your code for errors, validate the data, and ensure your server and MongoDB are running correctly.

Finalizing the Project

To prepare your project to be scalable and maintainable, it’s best to structure it into distinct folders such as routes/⁣, models/ and config/⁣. Also make sure you store sensitive information like the database URI and API keys in a .env file and use the dotenv package to access them in your code.

For deployment, you can host your server on platforms like Heroku and Vercel. Both platforms offer free tiers, making it easy to deploy your REST API.

Conclusion

To sum it up:

You learned how to create a simple REST API using Express and MongoDB, implementing the fundamental CRUD operations (Create, Read, Update, Delete).
You also saw how to set up and structure your project to keep it clean and scalable.
You’ve also tested your API with Postman or Thunder Client.

With this, you can now start building your own REST APIs and even expand it further by adding more features, such as authentication or proper data validation when making requests.

6 Best Practices in Software Engineering

Christian Mbah — Thu, 08 May 2025 08:53:42 +0000

Best practices are a set of guidelines, ethics, or ideas that represent the most effective or safest method of achieving a business function. It is a method or technique that has been broadly accepted as superior to others in its category due to the fact that it has a tendency to produce superior results.

Best Practices in Software Engineering

Best practices in software engineering are established guidelines and principles that help teams create high-quality, maintainable, and effective software products with fewer errors and rework. They offer a template for organizing workflows, improving collaboration, and delivering reliable software that meets user and business needs.

The importance of best practices in software engineering is in their ability to improve code quality, reduce bugs, improve security, and save time and costs over the project lifecycle. I’ve created a list of best practices every software engineer should adhere to, and by following these practices, teams can create adaptable and scalable software that remains relevant amid changing technologies and requirements.

1. DRY principle

The DRY principle — "Don't Repeat Yourself" — is simply not being redundant in your code. Instead of duplicating logic in multiple places throughout your codebase, you want to write reusable components: functions, classes, or modules that can be reused wherever they are needed.

By avoiding duplication, you reduce technical debt and the risk of inconsistencies or bugs when you must make modifications. When an item of logic needs changing, you only have to modify it in one place — and the improvement is reflected wherever it's used. The outcome is cleaner and more organized code that's easier to read, test, and debug.

DRY can be achieved through abstraction — identifying repeated patterns and turning them into reusable building blocks. When applied consistently, it speeds up development, promotes consistency, and makes it easier for teams to collaborate, since the codebase becomes more organized and predictable.

2. KISS principle

This stands for “Keep It Simple, Stupid” and it emphasizes simplicity in design and code, avoiding over-engineering, and focusing on clear, maintainable, and efficient solutions. In software engineering, it’s easy to overthink a solution — adding multiple layers of logic, edge case handling, and abstractions that aren’t immediately needed. While it might feel like you’re future-proofing your code, most times you’re just making it harder to understand, test, and maintain.

Keeping things simple means solving the problem at hand with the most straightforward, readable solution possible. It doesn’t mean ignoring edge cases or scalability, but rather handling those when the need actually arises, not preemptively.

Simple code is easier to debug, onboard into, and extend. Stick to what’s necessary — and nothing more.

3. YAGNI principle

YAGNI stands for “You Aren’t Gonna Need It,” and it’s a principle that encourages engineers to focus only on what’s necessary — not what might be needed in the future. It opposes the temptation to overbuild features or add extra layers of functionality “just in case.”

In practice, this means resisting the urge to anticipate every possible use case or future requirement. Even though it’s good to plan ahead, building for hypothetical scenarios could lead to bloated, complex codebases filled with unused logic and features. This not only wastes time but also increases the chances of introducing bugs and confusion.

By following the YAGNI principle, developers stay focused on implementing actual, verified requirements — functionality that is needed now, not later. It encourages shipping lean, working software sooner and iterating based on actual user feedback rather than speculation. It also allows for better maintainability and makes the code easier to refactor or scale when real needs are clear.

4. Testing

Testing is a non-negotiable part of software development. It makes sure your code does what it’s supposed to do — not just in best-case scenarios, but under real-world conditions too.

Good tests basically act like a safety net. They catch bugs early, prevent regressions, and give you peace of mind when refactoring or adding new features. Without tests, even small changes can be unpredictable and risky.

There are different types of testing — unit tests for individual functions, integration tests for how parts of the system work together, and end-to-end tests that simulate actual user interactions. While not every line of code needs a test, the goal is to cover the parts that are critical to functionality and prone to change.

Testing your code not only improves your software — it also allows better collaboration. If tests exist, new developers can confidently make changes without worrying they're breaking something that already works.

5. Design before Coding

Jumping straight into code might feel productive, but without a clear plan, you’re simply setting yourself up for rework and confusion down the line. “Design before coding” simply means thinking through your solution before you start typing.

But this doesn’t always mean drawing detailed UML diagrams or writing pages of documentation. It can be as simple as sketching out a flow, defining data models, or breaking a problem into smaller parts. The goal is to clarify what you’re building and how the pieces fit together — before you start implementing.

Whether you’re building a feature, designing an API, or structuring a system, taking time to plan before you build leads to better outcomes — for both your code and your team.

6. Code Reviews

Code reviews are more than just a quality check —they’re a collaborative process that helps teams grow, catch issues early, and maintain a consistent codebase.

A good review isn’t just about pointing out bugs or nitpicking syntax. It’s about understanding the intent behind the code, offering constructive feedback, and suggesting improvements that make the code cleaner, more efficient, or easier to understand. It’s also an opportunity to learn from each other — whether it's discovering a new pattern, a better naming convention, or a smarter approach.

Code review avoids bottlenecks, reduces technical debt, and makes sure the code is consistent with team standards. It also spreads knowledge across the team — when multiple people understand how a feature works, no one person becomes a single point of failure.

Conclusion

Following best practices is not just about writing cleaner code; it’s about building a more efficient, collaborative, and future-ready development process. By incorporating these principles into your workflow, you’ll create software that’s not only high-quality but also easier to maintain, scale, and adapt as your projects grow.

Adopting these best practices today will not only save you time but also set you up for long-term success, making sure you stay ahead in the tech industry.

Why is Next.js so slow for developers?

Christian Mbah — Wed, 07 May 2025 15:38:50 +0000

I've been building apps with Next.js for months now. Its built-in routing, SEO support, and other benefits made it a no-brainer over plain React when building full-stack web applications. But there’s one thing that’s been consistently frustrating:

The development speed is painfully slow.

Next.js Hot Reload is supposed to make updates from your code to the browser faster, but really, every small code change feels like waiting for a full rebuild. I experience freezing pages and lagging terminals, even when working on something as simple as a landing page. It really makes me question if this is truly the "React on steroids" that everyone talks about.

I've worked on Vite + React projects, and I recalled the development speed was never this slow regardless of how complex the project was, so I decided to run up a simple Vite + React and Next.js project to contrast their speed, and within minutes, I noticed that the Vite + React app was A LOT faster, and it wasn't even close. There were no page reloads, no rebuild delays—just instant feedback.

So this begs the question:

If Vite can give this kind of developer experience, why is Next.js still so far behind?

The Reality of Next.js in a Development Environment

When you look at the marketing for Next.js, it seems like a great solution for React developers (and it is). It offers:

✅Built-in routing
✅Server-side rendering (SSR)
✅API routes
✅SEO optimization
✅Full stack capabilities

But there's a downside; Next.js can sometimes feel like it's working against you during development.

Every time you save a file, the terminal starts multiple rebuilds. The browser refreshes slowly, and if you're working on a large, complex application or have many dynamic routes, it gets even worse. Navigating to a different route takes a lot of time, and it's not just your machine causing this (which I initially thought). So then...

Why is Next.js so slow?

After a little bit of research, I realized it isn’t actually a “me” problem; many developers have shared their frustration online:

After more digging, I realized that it comes down to how the framework is built under the hood. Here’s what I found:

1. Next.js Compiles Everything — Client And Server

As a full-stack framework, Next.js isn’t just compiling your frontend like Vite does; it’s compiling both the frontend and the backend at once. So this means every time you hit save, the Next.js compiler has to figure out:

“Does this affect the client? The server? or Both?

...then it rebuilds accordingly. So it kind of makes sense that a one-line tweak might still trigger a chain reaction that takes seconds instead of milliseconds (not very efficient, in my opinion).

2. Hot Reload ≠ Hot Module Replacement

Next.js uses React Fast Refresh, which is supposed to preserve component state between edits. But in practice, especially in larger apps, Fast Refresh is slower, less predictable, and sometimes triggers a full page reload anyway.

Meanwhile, Vite uses native ESM and Hot Module Replacement (HMR), so it only swaps the module that changed without doing extra work. It’s way lighter.

3. Still Built on Webpack (Unless You Switch to Turbopack)

By default, Next.js still uses Webpack in dev mode — and Webpack is not known for speed. It was designed before ESM became mainstream, and it rebuilds too much by default.

Vite, on the other hand, uses esbuild (written in Go) and rollup for production. The difference is a lot, and for reference, Vite can cold-start a dev server in under 300–500 ms, while Next.js sometimes takes 10–20 seconds or more in a mid-size project.

4. File Watching

Next.js watches a lot of files. This includes components, pages, layouts, server functions, and basically any custom config files. So if you have a large number of routes/components, Next.js file-watching gets heavier and can hit your CPU hard, making things feel slower.

5. Your Machine is Still a Factor

If you're running both server-side and client-side code locally (which you are with Next.js), your laptop or PC ends up doing a lot more work than in a basic client-only setup, and if you don't have a mid- to high-end PC, the developer experience can be frustrating.

Workarounds & Solutions

To be fair, Next.js IS a full-stack framework, so it does a lot under the hood; so for a better developer experience, there are some things you can tweak to improve the speed:

1. Try Turbopack with next dev --turbo

Vercel is currently working on Turbopack, their Webpack replacement written in Rust. It’s still in early stages, but it can offer faster refresh times — especially in smaller apps.

You can use Turbopack in your app by replacing the dev script in your package.json file with next dev --turbopack

"scripts": {
    "dev": "next dev --turbopack",
  }

2. Keep Pages and Components Small

It’s simple logic that big files = bigger rebuilds, regardless of the framework. If you split your app into smaller components and pages, you reduce the surface area that triggers a rebuild.

3. Lazy-Load Heavier Routes or Components

If you’re importing a huge component statically, it gets bundled into everything. Use Next,js dynamic import dynamic() to load heavy UI or logic only when needed.

import dynamic from 'next/dynamic'

const HeavyComponent = dynamic(() => import('../components/HeavyComponent'))

4. Offload Your Backend

If you're doing API stuff inside Next.js api routes (/api), it might slow things down, so try separating your backend into a service (like Firebase, Supabase, or even a separate Express API) during development. This will lighten things up for the compiler.

Final Thoughts

So with all these said, should you ditch Next.js? Well, it depends.

It’s easy to get frustrated (I’ve been there), but context matters. Here’s how I think about it now:

When Next.js Makes Sense

You’re building a full-stack app with server-side logic
You need SEO optimization or static generation

Also, Next.js performance optimizations, image handling, SSR, and edge capabilities are great in production.

When Vite Might Be Better

You’re building a frontend-heavy app or design tool
You want instant feedback during development
You’re prototyping and speed matters more than structure

For dev experience (especially speed), Vite is just better right now.

So what has been your experience so far with Next.js? Have you run into the same dev-speed issues? Did Turbopack help, or did you eventually switch to something like Vite?

Feel free to share your thoughts in the comments.