DEV Community: Muhammad

Stop Writing Clean Code. Write Boring Code Instead.

Muhammad — Thu, 12 Feb 2026 18:38:04 +0000

"Clean code" has become the religion of the professional software developer. We have its sacred texts — Clean Code by Robert Martin, A Philosophy of Software Design by John Ousterhout, the writings of the Gang of Four. We have its commandments: functions shall do one thing, abstractions shall not leak, dependencies shall flow in one direction. We have its rituals: refactoring sprints, architecture review meetings, pull request threads debating whether a function is "too long."

And like most religions, it has quietly accumulated some dogma that, when examined carefully, causes real harm.

I want to make a case for boring code — and argue that the pursuit of "clean" has become one of the more reliable ways to make a codebase worse.

What We Mean When We Say "Clean"

When most engineers talk about clean code, they're gesturing at a cluster of related ideas: short functions, meaningful names, minimal duplication, clear abstractions, separation of concerns. None of these are bad ideas in isolation.

The problem is what happens in practice. "Clean" has become an aesthetic rather than an engineering criterion. Code gets refactored not because it's hard to change or hard to understand, but because it doesn't look like the platonic ideal some engineer has in their head.

I've seen a 40-line function that did one coherent thing get split into six functions with six names and a new abstraction layer — because the original was "too long." I've seen working, well-tested code rewritten in a more "functional" style because the previous author had used for-loops. I've seen simple conditional logic replaced with a Strategy pattern because the reviewer felt that direct conditionals were "procedural."

In each case, the refactoring made the code harder to follow, harder to debug, and harder to delete. It made the code cleaner, in the aesthetic sense, and worse, in the engineering sense.

The Abstraction Trap

