DEV Community: Christian Mbah

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.