The single most reliable way to damage a codebase long-term is to introduce the wrong abstraction at the wrong time. And our obsession with clean code, with DRY (Don't Repeat Yourself), with "separation of concerns" — pushes us toward abstraction almost by default.

Here's the thing about abstractions: they're bets. When you build an abstraction, you're betting that the two things you've unified will continue to change for the same reasons, in the same directions, at the same times. When that bet is right, the abstraction pays off. When it's wrong — and it's often wrong — you've bound together things that needed to evolve independently, and now every change to either one requires you to reason about both.

Sandi Metz's talk "All the Little Things" introduced an idea that I think about constantly: duplication is far cheaper than the wrong abstraction. A bit of code that's repeated in two places can be unified later, once you actually understand how it will need to change. An abstraction built too early locks in assumptions that turn out to be false, and costs you far more to unwind than the original duplication would have cost to maintain.

The practical implication is almost the opposite of what most code review culture teaches: when you see two pieces of similar code, your first instinct should not be to unify them. It should be to ask what would have to be true for these two things to always change together. If you can't answer that confidently, leave them separate.

Boring Code Is Predictable

Let me describe what I mean by boring code, because I don't mean sloppy code or lazy code.

Boring code is code where, when something goes wrong at 2am, you can find the problem in five minutes. It's code where a new engineer can read the relevant function and understand what it does without jumping through three layers of abstraction and two interface definitions. It's code that does the obviously right thing instead of the elegantly clever thing.

Boring code tends to be:

Explicit rather than clever. It says what it does. It doesn't require you to know the design pattern to understand the intent. An explicit conditional branch that reads like English is almost always preferable to a polymorphic dispatch that requires you to know which concrete class is in scope.

Flat rather than deeply nested. Not because nesting is aesthetically bad, but because flat call stacks are faster to navigate in a debugger, easier to read in a stack trace, and simpler to test.

Longer rather than fractured. A 60-line function that does one coherent workflow is often easier to understand than six 10-line functions that each do a fragment of it. The question isn't "is this function long?" but "can I understand what this function does end-to-end without constant context switching?"

Direct about its dependencies. Dependency injection frameworks, service locators, and ambient context make code harder to trace. Passing dependencies explicitly — even if it makes function signatures a bit longer — makes the code easier to reason about and test.

The Naming Problem

Here's a subtle way that clean code culture makes things worse: it places enormous emphasis on naming, in a way that encourages naming things that shouldn't exist.

When you introduce a new abstraction — a class, a function, a module — you have to name it. The act of naming creates cognitive overhead: now there's a new concept in the codebase that readers need to build a mental model of. Good naming reduces that overhead. But no naming at all — because the abstraction doesn't exist — reduces it to zero.

I've watched engineers spend twenty minutes in a pull request arguing about whether a helper function should be called processUserData, transformUserRecord, or normalizeUserPayload. The argument is real and the stakes are legitimate — names matter. But the more important question, which often goes unasked, is: should this function exist at all? Is the code clearer with the extraction, or would it be clearer if the logic just lived inline where it's used?

The answer is often "inline is clearer," and the reason we didn't start there is that we were pattern-matching against our idea of what clean code looks like.

On Being Hard to Delete

One of the best tests for a piece of code is: how hard is it to delete?

Code that's easy to delete is code that's doing exactly one thing, has minimal dependencies, doesn't reach into other parts of the system, and has clear tests that tell you what you'll break if you remove it. Code that's hard to delete is code that's become load-bearing — other things depend on it, it carries implicit assumptions that other parts of the system rely on, and changing it sets off unexpected cascades.

Clean code culture, paradoxically, often produces code that's hard to delete. When you've carefully designed a class hierarchy, extracted everything into interfaces, built a layered architecture with a domain model and repository pattern and service layer — you've created a system where everything is neatly separated and also tightly coupled conceptually. Removing any piece requires understanding how the other pieces have been designed around it.

Boring code, because it tends toward the explicit and the flat, tends to be easier to delete. Dependencies are obvious. Scope is limited. If the thing doesn't work anymore or isn't needed, you can see clearly what it touches and cut it out.

When "Clean" Is Actually Right

I don't want to overcorrect. There are patterns from clean code culture that I think are unambiguously good and that I apply consistently.

Meaningful names for things that matter. A well-named variable in a complex algorithm is worth investing time in. The name should capture why, not just what.

Tests that document intent. A test suite that reads like a specification of behavior is one of the clearest forms of documentation. The discipline around testability from clean code culture has made codebases dramatically more maintainable.

Small, stable interfaces at system boundaries. Where two systems or services touch, a clean, minimal interface protects both sides. This is where abstraction investment pays off reliably.

Consistent patterns within a team. If your team has agreed on how you do error handling, how you structure modules, how you name things — consistency beats cleverness every time. The value isn't in any individual pattern, it's in the predictability across the codebase.

The problem isn't clean code ideas. The problem is applying them without asking whether they're making the specific code in front of you easier to understand, change, and delete — or just making it look more like the ideal.

What I'd Change About Code Review Culture

Most code review threads about style and cleanliness are asking the wrong question. They ask: does this code conform to our aesthetic? They should ask: if this code breaks in production, how quickly can we diagnose it? If a new engineer joins next month, how long until they understand this? If we need to change this behavior in six months, what's the blast radius?

Those questions have concrete answers that you can reason about. Whether a function is "too long" or an abstraction is "clean enough" does not.

I'd also add a new norm to most teams I've worked with: before extracting an abstraction, articulate what you're betting. Say it out loud in the PR: "I'm extracting this because I believe X and Y will always change together, and here's why." That single discipline — making the bet explicit — would prevent a significant fraction of the premature abstractions I've seen.

The Actual Goal

The goal of software engineering is not clean code. It's software that works, is easy to change, and survives contact with the people who will work on it over time.

Sometimes clean code and boring code are the same thing. More often, in my experience, they're in tension — and when they are, boring wins. The codebase that a tired engineer can navigate at 2am. The function that a junior developer can modify without being afraid they've misunderstood the abstraction. The module that can be deleted entirely when the product requirement changes without leaving load-bearing assumptions scattered through four other layers.

Boring isn't glamorous. It won't get you compliments in code review. But it'll get your users' problems fixed, your team's velocity up, and your own stress levels down.

Write the boring code. Let someone else win the aesthetic argument.

What's your take? I've found this framing useful, but I'm genuinely curious where clean code culture has served your team well — or where it's burned you. Drop a comment below.

Building a Real-Time Notification System with Node.js, WebSockets, and Redis Pub/Sub

Muhammad — Thu, 12 Feb 2026 18:22:33 +0000

Real-time notifications are one of those features that seem simple on the surface — "just send a message when something happens" — and turn into an architectural puzzle the moment you try to scale them. A single server maintaining WebSocket connections is easy. The problem starts when you have multiple server instances and a WebSocket connection on Server A needs to deliver a message triggered by an event on Server B.

This tutorial walks through building a production-grade notification system that solves exactly that problem using Node.js, the ws library, and Redis Pub/Sub as a message broker across instances.

What We're Building

A WebSocket server that maintains persistent client connections
A Redis Pub/Sub channel as a cross-instance message bus
A REST endpoint to trigger notifications (simulating an internal service)
Automatic reconnection logic on the client side
TypeScript throughout

By the end you'll have a working system where publishing a notification to any server instance delivers it to the correct connected client regardless of which instance holds their WebSocket connection.

The Architecture

Client A ──WebSocket──► Server Instance 1 ──Subscribe──► Redis Pub/Sub Channel
Client B ──WebSocket──► Server Instance 2 ──Subscribe──►      │
                                                               │
Any Service ──POST /notify──► Any Instance ──Publish──────────┘

Every server instance subscribes to the same Redis channel. When any instance receives a "publish" event (from an internal API call, a job queue, a webhook — whatever), it broadcasts to Redis. Every instance receives that message and checks: do I have a WebSocket connection for this user? If yes, deliver it.

This pattern scales horizontally with zero coordination between instances.

Prerequisites

Node.js 18+
Docker (for local Redis)
Basic familiarity with WebSockets and async/await

Step 1: Setup

mkdir realtime-notifications && cd realtime-notifications
npm init -y
npm install ws redis express
npm install -D typescript @types/ws @types/express @types/node ts-node
npx tsc --init

Update tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "outDir": "./dist"
  }
}

Start Redis:

docker run -d --name redis-notify -p 6379:6379 redis:7-alpine

Step 2: The Connection Registry

Each server instance needs to track which WebSocket connections it's currently holding, keyed by user ID. This is purely in-memory — it only needs to know about its own connections.

Create src/connectionRegistry.ts:

import WebSocket from 'ws';

// In-memory map of userId → Set of WebSocket connections
// A user can have multiple open tabs/devices
const registry = new Map<string, Set<WebSocket>>();

export function registerConnection(userId: string, ws: WebSocket): void {
  if (!registry.has(userId)) {
    registry.set(userId, new Set());
  }
  registry.get(userId)!.add(ws);
  console.log(`[Registry] User ${userId} connected. Total connections: ${getConnectionCount()}`);
}

export function removeConnection(userId: string, ws: WebSocket): void {
  const connections = registry.get(userId);
  if (!connections) return;

  connections.delete(ws);
  if (connections.size === 0) {
    registry.delete(userId);
  }
  console.log(`[Registry] User ${userId} disconnected. Total connections: ${getConnectionCount()}`);
}

export function getConnections(userId: string): Set<WebSocket> | undefined {
  return registry.get(userId);
}

export function getConnectionCount(): number {
  let count = 0;
  registry.forEach((connections) => (count += connections.size));
  return count;
}

Why a Set per user instead of a single connection? A user on three devices has three WebSocket connections. You want a notification to reach all of them.

Step 3: The Notification Type

Create src/types.ts:

export interface Notification {
  id: string;
  userId: string;           // Recipient
  type: 'info' | 'warning' | 'success' | 'error';
  title: string;
  message: string;
  timestamp: string;
  metadata?: Record<string, unknown>;
}

Step 4: The Redis Pub/Sub Bridge

This is the core of the cross-instance communication. We need two separate Redis clients: one for publishing, one for subscribing. This is a Redis requirement — a client in subscriber mode can't issue regular commands.

Create src/redisBridge.ts:

import { createClient, RedisClientType } from 'redis';
import { Notification } from './types';
import { getConnections } from './connectionRegistry';

const CHANNEL = 'notifications';

let publisherClient: RedisClientType;
let subscriberClient: RedisClientType;

export async function initRedisBridge(): Promise<void> {
  publisherClient = createClient({ url: process.env.REDIS_URL || 'redis://localhost:6379' });
  subscriberClient = createClient({ url: process.env.REDIS_URL || 'redis://localhost:6379' });

  publisherClient.on('error', (err) => console.error('[Redis Publisher] Error:', err.message));
  subscriberClient.on('error', (err) => console.error('[Redis Subscriber] Error:', err.message));

  await publisherClient.connect();
  await subscriberClient.connect();

  // Subscribe to the notifications channel
  await subscriberClient.subscribe(CHANNEL, (message) => {
    handleIncomingMessage(message);
  });

  console.log(`[RedisBridge] Listening on channel: ${CHANNEL}`);
}

function handleIncomingMessage(rawMessage: string): void {
  let notification: Notification;

  try {
    notification = JSON.parse(rawMessage);
  } catch {
    console.error('[RedisBridge] Failed to parse message:', rawMessage);
    return;
  }

  // Check if THIS instance has a connection for this user
  const connections = getConnections(notification.userId);

  if (!connections || connections.size === 0) {
    // This instance doesn't hold a connection for this user — that's fine,
    // another instance will handle it
    return;
  }

  // Deliver to all of this user's connections on this instance
  const payload = JSON.stringify(notification);
  for (const ws of connections) {
    if (ws.readyState === ws.OPEN) {
      ws.send(payload);
      console.log(`[RedisBridge] Delivered notification ${notification.id} to user ${notification.userId}`);
    }
  }
}

export async function publishNotification(notification: Notification): Promise<void> {
  const payload = JSON.stringify(notification);
  await publisherClient.publish(CHANNEL, payload);
  console.log(`[RedisBridge] Published notification ${notification.id} for user ${notification.userId}`);
}

The key insight in handleIncomingMessage: every instance receives every published message, but only the instance holding that user's WebSocket connection will actually have something to send. The others will hit the early return and do nothing. No coordination required.

Step 5: The WebSocket Server

Create src/wsServer.ts:

import { WebSocketServer, WebSocket } from 'ws';
import { IncomingMessage } from 'http';
import { registerConnection, removeConnection } from './connectionRegistry';

// In a real system, validate a JWT token here
// For this demo, we accept userId as a query parameter
function extractUserId(req: IncomingMessage): string | null {
  const url = new URL(req.url || '', `http://localhost`);
  return url.searchParams.get('userId');
}

export function initWebSocketServer(port: number): void {
  const wss = new WebSocketServer({ port });

  wss.on('connection', (ws: WebSocket, req: IncomingMessage) => {
    const userId = extractUserId(req);

    if (!userId) {
      ws.close(1008, 'userId is required');
      return;
    }

    registerConnection(userId, ws);

    // Send an acknowledgment on connection
    ws.send(JSON.stringify({
      type: 'connected',
      message: `Connected as ${userId}`,
      timestamp: new Date().toISOString(),
    }));

    ws.on('close', () => {
      removeConnection(userId, ws);
    });

    ws.on('error', (err) => {
      console.error(`[WebSocket] Error for user ${userId}:`, err.message);
      removeConnection(userId, ws);
    });

    // Handle ping/pong for connection health checks
    ws.on('pong', () => {
      (ws as any).isAlive = true;
    });
  });

  // Heartbeat interval — detect and clean up zombie connections
  const heartbeat = setInterval(() => {
    wss.clients.forEach((ws) => {
      if ((ws as any).isAlive === false) {
        ws.terminate();
        return;
      }
      (ws as any).isAlive = false;
      ws.ping();
    });
  }, 30_000);

  wss.on('close', () => clearInterval(heartbeat));

  console.log(`[WebSocket] Server listening on port ${port}`);
}

The heartbeat interval is important in production. TCP connections can appear open to your server while the client is actually gone (network dropout, mobile device sleeping). Sending a periodic ping and terminating connections that don't respond prevents accumulating ghost connections that hold memory and skew your connection count metrics.

Step 6: The REST API for Publishing Notifications

Create src/apiServer.ts:

import express from 'express';
import { v4 as uuidv4 } from 'uuid';
import { publishNotification } from './redisBridge';
import { Notification } from './types';

// npm install uuid && npm install -D @types/uuid

export function initApiServer(port: number): void {
  const app = express();
  app.use(express.json());

  // Internal endpoint — in production, protect with API key or internal network policy
  app.post('/notify', async (req, res) => {
    const { userId, type, title, message, metadata } = req.body;

    if (!userId || !type || !title || !message) {
      return res.status(400).json({ error: 'userId, type, title, and message are required' });
    }

    const notification: Notification = {
      id: uuidv4(),
      userId,
      type,
      title,
      message,
      timestamp: new Date().toISOString(),
      metadata,
    };

    await publishNotification(notification);
    res.status(202).json({ id: notification.id, status: 'published' });
  });

  app.get('/health', (_, res) => res.json({ status: 'ok' }));

  app.listen(port, () => console.log(`[API] Server listening on port ${port}`));
}

Note the 202 Accepted response rather than 200 OK. Publishing to Redis is fire-and-forget — we don't wait for delivery confirmation from the WebSocket layer. A 202 correctly signals that we've accepted the request and will process it asynchronously.

Step 7: The Entry Point

Create src/index.ts:

import { initRedisBridge } from './redisBridge';
import { initWebSocketServer } from './wsServer';
import { initApiServer } from './apiServer';

async function start() {
  await initRedisBridge();
  initWebSocketServer(8080);
  initApiServer(3000);
  console.log('[App] Notification server ready');
}

start().catch((err) => {
  console.error('[App] Fatal startup error:', err);
  process.exit(1);
});

Step 8: Test It End-to-End

Start the server:

npx ts-node src/index.ts

Open a WebSocket connection (using websocat or the browser console):

# Install websocat: https://github.com/vi/websocat
websocat ws://localhost:8080?userId=user-123

You should see the connection acknowledgment:

{"type":"connected","message":"Connected as user-123","timestamp":"..."}

Now trigger a notification from another terminal:

curl -X POST http://localhost:3000/notify \
  -H "Content-Type: application/json" \
  -d '{
    "userId": "user-123",
    "type": "success",
    "title": "Payment Received",
    "message": "Your payment of $49.00 has been processed.",
    "metadata": { "invoiceId": "INV-2024-0042" }
  }'

The notification should appear immediately in your WebSocket terminal.

Step 9: Verify Cross-Instance Delivery

To prove the multi-instance routing works, run two server instances on different ports:

# Terminal 1
PORT=3000 WS_PORT=8080 npx ts-node src/index.ts

# Terminal 2 (you'd update index.ts to accept PORT/WS_PORT env vars)
PORT=3001 WS_PORT=8081 npx ts-node src/index.ts

Connect your WebSocket client to instance 1 (port 8080), then send the POST /notify request to instance 2 (port 3001). The notification still arrives via instance 1. Redis does the routing.

What to Add Before Production

Persistent notification history. Right now, a notification sent while a user is offline is lost. Store notifications in a database (Postgres with a notifications table works well) and fetch unread ones on WebSocket connect.

Authentication. Replace the ?userId= query param with a signed JWT. Validate it before registering the connection and extract the user ID from the token claims.

Notification acknowledgment. Add a client-to-server message ({ type: 'ack', notificationId: '...' }) so users can mark notifications as read and you can track delivery.

Monitoring. Instrument connection count, messages published per second, and Redis publish latency. A spike in connection count without a corresponding traffic spike often indicates reconnection loops — worth alerting on.

Conclusion

The Redis Pub/Sub pattern is elegant for this use case because it adds almost no complexity — it's just a broadcast channel every instance listens to. Each instance independently decides whether it has something to do with each message, and those that don't simply move on.

It won't serve every use case: if you need guaranteed delivery, ordered delivery, or delivery acknowledgment at the broker level, you'll want Kafka or a dedicated message queue. But for real-time notifications at typical web application scale, this architecture is reliable, understandable, and horizontally scalable without any instance coordination.

The Senior Engineer's Career Trap: Why You're Optimizing for the Wrong Thing

Muhammad — Thu, 12 Feb 2026 18:19:35 +0000

There's a pattern I've watched repeat itself more times than I can count. A talented developer spends three to four years grinding through difficult problems, earns the "Senior Engineer" title, gets a meaningful pay bump — and then stalls.

Not because they stop learning. Not because they stop shipping. They stall because they keep doing exactly what got them promoted in the first place: writing good code, fixing hard bugs, unblocking teammates. Individual output, optimized relentlessly.

The trap isn't technical stagnation. It's optimizing for the wrong metric at the wrong career stage.

The Metric That Got You Here Won't Get You Further

Early in your career, the relationship between effort and impact is roughly linear. You write more code, you create more value. You fix more bugs, you unblock more people. The feedback loop is fast and legible.

At the senior level, that math breaks down.

The most impactful thing you can do on any given day is often invisible: a ten-minute conversation that saves a teammate three days of going down the wrong architectural path. A well-timed question in a design review that surfaces a flaw before it gets baked into production. A decision to not build something because you recognized the feature request as a symptom of a broken upstream process.

None of those show up in your commit history.

The engineers who plateau at Senior are usually the ones still measuring their own value by what they personally build. The ones who advance — into Staff, Principal, or into technical leadership — have made a fundamental mental shift: they start measuring their value by the output of everyone around them.

What Leverage Actually Looks Like

I want to be concrete here, because "have more impact" is advice so generic it's practically useless.

Leverage through documentation. The most scalable thing you can write is not code — it's a clear, opinionated explanation of why a system works the way it does. An architecture decision record (ADR) that 40 engineers will read over the next two years delivers more value than most features. I've seen well-written ADRs prevent the same bad decision from being relitigated repeatedly for years.

Leverage through taste. Senior engineers who develop a reputation for strong technical taste — knowing which abstractions hold up, which performance tradeoffs are worth making, when "good enough" is actually good enough — become multipliers for everyone around them. People start asking before building. Pull request quality goes up. You spend less time in code review pointing out the same class of problems.

Leverage through sponsorship, not just mentorship. There's a meaningful difference. Mentorship is advice. Sponsorship is putting your name behind someone's work, advocating for them in rooms they're not in, and giving them high-visibility projects that accelerate their career. The engineers who build strong networks inside and outside their company almost always did so through sponsorship — giving and receiving it.

Leverage through clarity of thought. The ability to write clearly — a crisp technical proposal, a concise incident post-mortem, a well-structured RFC — is a force multiplier that compounds over years. Teams make better decisions when the context is clearly documented. I've seen technically average engineers outperform brilliant ones purely because they could write down what they were thinking.

The Uncomfortable Truth About "Staying Technical"

One of the most common anxieties I hear from senior engineers is the fear of drifting away from the code — of becoming "just a manager" or "just a coordinator." I understand it. Most of us got into this field because we love building things, and that doesn't go away.

But there's a version of "staying technical" that's actually a defense mechanism.

If you're the most senior person on a project and you're still personally writing the most critical path code — not because no one else can, but because you haven't created the conditions for anyone else to — that's not staying technical. That's a bottleneck with good intentions.

The engineers I most respect at Staff level and above have found a different balance. They stay deep enough in the technical details to maintain their judgment and credibility — they can still read the code, spot the systemic issue in an incident timeline, challenge the vendor's architecture. But they've deliberately stepped back from being the primary implementor, because their time creates more value when it's spent on the problems that don't have someone else already working on them.

That shift is harder than it sounds, because it requires sitting with ambiguity and slower feedback loops. You don't always know if the decision you influenced today will play out well for another six months. That's uncomfortable for people who are used to the immediate satisfaction of shipping a feature.

The Career Advice I Wish Someone Had Given Me Earlier

Invest in your network before you need it. Most engineers treat professional networking as something you do when you're job hunting. The engineers who have optionality — the ones who can move into interesting roles quickly, who get calls about opportunities before those roles are posted — built those relationships over years, not in a job-search sprint. Write publicly. Speak at meetups. Review open-source PRs. Be genuinely helpful to people without an agenda.

Pick a hill to be known for. Generalism is valuable, but it's hard to build a reputation on. The senior engineers who advance fastest are usually known for something specific — distributed systems reliability, React performance, developer experience, API design. That reputation gives people a reason to seek you out and gives you a filter for which opportunities to pursue.

Learn to talk about money. Compensation negotiation is a skill. Most engineers underinvest in it, leave significant money on the table across their careers, and then feel resentful about it. Understanding how equity works, how to evaluate competing offers, and how to have a direct conversation about compensation without it feeling awkward is worth several hours of your time. No one is coming to offer you market rate out of the goodness of their heart.

Know the difference between a growth problem and a company problem. If you're frustrated, bored, or stalled — sit with the question of whether the issue is something you can change by showing up differently, or whether it's structural. A company with no engineering ladder above Senior, a leadership team that doesn't value technical excellence, or a culture that treats infrastructure as a cost center rather than a competitive advantage will limit your growth regardless of how hard you work. Recognizing the difference can save you years.

On Titles and Their Actual Meaning

The title matters less than most people think, and more than some people pretend.

It matters less because a "Senior Engineer" at a 500-person company operating at the technical frontier is often doing more impactful and more complex work than a "Staff Engineer" at a company that inflated titles to retain people. The credential is not the competence.

It matters more because titles are a communication shorthand that determines which conversations you get invited into, which decisions you're consulted on, and how much autonomy you're extended before you've proven yourself in a new context. Especially when you change companies, a title is the first signal a new team has about what to expect from you.

My practical advice: optimize for the work, not the title. Take the projects where you'll grow the most and have the most impact. Titles tend to follow outcomes, and when they don't, you'll have the credibility to push for them or the options to go somewhere that recognizes the work appropriately.

Where to Spend the Next Six Months

If you're at Senior and feeling stuck, here's what I'd actually do:

Pick one area where your team consistently makes the same kinds of mistakes and fix the upstream cause — a missing abstraction, an unclear ownership boundary, a lack of documentation. Solve it structurally, not symptom by symptom.

Find one person more junior than you and sponsor them. Not just answer their questions, but actively find an opportunity to put your credibility behind their work.

Write one piece of technical content publicly — a blog post, a conference talk, an open-source contribution with a write-up. It will force clarity in your thinking and start building a reputation outside your current employer.

None of these are glamorous. None of them will show up in your sprint velocity. But six months from now, they will have compounded into something that matters for your career in ways that grinding out another feature almost certainly won't.

The engineering career ladder is poorly documented and unevenly applied. The engineers who navigate it well are usually the ones who figured out — through observation, mentorship, or hard-won experience — that the rules change at the Senior level. Output matters less. Leverage matters more.

That shift isn't comfortable, but it's the one that opens everything up.

How to Build a Production-Ready API Rate Limiter with Node.js and Redis

Muhammad — Thu, 12 Feb 2026 18:16:26 +0000

Rate limiting is one of those things every senior engineer knows they need, but far too many teams bolt on at the last minute — usually right after their first DDoS incident or surprise AWS bill. In this tutorial, I'll walk you through building a robust, sliding-window rate limiter from scratch using Node.js and Redis, the same pattern used in production at scale.

By the end, you'll have a reusable Express middleware that enforces per-user, per-route limits with graceful degradation when Redis is unavailable.

What We're Building

A sliding window rate limiter (more accurate than fixed-window)
Implemented as Express middleware
Backed by Redis with an in-memory fallback
Returns proper 429 responses with Retry-After headers
Fully typed with TypeScript

Prerequisites

Node.js 18+
A running Redis instance (locally via Docker or a managed service)
Familiarity with Express and async/await

Step 1: Project Setup

mkdir rate-limiter-demo && cd rate-limiter-demo
npm init -y
npm install express redis
npm install -D typescript @types/express @types/node ts-node
npx tsc --init

Update your tsconfig.json to set "target": "ES2020" and "moduleResolution": "node".

Step 2: Spin Up Redis Locally

If you don't have Redis running, the fastest path is Docker:

docker run -d --name redis-limiter -p 6379:6379 redis:7-alpine

Step 3: Create the Redis Client

Create src/redisClient.ts:

import { createClient } from 'redis';

const client = createClient({
  url: process.env.REDIS_URL || 'redis://localhost:6379',
});

client.on('error', (err) => {
  console.error('[Redis] Connection error:', err.message);
});

export const connectRedis = async () => {
  if (!client.isOpen) await client.connect();
};

export default client;

One thing worth emphasizing: we're using an error listener rather than letting uncaught exceptions crash the process. In production, Redis blips happen — you want to log and degrade gracefully, not take down your entire API.

Step 4: Implement the Sliding Window Algorithm

The fixed-window approach (e.g., "100 requests per minute, reset at :00") has a well-known edge case: a user can send 100 requests at 12:00:59 and another 100 at 12:01:01, effectively doubling your intended limit in a two-second window.

The sliding window algorithm solves this by tracking the actual timestamps of each request within a rolling time range.

Create src/rateLimiter.ts:

import { Request, Response, NextFunction } from 'express';
import redisClient from './redisClient';

interface RateLimiterOptions {
  windowMs: number;   // Time window in milliseconds
  maxRequests: number; // Max requests per window
  keyPrefix?: string;  // Namespace for Redis keys
}

function getRateLimiter(options: RateLimiterOptions) {
  const { windowMs, maxRequests, keyPrefix = 'rl' } = options;

  return async function rateLimiterMiddleware(
    req: Request,
    res: Response,
    next: NextFunction
  ) {
    // Identify the requester — prefer authenticated user ID, fall back to IP
    const identifier =
      (req as any).user?.id || req.ip || 'anonymous';
    const key = `${keyPrefix}:${req.path}:${identifier}`;
    const now = Date.now();
    const windowStart = now - windowMs;

    try {
      // Use a pipeline to batch Redis commands atomically
      const pipeline = redisClient.multi();

      // Remove timestamps outside the current window
      pipeline.zRemRangeByScore(key, 0, windowStart);

      // Count remaining requests in the window
      pipeline.zCard(key);

      // Add current request timestamp
      pipeline.zAdd(key, { score: now, value: `${now}-${Math.random()}` });

      // Set key TTL to auto-expire (prevent orphaned keys)
      pipeline.expire(key, Math.ceil(windowMs / 1000));

      const results = await pipeline.exec();
      const requestCount = results[1] as number;

      // Set informational headers
      res.setHeader('X-RateLimit-Limit', maxRequests);
      res.setHeader('X-RateLimit-Remaining', Math.max(0, maxRequests - requestCount - 1));
      res.setHeader('X-RateLimit-Reset', new Date(now + windowMs).toISOString());

      if (requestCount >= maxRequests) {
        const retryAfterSeconds = Math.ceil(windowMs / 1000);
        res.setHeader('Retry-After', retryAfterSeconds);
        return res.status(429).json({
          error: 'Too Many Requests',
          message: `Rate limit exceeded. Try again in ${retryAfterSeconds} seconds.`,
          retryAfter: retryAfterSeconds,
        });
      }

      next();
    } catch (err) {
      // Redis is down — fail open to avoid blocking legitimate traffic
      console.error('[RateLimiter] Redis unavailable, failing open:', err);
      next();
    }
  };
}

export default getRateLimiter;

A few senior-level decisions worth noting here:

Why zAdd with a random suffix? Redis sorted sets use the value as a tiebreaker when scores are equal. If two requests arrive at the exact same millisecond, identical values would deduplicate. Adding a random suffix prevents that.

Why fail open? If Redis goes down, the alternative is failing closed — which means your entire API goes down with it. For most use cases, briefly losing rate limiting protection is preferable to a full outage. For high-security endpoints, you might reverse this.

Step 5: Wire It Into Express

Create src/index.ts:

import express from 'express';
import { connectRedis } from './redisClient';
import getRateLimiter from './rateLimiter';

const app = express();
app.use(express.json());

// Global limit: 100 requests per minute per user/IP
const globalLimiter = getRateLimiter({
  windowMs: 60 * 1000,
  maxRequests: 100,
  keyPrefix: 'global',
});

// Strict limit for auth endpoints: 10 per minute
const authLimiter = getRateLimiter({
  windowMs: 60 * 1000,
  maxRequests: 10,
  keyPrefix: 'auth',
});

app.use(globalLimiter);

app.post('/login', authLimiter, (req, res) => {
  res.json({ message: 'Login endpoint' });
});

app.get('/health', (req, res) => {
  res.json({ status: 'ok' });
});

const start = async () => {
  await connectRedis();
  app.listen(3000, () => console.log('Server running on port 3000'));
};

start();

Step 6: Test It

Run the server:

npx ts-node src/index.ts

In a separate terminal, fire off rapid requests:

for i in {1..12}; do curl -s -o /dev/null -w "%{http_code}\n" -X POST http://localhost:3000/login; done

You'll see 200s for the first 10 requests, then 429s — exactly as intended.

Step 7: Verify the Headers

curl -I -X POST http://localhost:3000/login

You should see:

X-RateLimit-Limit: 10
X-RateLimit-Remaining: 8
X-RateLimit-Reset: 2024-11-15T14:32:00.000Z

These headers let well-behaved clients implement their own backoff logic without guessing.

Taking It Further in Production

Once this is working, a few things I'd add before shipping:

Tiered limits by user role. Your free tier might get 60 req/min while paid users get 600. You can pass a maxRequests resolver function instead of a static number and derive it from req.user.plan.

Distributed key namespacing. In a multi-region setup, you might want per-region limits vs. global limits. Prefix your keys accordingly (us-east:rl:... vs. global:rl:...).

Metrics and alerting. Log a warning when any key hits 80% of its limit. That's your early signal of abuse or a runaway client before the 429s start.

Testing with ioredis-mock. Swap the Redis client with a mock in your test environment so your rate limiter unit tests don't require a live Redis instance.

Conclusion

A well-built rate limiter isn't just a security control it's a first-class citizen of your API's contract with clients. The sliding window approach gives you accuracy, Redis gives you shared state across instances, and the fail-open design keeps a cache blip from becoming a customer-facing incident.

The full code for this tutorial is available on GitHub . Drop a comment below if you have questions or want me to cover token bucket rate limiting next.

Fixing React Performance at Scale: A Senior Engineer's Practical Playbook

Muhammad — Thu, 12 Feb 2026 18:14:33 +0000

Fixing React Performance at Scale: A Senior Engineer's Practical Playbook

Premature optimization is the root of all evil — but so is ignoring performance until your users are complaining. After years of working on React applications that serve millions of users, I've developed a systematic approach to diagnosing and fixing performance problems without guessing. This is that playbook.

We'll cover the full cycle: profiling, identifying root causes, and applying the right fix for the right problem. No cargo-culted useMemo everywhere, no unnecessary complexity. Just targeted solutions.

The Golden Rule Before We Start

Never optimize without measuring first. I've seen engineers spend a week wrapping everything in memo() and useMemo() only to discover the real bottleneck was a single synchronous localStorage read on every render. Profile first. Always.

Step 1: Profile with the React DevTools Profiler

Open Chrome DevTools, install the React Developer Tools extension, and navigate to the Profiler tab.

Click Record (the circle icon)
Perform the slow interaction
Click Stop

What you're looking for:

Flamechart — Which component took the longest to render?
Ranked chart — Sort by self time to find the actual culprit vs. components that are slow only because their children are slow
Why did this render? — Click any bar and look at the reason. This alone saves hours of guessing.

Pay special attention to components that render with (memo) — if they're still re-rendering, their props aren't stable. We'll fix that.

Step 2: Identify Your Problem Category

Performance issues in React almost always fall into one of four categories:

Category A: Unnecessary re-renders
A parent re-renders and takes down an entire subtree that hasn't actually changed.

Category B: Expensive computations on every render
A component does heavy work (sorting, filtering, transforming) that doesn't need to happen unless specific values change.

Category C: Too many components in the render tree
Large lists, tables, or grids rendering thousands of DOM nodes.

Category D: Waterfalls and layout thrash
Sequential data fetching, or reading layout properties (offsetHeight, getBoundingClientRect) that force style recalculations.

Knowing the category determines the fix. Let's walk through each.

Step 3: Fix Category A — Unnecessary Re-renders

The Setup

Here's a classic problem. A Dashboard component holds state, and every state update causes a deeply nested ExpensiveWidget to re-render — even though it doesn't use that state.

function Dashboard() {
  const [selectedTab, setSelectedTab] = useState('overview');

  return (
    <div>
      <TabBar selected={selectedTab} onSelect={setSelectedTab} />
      <ExpensiveWidget /> {/* Re-renders on every tab change. Why? */}
    </div>
  );
}

The Diagnosis

Open the Profiler, switch tabs, and click ExpensiveWidget. The "Why did this render?" panel will say: "The parent component rendered."

The Fix: Component Composition First, Memo Second

Before reaching for React.memo, ask whether you can restructure to avoid the problem entirely.

// ✅ Better: Extract state into a component that doesn't parent ExpensiveWidget
function Dashboard() {
  return (
    <div>
      <TabSection />      {/* Owns selectedTab state */}
      <ExpensiveWidget /> {/* Never re-renders due to tab changes */}
    </div>
  );
}

function TabSection() {
  const [selectedTab, setSelectedTab] = useState('overview');
  return <TabBar selected={selectedTab} onSelect={setSelectedTab} />;
}

This is the state colocation pattern. Moving state down to the smallest component that needs it eliminates re-render cascades without any memoization overhead.

When you can't restructure (e.g., the state is genuinely needed by multiple siblings), then use React.memo:

const ExpensiveWidget = React.memo(function ExpensiveWidget({ data }) {
  // Only re-renders when `data` changes by reference
});

Critical caveat: memo only works if props are referentially stable. If a parent passes an inline object or function, it breaks memo on every render.

// ❌ Breaks memo — new object reference on every render
<ExpensiveWidget config={{ theme: 'dark' }} />

// ✅ Stable reference
const config = useMemo(() => ({ theme: 'dark' }), []);
<ExpensiveWidget config={config} />

Same for callbacks:

// ❌ New function reference every render
<ExpensiveWidget onUpdate={() => doSomething(id)} />

// ✅ Stable reference
const handleUpdate = useCallback(() => doSomething(id), [id]);
<ExpensiveWidget onUpdate={handleUpdate} />

Step 4: Fix Category B — Expensive Computations

The Setup

function ProductList({ products, searchQuery }) {
  // This runs on EVERY render, even if products and searchQuery haven't changed
  const filtered = products
    .filter(p => p.name.toLowerCase().includes(searchQuery.toLowerCase()))
    .sort((a, b) => b.rating - a.rating);

  return filtered.map(p => <ProductCard key={p.id} product={p} />);
}

The Fix: useMemo

function ProductList({ products, searchQuery }) {
  const filtered = useMemo(() => {
    return products
      .filter(p => p.name.toLowerCase().includes(searchQuery.toLowerCase()))
      .sort((a, b) => b.rating - a.rating);
  }, [products, searchQuery]); // Only recalculates when these change

  return filtered.map(p => <ProductCard key={p.id} product={p} />);
}

When is this worth it? Run the computation in the Profiler and check its self-time. If it's consistently over 1-2ms and the component re-renders frequently, useMemo is justified. For simple operations like filtering a 10-item array, the memoization overhead often costs more than it saves.

Step 5: Fix Category C — Long Lists

Never render 10,000 DOM nodes. The browser can't handle it, and neither can React's reconciler.

The Fix: Virtualization with TanStack Virtual

npm install @tanstack/react-virtual

import { useVirtualizer } from '@tanstack/react-virtual';
import { useRef } from 'react';

function VirtualList({ items }) {
  const parentRef = useRef(null);

  const virtualizer = useVirtualizer({
    count: items.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 60, // Estimated row height in px
    overscan: 10,           // Render 10 extra rows above/below viewport
  });

  return (
    <div
      ref={parentRef}
      style={{ height: '600px', overflow: 'auto' }}
    >
      <div style={{ height: virtualizer.getTotalSize() }}>
        {virtualizer.getVirtualItems().map((virtualItem) => (
          <div
            key={virtualItem.key}
            style={{
              position: 'absolute',
              top: 0,
              left: 0,
              width: '100%',
              transform: `translateY(${virtualItem.start}px)`,
            }}
          >
            <ItemRow item={items[virtualItem.index]} />
          </div>
        ))}
      </div>
    </div>
  );
}

This renders only the rows visible in the viewport plus a small overscan buffer — typically 20-40 rows instead of thousands.

Step 6: Fix Category D — Data Fetching Waterfalls

This is the most impactful fix on this list, and the most often overlooked.

The Problem

function UserProfile({ userId }) {
  const { data: user } = useQuery(['user', userId], fetchUser);

  // This query can't start until the first one finishes
  const { data: posts } = useQuery(
    ['posts', user?.id],
    () => fetchPosts(user.id),
    { enabled: !!user }
  );
}

Two sequential network requests when they could be parallel.

The Fix: Parallel Queries

function UserProfile({ userId }) {
  const [userQuery, postsQuery] = useQueries({
    queries: [
      { queryKey: ['user', userId], queryFn: () => fetchUser(userId) },
      { queryKey: ['posts', userId], queryFn: () => fetchPosts(userId) },
    ],
  });

  // Both requests fire simultaneously
}

If you're using React Server Components or a framework like Next.js, push the data fetching up to the server layer and pass it down as props. Zero waterfalls, zero loading spinners for the user.

Step 7: Measure the Improvement

After every fix, go back to the Profiler and run the same interaction.

What to check:

Has total render time decreased?
Has the number of components in the commit decreased?
Do previously over-rendering components now say "Did not render" in the timeline?

Document before/after numbers. This matters for PR reviews and for building your own intuition about which fixes actually move the needle.

What I Don't Do Anymore

After years of doing this, here's what I've stopped wasting time on:

useMemo on primitive values. useMemo(() => userId + '-profile', [userId]) is pure overhead.

React.memo on every component by default. Some teams add it preemptively to all components. The overhead of comparing props on every render often outweighs the cost of just re-rendering simple components.

Chasing milliseconds on non-interactive paths. A page that takes 400ms to load feels fine. Optimize interactions first — clicks, typing, scrolling — because those are what users feel.

Conclusion

React performance work is mostly detective work. Profile first, categorize the problem, apply the targeted fix, measure the result. The engineers I've seen do this well aren't the ones who memorize all the APIs — they're the ones who stay curious, trust their profiling data, and resist the urge to optimize things that don't matter yet.

The next time a component feels slow, open the Profiler before you touch the code. The answer is usually already there.