DEV Community: Adam - The Developer

When Software Started Writing Software: A Developer’s History of AI

Adam - The Developer — Mon, 22 Jun 2026 08:06:29 +0000

If you've shipped software in the last three years, you've probably watched your job description quietly rewrite itself. You went from writing code, to writing code with an autocomplete, to writing code with a collaborator, to increasingly writing a spec and watching an agent write, test, and ship the code for you.

That didn't happen overnight. It's the latest chapter in a 70-year story that started with researchers trying to teach machines to play checkers. Let's walk through it, not as a dry timeline, but as the story of how "intelligence" kept getting redefined every time machines got good at the last definition.

1. The Symbolic Era: Intelligence as Logic (1950s–1980s)
2. Statistics Quietly Eats Symbols (1990s–2000s)
3. Deep Learning Breaks the Ceiling (2012–2017)
4. The Transformer and the Birth of "General-ish" Intelligence (2017–2022)
5. From Chatbot to Coworker: The Agentic Turn (2023–Today)
So What Changed, Really?

1. The Symbolic Era: Intelligence as Logic (1950s–1980s)

The founding bet of AI, made official at the 1956 Dartmouth Workshop, was simple and audacious: thought is computation. If you could represent knowledge as symbols and rules, and manipulate those symbols correctly, you'd get intelligence.

This gave us:

Logic Theorist (1956): proved mathematical theorems by searching through logical statements.
ELIZA (1966): pattern-matched your sentences back at you and convinced people it understood them. The first chatbot, and the first time humans projected understanding onto a system that had none.
Expert systems (1970s–80s): programs like MYCIN encoded a domain expert's rules as IF-THEN statements. MYCIN could diagnose bacterial infections about as well as a human specialist, using a few hundred hand-written rules.

This was weak, narrow intelligence in the most literal sense: a system that was a genius in one box and knew nothing outside it. The fatal flaw was scale, every rule had to be written by hand by a human expert. Knowledge didn't generalize, and it didn't learn from data. When funding agencies realized these systems couldn't handle the messiness of the real world, the money dried up. This was the first AI winter.

2. Statistics Quietly Eats Symbols (1990s–2000s)

While "AI" was a dirty word in grant applications, a different idea was gaining ground: instead of telling a machine the rules, show it examples and let it find the rules itself.

Neural networks had existed since the 1950s (the perceptron) but were widely written off after Minsky and Papert detailed their mathematical limits in Perceptrons (1969).
Backpropagation, popularized in 1986, gave multi-layer networks a real way to learn and yet networks still mostly lost to simpler methods for another two decades. The algorithm existing wasn't enough; there wasn't enough labeled data or compute to let it show what it could do. It sat half-revived, a promising idea nobody could afford to run at scale.
Support Vector Machines, decision trees, and Bayesian methods dominated practical machine learning, spam filters, recommendation engines, fraud detection.
IBM's Deep Blue beat Garry Kasparov in 1997, but largely through brute-force search over chess positions, not learning. Still narrow, still impressive.

This era's intelligence was statistical rather than logical: pattern recognition over labeled data. It worked well on narrow, well-defined tasks but needed mountains of hand-labeled examples and feature engineering done by humans. The "intelligence" was still mostly in the human designing the features the model was just fitting a curve.

3. Deep Learning Breaks the Ceiling (2012–2017)

The ingredients for the next leap had been sitting around for a decade: more data (the internet), more compute (GPUs originally built for video games), and algorithmic tricks for training deeper networks without them collapsing into noise. None of this looked inevitable at the time. Most of the field had moved on from neural networks; deep nets were a fringe bet kept alive by a small number of labs who kept getting told they were wasting their careers.

The spark was AlexNet (2012), a deep convolutional neural network that crushed the ImageNet image-classification competition, slashing the error rate compared to the next-best approach. That one result told the field something important: stack enough layers, feed them enough data, and the network finds its own features, no human feature engineering required. It wasn't a smooth continuation of the field's direction; it was closer to a coup. Within a couple of years, techniques that had been a punchline became the default starting point for almost every computer vision paper.

What followed was a five-year sprint:

**Word2Vec (2013) / GloVe (2014)**: words became vectors, and "meaning" became something you could do arithmetic on.
Generative Adversarial Networks (2014): two networks competing, one generating fakes, one detecting them, together learning to produce eerily convincing images.
AlphaGo (2016): beat the world's best Go player (the board game, not go run main.go energy) using deep learning plus reinforcement learning plus tree search, on a game once thought too intuitive for machines.

Each of these was still task-bound, a vision model couldn't write a sentence, a Go-playing model couldn't recognize a cat — but the skill inside each one was no longer handed to it by a human; the model discovered its own representation of the problem. That shift in mechanism, more than any single result, is what made the next jump possible.

4. The Transformer and the Birth of "General-ish" Intelligence (2017–2022)

In 2017, a Google paper titled "Attention Is All You Need" introduced the transformer architecture. Instead of processing text sequentially like older recurrent networks, transformers let every word attend to every other word at once. It was a better way to model sequences and it turned out to scale beautifully.

That architectural choice, combined with the realization that you could pretrain a single giant model on a huge slice of the internet and then adapt it to almost any language task, produced the GPT lineage:

GPT (2018) → GPT-2 (2019) → GPT-3 (2020): each generation showed that scaling up parameters and data kept producing qualitatively new abilities, not just marginal accuracy gains. GPT-3 could write code, translate, summarize, and hold a conversation, despite never being explicitly trained to do any of those things.
Instruction tuning and RLHF (2021–2022): raw language models predict the next token; they don't inherently want to be helpful. Techniques like reinforcement learning from human feedback turned raw next-token predictors into assistants that follow instructions and refuse harmful ones.
ChatGPT (November 2022): Sam Altman announced it on X with the energy of a minor release: "today we launched ChatGPT. try talking with it here." Understated copy for the moment the old era ended and a new history began. Research left the lab; your non-technical relatives showed up. A hundred million users in two months. The Turing Test stopped being a thought experiment and became something people ran into accidentally over breakfast.

This is the point where AI stopped meaning "deep in one box, blank everywhere else" and started meaning compositional: a single set of weights that could combine skills it was never explicitly trained to combine. One model could write a sonnet, debug Python, and explain the sonnet's meter not because it was three different systems, but because language turned out to be a surprisingly good universal interface to a huge range of human tasks.

5. From Chatbot to Coworker: The Agentic Turn (2023–Today)

A language model that just answers questions is a powerful autocomplete. The next phase of the story is about giving that model hands: the ability to call tools, write and execute code, browse the web, remember state across steps, and chain its own reasoning into multi-step plans.

A few threads converged here:

Tool use / function calling let models stop just describing actions and start taking them, querying a database, hitting an API, running a calculation, instead of guessing at the answer.
Retrieval-augmented generation (RAG) gave models access to information beyond their training data, grounding answers in real documents instead of frozen memory.
Chain-of-thought and reasoning models showed that letting a model "think out loud" before answering and eventually training it specifically to reason longer on hard problems, produced dramatically better results on math, logic, and multi-step planning.
Agentic frameworks stitched these into loops: plan → act → observe → revise. Wrapped in orchestration code, retry logic, and well-designed tools, a model could chase a goal across many steps instead of answering once and stopping. Left alone long enough, it still drifts or takes wrong turns, the scaffolding exists to catch that. "Agent" describes a system, not a self-sufficient mind.
Multi-agent orchestration: models that spin up other model instances to parallelize work, each with a narrower role, then combine results. The specialist of the symbolic era is back, except now it's a transformer playing a role inside a swarm coordinated by another transformer, instead of a human-written rule.

This is the world a developer in 2026 actually lives in. Code isn't just suggested line-by-line; it's planned, written across multiple files, tested, and debugged in a loop that needs less hands-on steering than it used to, though still real review, real guardrails, and real human judgment about when to trust the output. The same pattern shows up outside coding: research agents that browse, synthesize, and cite sources across dozens of pages; operations agents that read a ticket, check a calendar, and draft a response; design agents that take a brief and return a working prototype. None of this is autonomy in the strong sense yet. It's interactive capability, a model in a loop with tools and a feedback signal — and it's powerful precisely because of how tightly that loop is engineered, not in spite of it.

Easy to miss when you're staring at capability charts: every jump here was also an economics story. Expert systems died because expert time didn't scale. Statistical ML rode cheap labeled data and storage. Deep learning rode gaming GPUs. LLMs rode internet-scale data and transformer parallelism. Agents are having their moment because inference got cheap enough to run a model in a loop hundreds of times per task without laughing. The recurring question isn't "can we build it?" but it's "can we afford to run it enough times to be useful?" That bottleneck moved; it didn't disappear.

So What Changed, Really?

If you zoom out, the history of AI is a story about where the intelligence lives:

Era	Where the "smarts" lived
Symbolic AI	In rules a human expert wrote by hand
Statistical ML	In features a human engineer chose
Deep learning	In representations the model learned itself
Large language models	In patterns learned from most of the public internet
Agentic systems	In the model's own planning, tool use, and self-correction across time

Each era didn't replace the last so much as absorb it. Today's agents still do statistical pattern matching under the hood; they still occasionally fail in the brittle, overconfident ways the old expert systems did, just less often and less predictably.

If you compress the five eras above, there are really only three discontinuities that mattered:

Hand-coded intelligence: rules a human wrote (symbolic AI).
Learned representations: patterns a model found in data, with steadily less human-chosen structure (statistical ML → deep learning → LLMs).
Interactive systems: models that act, observe consequences, and revise, instead of just outputting a single answer (agents).

The five-era version tells a better story; the three-version compression is what actually changed underneath.

Shift one: who writes the rules — human or data.
Shift two: passive answer vs. active loop. Most of "AI got so much better" traces to one of those.

This isn't a straight march toward AGI. It's researchers repeatedly asking "what if the machine decided this part?" and finding that worked, once the economics finally allowed it.

Whether the next chapter is "agents that reliably run entire businesses" or "another winter while the hype outpaces the engineering" is genuinely an open question and depending on who you ask, both are already happening at once.

There Is No Perfect Solution in Software Development: Every Decision is a Tradeoff

Adam - The Developer — Mon, 15 Jun 2026 06:22:48 +0000

Most bad decisions in software engineering aren't made because the engineer chose wrong between two clear options. They're made because the engineer didn't realize they were making a choice at all.

You optimized for readability without noticing that particular loop runs a million times per second. You built for perfect flexibility without realizing you'd never actually need it. You shipped fast and acknowledged the technical debt—until the debt became someone else's problem, and by then it was too late to refactor.

The pattern: teams usually aren't choosing between two good options. They're choosing between one safe default and one speculative optimization, and calling it a tradeoff to feel better about it.

What Every Engineer Needs to Know About Tradeoffs
Classic Tradeoffs You'll Face
- Performance vs. Readability
- Flexibility vs. Simplicity
- Speed to Market vs. Technical Debt
- Scalability vs. Cost
- Security vs. Convenience
- The CAP Theorem: What It Actually Means
The Pattern: How Good Decisions Actually Get Made
How to Make Better Tradeoff Decisions
The Mark of Experience

What Every Engineer Needs to Know About Tradeoffs

There is no perfect solution. Every architecture, every algorithm, every design decision buys you something at the cost of something else. This isn't pessimism, it's the foundation of good engineering judgment.

But here's the catch: not all tradeoffs are 50/50. In practice, experienced engineers often default heavily one way and only deviate with evidence.

Classic Tradeoffs You'll Face

Performance vs. Readability

Here's what usually wins: readability. Unless you have a proven bottleneck backed by profiling data, optimize for clarity.

// Faster but harder to maintain
function processData(source: number[], offset: number, length: number): number[] {
  const result = new Array(length);
  for (let i = 0; i < length; i++) {
    result[i] = source[i + offset];
  }
  return result;
}

// Slower but immediately clear
function processData(source: number[], offset: number, length: number): number[] {
  return source
    .slice(offset, offset + length)
    .filter(x => x > 0)
    .map(x => x * 2);
}

The second version is probably fine. Premature optimization is still the root of all evil. The first example should only exist if:

you've profiled
you found this function is actually slow
you've measured that the optimization makes a meaningful difference

All three conditions are rarer than you'd think.

Flexibility vs. Simplicity

"Flexibility" often looks like smart future-proofing until you realize you'll never actually need it.

You build a generic plugin system because "we might need it." You abstract everything into interfaces because "we'll probably want to swap implementations." You create configuration options for scenarios that never materialize. Meanwhile, your simple code that handles exactly one thing is getting buried under layers of generality.

Ship the simple thing. If you actually need multiple use cases later, refactoring from concrete to generic is almost always easier than refactoring from over-engineered to usable. The exception: if you're building a library or platform that multiple teams depend on, flexibility becomes a real requirement, not speculation.

Most over-engineering is just ego disguised as foresight.

Speed to Market vs. Technical Debt

Ship in two weeks with known compromises? Or spend two months building something maintainable?

Both answers are right in different contexts. A startup with three months of runway and a saturated market needs speed. A fintech system handling billions in transactions needs stability. There's no universal answer.

Scalability vs. Cost

Premature scalability is usually just waste unless you have strong signals of growth.

You can architect for 100x your current traffic and be right. You can also architect for today's load and be right. The difference is that one cost money now, and the other might cost money later. Most teams choose wrong because they're optimizing for an imagined future instead of the constraints they actually face.

The right call: scale when you have evidence that growth is coming, not because it might happen. Growth that doesn't materialize? You've spent months and money on infrastructure that will never be used. Growth that does materialize and catches you off-guard? That's painful, but you'll fix it. The fix is usually cheaper than over-engineering.

If you are unsure whether you need scalability, you don't.

Security vs. Convenience

Require 2FA, complex passwords, and proof of identity? That's more secure. Users will also hate you.

Frictionless auth is delightful for users and a security nightmare. You're balancing two legitimate concerns.

The CAP Theorem: What It Actually Means

Everything above applies to a single application you control end to end. This one is different — it belongs to distributed systems.

A distributed system is software spread across multiple machines that coordinate over a network. Your API talking to one database is distributed in the loose sense, but CAP really starts to matter when the same data lives in more than one place: a primary with read replicas, a Redis cluster, a multi-region deployment. The moment you have copies of data on separate nodes, connected by a network that can fail, you inherit tradeoffs you do not get on a single server.

The CAP theorem names the central one. The textbook version says: "Pick any two of Consistency, Availability, and Partition Tolerance."

Here's what actually happens: In any real distributed system, partition tolerance is not optional. Network failures will happen. So the real choice is between Consistency and Availability when the network breaks.

CP systems fail safely when they can't guarantee consistency. A banking app might do this, it's better to be down than serve wrong balances.
AP systems stay up and serve whatever data they have. A social feed might do this, slightly stale likes are better than a 503.

The code doesn't need to be complicated:

// CP: fail rather than serve wrong data
async function getBalance(userId: string): Promise<number> {
  const result = await database.query('SELECT balance FROM accounts WHERE id = $1', [userId]);
  return result[0].balance;
  // If database is unreachable, the request fails. That's the design.
}

// AP: serve cached data with a staleness flag
async function getBalance(userId: string): Promise<{ balance: number; stale: boolean }> {
  try {
    const result = await database.query('SELECT balance FROM accounts WHERE id = $1', [userId]);
    return { balance: result[0].balance, stale: false };
  } catch (error) {
    // Partition: return whatever we have cached
    return { balance: await cache.get(userId), stale: true };
  }
}

Choose based on what breaks is worse: being wrong (CP) or being unavailable (AP).

The Pattern: How Good Decisions Actually Get Made

Once you recognize that a tradeoff exists, you're already halfway to making a good decision. You can be intentional about what you're trading and why. You can explain it to your team. You can revisit it later if your constraints change.

Without that awareness? You end up optimizing for readability on a loop that runs a million times per second. You build flexibility you'll never need. You ship fast and defer the cost to future-you.

Here's what separates functional teams from dysfunctional ones: functional teams argue about which tradeoff they're making. Dysfunctional teams don't realize there's a choice at all, and they compound the costs by pretending it was inevitable.

How to Make Better Tradeoff Decisions

1. Name the tradeoff explicitly
Don't say "should we use Redis?" Say "are we optimizing for speed or operational simplicity?"

2. Understand your constraints
What actually matters in your context? A library used by millions needs different tradeoffs than an internal tool used by five people.

3. Make it reversible if possible (but know the real limits)
Refactoring from concrete to generic is usually easier than the reverse. Local code changes are easy to undo. But reversibility has hard boundaries.

True reversibility: Internal implementation details, local code scope, nothing that touches user-facing behavior.

False reversibility: Anything that becomes business-critical, anything customers build workflows around, anything that spreads to multiple teams. A quick hack that ships and immediately gets embedded in product behavior doesn't refactor cleanly six months later. The team has built processes around it. Customers depend on it. Other engineers have written code that relies on it. Reversibility was an illusion from the moment the code touched production.

Know which category your decision falls into before you ship it as temporary.

4. Document your reasoning
Future you (and your teammates) will thank you. "We chose simple over performant here because X" is gold.

5. Revisit your assumptions
Your constraints change. What was the right tradeoff six months ago might be wrong now. That's not failure—that's growth.

The Mark of Experience

Here's what changes as you get better at this:

Seniors aren't less stressed, they're stressed about the right things. They don't waste energy trying to eliminate uncertainty. They can't. Uncertainty is part of the job. Instead, they focus on reducing risk and keeping decisions reversible where possible.

They ask good questions: "What happens if we're wrong about this?" "What would make us want to undo this decision?" "Do we have evidence this is actually a bottleneck?" They make explicit choices, document the tradeoffs, and move forward without second-guessing.

The skill isn't knowing everything. It's making conscious tradeoffs and living with the consequences without pretending there was ever a perfect choice.

The Hidden Machinery Behind Background Jobs

Adam - The Developer — Tue, 09 Jun 2026 07:27:48 +0000

This will be a boring article today, but I wanted to write it after talking to a developer who genuinely believed background jobs are the key to faster software.

They’re not hard to add. They’re easy to write, easy to deploy, and deceptively minimal, depending on how much complexity you’re willing to ignore elsewhere.

Let’s talk about something most of us use every day but rarely think about.

You enqueue a job (or, in my language, “drop something into a queue”). Your API returns 202 Accepted in 3 milliseconds. It feels good, responsive, non-blocking, event-driven. All the right words.

But between queue.enqueue() and a worker picking it up, a lot happens across your app, the OS, the network stack, and the broker. Most of it is invisible. All of it matters when something breaks at 2am.

This is that journey, layer by layer. By the end, you’ll have a clearer picture of what “fast” and “non-blocking” actually mean when a queue is involved.

What We Think Is Happening
Layer 1: Your Application Code
Layer 2: The Network Stack and the Kernel
Layer 3: Inside the Broker
- Redis
- RabbitMQ
- Kafka
Layer 4: The Event Loop, and What Is Actually Powering It
- How It Evolved
Layer 5: The Worker, Acknowledgments, and What "At Least Once" Actually Means
Layer 6: The Things That Quietly Go Wrong
What "Fast" Actually Means
The Full Journey, Summarized
Closing Thoughts

What We Think Is Happening

Most of us carry a mental model that looks roughly like this:

Producer  →  [ Queue ]  →  Worker

Clean. Simple. And not wrong, exactly, just kinda incomplete. The full picture looks more like:

Producer
  → serialize payload to bytes
  → write bytes to TCP socket
  → kernel buffers → NIC → wire
  → broker receives bytes
  → broker deserializes, routes, stores message
  → broker sends ACK to producer
  → worker connects and subscribes
  → broker reads message from storage
  → broker sends to worker over TCP
  → worker deserializes → your function runs
  → worker sends ACK back to broker
  → broker marks message delivered, removes it

Every one of those arrows is real work. Let's walk through each one.

Layer 1: Your Application Code

Here is a fairly typical job enqueue in TypeScript using BullMQ:

import { Queue } from 'bullmq';

const emailQueue = new Queue('emails', {
  connection: { host: 'localhost', port: 6379 }
});

await emailQueue.add('sendWelcome', {
  userId: 'usr_abc123',
  to: 'user@example.com',
  template: 'welcome-v2',
});

console.log('Job enqueued'); // Returns in ~3ms

That await resolves fast. But a few things happened before it did.

Serialization. Your payload object got converted to a flat sequence of bytes. In BullMQ's case, this is JSON. Every nested field, every string, every number, reduced to a string that can cross a process boundary. Your clean TypeScript object does not survive the trip; its data does.

Message wrapping. The payload gets wrapped in an envelope before it goes anywhere. Job ID, timestamp, retry count, delay, priority, queue name. Depending on the broker, this metadata overhead can be comparable in size to your actual payload for small messages.

Connection reuse. BullMQ does not open a new TCP connection to Redis for every job. It keeps a pool of connections alive. Enqueuing borrows one of those connections, writes the message bytes, and returns it. If every connection in the pool is busy, your await waits here. Not in some clean async queue, but blocked, waiting for a connection to free up.

So even before a byte has left your machine, your "fast, non-blocking enqueue" has already done serialization, object allocation, pool management, and potentially some waiting. Still fast. Just not free.

Layer 2: The Network Stack and the Kernel

When the library writes to the socket, your application hands control to the OS kernel. This boundary has a name: a syscall. Roughly speaking, it is your code saying "I need to do something I am not allowed to do myself" and the kernel taking over.

On Linux, that write looks like this at the system level:

// What your queue library is ultimately triggering
ssize_t bytes_written = write(socket_fd, message_bytes, message_length);

A few things happen in sequence:

Your bytes are copied from your process's memory into the kernel's TCP send buffer. This is a separate memory region. Once copied, your code cannot touch those bytes anymore.
The kernel's TCP stack breaks the data into segments, adds sequence numbers and checksums, and hands them to the network driver.
The NIC DMA-transfers the data to its own buffer and puts it on the wire.

the important part here: write() returns before the data is confirmed received by the broker. It returns when the kernel has accepted the bytes. The actual network transfer happens asynchronously behind your process's back.

When your enqueue call returns quickly, you have confirmed the kernel accepted your bytes. Not that the broker received them.

Layer 3: Inside the Broker

This is where things differ meaningfully depending on which broker you are using. Let's look at three common ones.

Redis

Redis works entirely in memory. When the message arrives over TCP, Redis's event loop reads the bytes from the socket, deserializes the command, and modifies an in-memory data structure. For a BullMQ job, this is an entry in a Redis sorted set or list, depending on job type.

No disk is touched in the default path. This is why Redis is fast. It is also the catch: a crash or restart with default settings means everything in memory is gone. Your enqueued jobs, vanished, with no error and no log entry.

Redis does support persistence (RDB snapshots, AOF logging), but these are asynchronous by default. There is always a small window between when you enqueue and when that data is safely written to disk. That window is your risk to size and accept consciously.

RabbitMQ

RabbitMQ has a more layered approach to storage. A message arrives via AMQP, gets deserialized, passes through the exchange's routing logic (which queue does this message belong to, based on binding keys and patterns), and lands in the target queue.

Each message carries more weight than it looks. A payload of 1KB actually occupies roughly 2KB in RabbitMQ's memory once internal metadata is factored in. The internal database keeps an in-memory copy of all data, even on disk nodes.

For persistent messages, RabbitMQ writes to disk before sending the ACK back to your producer. If memory pressure climbs above a configurable threshold, RabbitMQ starts paging messages to disk. If it keeps climbing, RabbitMQ does something that surprises most people who have not read the docs: it blocks publishers. Stops reading from their TCP sockets entirely. Your producer's write() call hangs. Your enqueue appears to freeze. The queue is not broken. It is telling you it is full and it cannot accept more until workers catch up.

Kafka

Kafka treats the problem differently at a fundamental level. A message is not stored in a data structure in memory. It is appended sequentially to a log file on disk.

Sequential disk writes on modern SSDs and NVMe drives are extremely fast because they avoid seek times entirely. This is where much of Kafka's throughput comes from. Consumer progress is tracked as a simple integer, an offset into that log file. To read the next message, a consumer increments its offset and fetches. To replay messages, it resets the offset.

This model means multiple independent consumers can read the same data, message replay is trivially possible, and retention is time-based rather than acknowledgment-based. It also means Kafka is disk-heavy and its throughput degrades with larger messages. NVMe storage is not optional for serious Kafka deployments.

Layer 4: The Event Loop, and What Is Actually Powering It

This is the part that ties everything together. Your broker, your async worker, your web framework: all of them are built on the same foundational mechanism.

To understand it, we need to understand the problem it exists to solve.

A server that handles connections by blocking on a socket read can only handle one connection per thread. To handle 10,000 concurrent connections, you would need 10,000 threads. A thread typically needs 1 to 8 MB of stack space. That is a lot of RAM spent on processes that are almost entirely idle, just waiting for data.

The solution is I/O multiplexing: a single thread monitors thousands of file descriptors and reacts only when one actually has data.

How It Evolved

select() was Unix's first answer. You pass the kernel a bitmask of file descriptors to watch. The kernel scans every one of them on every call to see which are ready:

// kernel scans ALL of these on every single call
fd_set read_fds;
FD_ZERO(&read_fds);
FD_SET(sock1, &read_fds);
FD_SET(sock2, &read_fds);
// ... up to 1024 max

select(max_fd + 1, &read_fds, NULL, NULL, &timeout);
// returns, then you scan the whole bitmask yourself to find who is ready

This is O(n) per call, where n is your total number of watched file descriptors. With thousands of connections, this burns meaningful CPU just on scanning. Plus there is a hard ceiling of 1,024 descriptors. Fine for an early-nineties Unix workstation. Not fine for anything built in the last twenty years.

poll() removed the 1,024 limit but kept the linear scan. A step forward, not a solution.

epoll() is the modern Linux answer. The philosophy shifts: instead of asking the kernel "which of these are ready right now?", you register your file descriptors once and say "notify me when something changes."

// create an epoll instance
// the kernel allocates a red-black tree and a ready list internally
int epfd = epoll_create1(0);

// register a file descriptor once
// kernel inserts it into the red-black tree — O(log n)
struct epoll_event ev;
ev.events = EPOLLIN;       // wake me when data is available to read
ev.data.fd = socket_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, socket_fd, &ev);

// The event loop — this is what Node.js, Redis, Nginx all do at their core
struct epoll_event events[MAX_EVENTS];
while (1) {
    // process sleeps here, consuming zero CPU
    // Kernel wakes it when at least one FD has data
    int n = epoll_wait(epfd, events, MAX_EVENTS, -1);

    // n is only the count of *ready* file descriptors, not total registered ones
    for (int i = 0; i < n; i++) {
        handle_event(events[i].data.fd);
    }
}

When epoll_create1() is called, the kernel allocates two internal structures: a red-black tree for all registered file descriptors (insertion and lookup in O(log n)), and a linked list for descriptors that currently have data ready.

When epoll_wait() is called, the process is suspended and consumes no CPU.

When a network packet arrives for one of your registered sockets, the NIC fires an interrupt. The kernel processes the incoming data and a callback moves that socket's file descriptor from the red-black tree to the ready list. epoll_wait() wakes up and returns only the descriptors that are ready.

With select, the kernel scans your entire list on every call regardless of how many are actually ready. With epoll, the kernel does the bookkeeping internally and only tells you about the ones you care about. For a server with 10,000 connected clients where 3 of them sent data right now, select scans 10,000, epoll returns 3.

This is why:

A single-threaded Node.js process can handle tens of thousands of concurrent connections.
Redis processes millions of operations per second on one thread.
Nginx serves enormous traffic without spawning thousands of OS threads.

Your event-driven architecture is, at its foundation, a process sleeping in the kernel, waiting to be woken by a network interrupt.

Layer 5: The Worker, Acknowledgments, and What "At Least Once" Actually Means

Below is a TypeScript worker consuming from the same queue:

import { Worker } from 'bullmq';

const worker = new Worker('emails', async (job) => {
  const { userId, to, template } = job.data;

  await sendEmail({ to, template, userId });
  // Ii we reach here without throwing, BullMQ sends the ACK automatically
  // if we throw, BullMQ sends a NACK and schedules a retry

}, {
  connection: { host: 'localhost', port: 6379 },
  concurrency: 5,   // how many jobs this worker handles in parallel
});

Simple from the outside. Under the hood, the worker process opened a TCP connection to Redis, subscribed to the queue, and entered its own event loop. From the OS's perspective, it is a sleeping process blocked on a socket read, parked in the kernel's wait queue, consuming no CPU.

When Redis has a job ready, it sends data over TCP. The kernel receives the bytes, the socket becomes readable, the wait queue callback fires, the process wakes, BullMQ deserializes the job data, and your function is called.

When your function returns without throwing, BullMQ sends an ACK to Redis. Redis marks the job complete. If your function throws before that ACK is sent, the job stays in an active state. After a configurable timeout, it gets requeued.

This is at-least-once delivery. Your function will be called at minimum once. It may be called more than once. Here is why that matters in practice:

// Unsafe: if this crashes after the charge but before the receipt,
// the job retries and the customer gets charged twice
async function processPaymentJob(job: Job) {
  await chargeCustomer(job.data.customerId, job.data.amount);
  await sendReceipt(job.data.email);
}

// Safer: the idempotency key ensures a duplicate call
// is treated as the same operation, not a new one
async function processPaymentJob(job: Job) {
  await chargeCustomer(job.data.customerId, job.data.amount, {
    // Idempotency is not a nice-to-have in a queue-based system. 
    // It is a correctness requirement for any handler that makes side effects in the outside world.
    idempotencyKey: job.id,
  });
  await sendReceipt(job.data.email);
}

Layer 6: The Things That Quietly Go Wrong

Now that we can see the full path, these failure modes are a lot less surprising.

The queue fills up and nobody is watching. Workers fall behind. Messages pile up. RabbitMQ reaches its memory threshold and stops accepting new messages. Your producers' TCP writes start hanging. Your API response times climb. Engineers look for a slow database query. Add queue depth and consumer lag to your dashboards and save everyone a confusing hour.

Data loss because persistence was not configured. Redis with default settings holds everything in memory. A clean deployment restart flushes the queue. No error is thrown because nothing went wrong from the broker's perspective. The data simply stops existing. Enable AOF persistence and understand the durability tradeoff you are making before your first production incident.

The dead letter queue fills up unnoticed. A dead letter queue is where failed jobs end up after repeated retries. It’s easy to ignore because nothing actively lives there by default. But that’s exactly the problem. If you don’t build a consumer for it, and don’t monitor its depth, you can quietly accumulate months of failed work without realizing it. By the time you notice, you’re just gonna be digging through history of dead queues.

Duplicate processing because the handler is not idempotent. A worker completes its work, then crashes before ACKing. The broker redelivers. The external side effect runs twice. This has caused real double-charges, duplicate emails, and inconsistent records at real companies.

A blocking call inside an async worker. If your handler makes a synchronous blocking call, it stalls the event loop for the duration. No other messages are processed. Throughput drops to the speed of the slowest synchronous operation. Use async drivers for databases, HTTP clients, and file I/O inside workers.

What "Fast" Actually Means

When we say a queue makes an endpoint faster, we mean something specific: the HTTP response no longer waits for the work to finish. The work itself takes the same amount of time. Often more, when you factor in serialization, network round trips to the broker, storage, retrieval, deserialization, and worker execution.

What changed is when the user gets their response. Not how long the work takes.

This is genuinely valuable. Decoupling user-facing latency from background work is a real improvement. But it is a different thing than making work faster, and conflating the two leads to queues in places that add complexity without benefit, and missing queues in places where the decoupling would genuinely help.

A queue earns its place when the work is not needed to form the response, the work is slow enough that waiting feels bad, the work is safe to retry, and the producer and consumer need to scale independently.

A queue adds complexity without clear payoff when you need the result to respond, your latency budget is too tight for broker round trips, or the operation is fast enough that doing it inline is simpler and easier to observe.

The Full Journey, Summarized

Your TypeScript code
  ↓  JSON.stringify → bytes allocated in your process memory
  ↓  write() syscall → bytes copied to kernel TCP send buffer
  ↓  kernel TCP stack → NIC DMA transfer → wire

Broker process (Redis / RabbitMQ / Kafka)
  ↓  epoll_wait() wakes on incoming socket data
  ↓  deserialize bytes → route → store (RAM / disk / log file)
  ↓  ACK sent back to producer over TCP

Worker process
  ↓  sleeping in kernel wait queue, zero CPU consumption
  ↓  broker pushes job data over TCP
  ↓  kernel wakes worker via socket callback
  ↓  deserialize → your async handler function runs
  ↓  ACK on success → broker removes job
  ↓  throw on failure → broker requeues after timeout

Every arrow is real work with real cost and real failure modes. None of it is magic. All of it is understandable, and understanding it makes you a meaningfully better engineer of the systems that depend on it.

Closing

Queues and background jobs are genuinely good tools. The resilience they add, the ability to absorb traffic spikes, retry failures gracefully, and let producers and consumers scale independently — all of that is real and worth the added complexity.

The point is not to be wary of them. It is to understand what you are working with so you can configure them thoughtfully, monitor the right things, and know where to look when something behaves unexpectedly.

The queue depth is a metric worth watching. The dead letter queue is an inbox worth reading. The ACK timeout is a contract with the broker worth understanding.

Keep an eye on those three and your queues will mostly be a quiet, reliable part of your system doing exactly what they promised.

When Duplicate Code Is the Better Design

Adam - The Developer — Mon, 01 Jun 2026 06:09:57 +0000

You've seen the developer. Maybe you are the developer.

They discover DRY — ✨ Don't Repeat Yourself ✨ — and something switches in their brain. A primal need awakens. Every duplicated string, every similar-looking function, every pair of lines that rhyme in the wrong light becomes a personal affront. An itch. A moral failing.

Two weeks later, their codebase looks like a game of Jenga where every piece is also load-bearing, also abstract, also parametrized six ways to Sunday, and also, crucially, completely impossible to understand.

Congratulations. You've achieved ✨ DRY ✨. You've also achieved a codebase that will ruin your next three Fridays and everyone's.

What DRY Actually Says (and Doesn't)

DRY comes from The Pragmatic Programmer by Andy Hunt and Dave Thomas. The actual rule is:

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

Notice what it says: knowledge. it's not code. it's not characters. it's not "things that look similar when squinted at from across the room."

It says knowledge.

The principle is about avoiding duplicated intent and logic — not scrubbing every repeated character like you're laundering evidence. But somewhere between the book and the keyboard, people stopped reading and started pattern-matching like raccoons sorting shiny garbage:

"If two lines of code look alike, merge them immediately or you're morally bankrupt, professionally suspect, and probably the reason standups run long."

That's not DRY. That's aesthetic OCD with a philosophy degree and a GitHub contribution graph to protect.

The Taxonomy of DRY Crimes

Crime #1: Abstracting Coincidental Similarity

// Two functions that happen to look the same TODAY
function formatUserName(user) {
  return `${user.firstName} ${user.lastName}`;
}

function formatAuthorName(author) {
  return `${author.firstName} ${author.lastName}`;
}

The classic DRY-brain response: "These are identical! Extract!"

// The abstraction
function formatName(entity) {
  return `${entity.firstName} ${entity.lastName}`;
}

Fine. Harmless, even. Like a campfire in dry grass. Six months later, user names want a salutation, author names want a pen name fallback, and your cute little formatName has metastasized into a fifteen-parameter horror show with an enum called NameFormattingStrategy — the kind of function that needs its own onboarding doc and makes junior devs reconsider their career choices.

The duplication wasn't a bug. It was two different things that happened to share a shape for one Tuesday. A user is not an author. Their names evolve on different timelines. The duplicate code was whispering that — you heard "refactor opportunity" and built a cage instead.

Crime #2: The Abstraction That Needs a Manual

// Before: readable in 3 seconds
function getActiveAdminUsers(users) {
  return users.filter(u => u.isActive && u.role === 'admin');
}

// After: DRY'd into a puzzle box
function filterEntities(collection, predicates, options = {}) {
  const { limit, sortBy, transform } = options;
  const filtered = collection.filter(item =>
    predicates.every(pred => pred(item))
  );
  const sorted = sortBy ? filtered.sort(sortBy) : filtered;
  const limited = limit ? sorted.slice(0, limit) : sorted;
  return transform ? limited.map(transform) : limited;
}

// Usage (good luck, new hire)
filterEntities(users, [u => u.isActive, u => u.role === 'admin']);

You saved four lines. You created a filterEntities function that now silently accumulates every filtering need in your entire app, grows to 200 lines, and gets passed to new developers with the haunted look of someone handing off a cursed object.

The original function had a name. It was easy to understand, it told a simple story, getActiveAdminUsers is self-documenting. Your generalized thing is a puzzle.

Code is read far more than it's written. Abstractions are not free — they are paid for in comprehension, every single time someone opens that file.

Crime #3: DRY Across Wrong Boundaries

The most insidious form. And unlike the toy examples above, this one has a body count.

Every backend dev has seen this happen. You're building a notification system. You have email, SMS, push, and in-app notifications. They all take a user, a type, and some options. They look identical at the call site:

// v1 — reasonable. clean. you feel good about yourself.
sendNotification(user, 'order_confirmed', { orderId });

The abstraction makes sense. You write one function. You route internally. Ship it.

Then marketing wants to send a promotional email blast. Different thing, same function — but now you need an isMarketing flag because marketing emails have unsubscribe footers and transactional ones don't.

Then legal needs CAN-SPAM compliance on marketing sends. Different opt-out logic per locale. Now you need locale and complianceRules.

Then mobile push notifications need to respect iOS quiet hours, which email doesn't care about. Add respectQuietHours.

Then in-app notifications don't go through any external service at all — they're just a database write — but they're still "notifications" so they stay in the function.

Then SMS gets a character limit and needs message chunking logic that email will never need.

Eighteen months after that clean sendNotification(user, type, options), you have:

// v∞ — the function that consumed itself
async function sendNotification(
  user: User,
  type: NotificationType,
  options: NotificationOptions,
  channel: 'email' | 'sms' | 'push' | 'in_app',
  isMarketing: boolean,
  isTransactional: boolean,
  locale: string,
  complianceRules: ComplianceConfig,
  respectQuietHours: boolean,
  chunkIfOverLimit: boolean,
  bypassOptOut: boolean, // "just this once, for the launch"
  trackingPixel?: string,
) {
  if (channel === 'email') {
    if (isMarketing) {
      // 40 lines of compliance logic
    } else {
      // 30 lines of transactional logic
    }
  } else if (channel === 'sms') {
    // 50 lines that have nothing to do with email
  } else if (channel === 'push') {
    // 45 lines that have nothing to do with SMS
  } else if (channel === 'in_app') {
    // just writes to a table but must pass through this gauntlet anyway
  }
}

This function is now 300 lines. It has no tests that actually cover all the flag combinations — there are 2⁷ of them, good luck. Every engineer who touches it adds one parameter at the top and one if branch somewhere in the middle, and prays they didn't break the Malaysian SMS path.

You have not DRY'd your code. You have built a load-bearing monolith disguised as a helper function.

The actual fix is humbling: email, SMS, push, and in-app were never the same thing. They shared a surface-level interface and nothing else. They have different rate limits, different compliance regimes, different retry logic, different failure modes, and different delivery guarantees. The right design was always:

sendEmail(user, template, options);
sendSms(user, message, options);
sendPushNotification(user, payload, options);
createInAppNotification(user, content);

Yes, it's four functions. Yes, some options are repeated across them. That's fine — the repetition is honest. Each function can evolve independently. The SMS team can add chunking without touching the email function. Legal can update the CAN-SPAM logic without a regression on push. A new engineer can read sendEmail and understand sendEmail without holding the entire notification universe in their head.

The shared abstraction didn't eliminate complexity. It hid it, then grew it, then held it hostage.

Crime #4: The Generic Repository That Ate Your Domain

Every backend dev hits this phase. You have UserService, OrderService, ProductService. They all need to fetch things from the database. The queries look suspiciously similar:

// Three services, three nearly identical queries. Your DRY alarm is screaming.
async findAllUsers() {
  return db.users.findMany({ where: { deletedAt: null } });
}

async findAllOrders() {
  return db.orders.findMany({ where: { status: { not: 'draft' } } });
}

async findAllProducts() {
  return db.products.findMany({ where: { isPublished: true } });
}

The fix writes itself. You extract a base class. You add generics. You feel like you're finally doing real architecture:

// The abstraction that will haunt three teams
abstract class BaseRepository<T> {
  abstract table: string;

  async findAll(filters?: Record<string, unknown>) {
    return db.query(this.table, { where: filters });
  }

  async findOne(id: string) {
    return db.query(this.table, { where: { id } });
  }

  async findPaginated(page: number, limit: number, filters?: Record<string, unknown>) {
    const offset = (page - 1) * limit;
    const [data, total] = await Promise.all([
      db.query(this.table, { where: filters, limit, offset }),
      db.count(this.table, { where: filters }),
    ]);
    return { data, total, page, limit };
  }
}

class UserRepository extends BaseRepository<User> { table = 'users'; }
class OrderRepository extends BaseRepository<Order> { table = 'orders'; }
class ProductRepository extends BaseRepository<Product> { table = 'products'; }

Beautiful. Reusable. You deleted forty lines and posted about it in Slack. Life is good.

Then product management asks for order search with customer name, date range, and payment status — but only for admins, and only orders that haven't been refunded unless the refund was partial. Your findPaginated now accepts a QueryOptions object with twelve optional fields and a include array that half the team misconfigures.

Then users need soft-delete scoping, role-based visibility, and a "last active" sort that requires a join. You override findAll in UserRepository. Then you override findPaginated too. The base class is now mostly dead code that new hires still have to read.

Then products need full-text search, category trees, and inventory counts from a warehouse table in another service. Someone adds findPaginatedWithSearch. Someone else adds findPaginatedWithJoins. The base class grows a buildQuery hook, then a QueryBuilder parameter, then an escape hatch called rawQueryOverride that three repositories use and nobody documents.

Eighteen months later:

// v∞ — BaseRepository, but make it suffer
async findPaginated<T extends Entity>(
  page: number,
  limit: number,
  filters?: FilterMap,
  options?: {
    include?: IncludeMap;
    joins?: JoinConfig[];
    search?: SearchConfig;
    sort?: SortConfig | SortConfig[];
    scope?: 'admin' | 'public' | 'internal';
    softDelete?: boolean;
    bypassTenantScope?: boolean; // "temporary, for the migration"
    aggregate?: AggregateConfig;
    cursor?: string;
    transform?: (row: T) => unknown;
  }
): Promise<PaginatedResult<T | TransformedRow<typeof options>>> {
  // 180 lines of conditional query assembly
  // every repository passes a different options shape
  // the type signature is longer than most functions it replaces
}

You have not eliminated duplication. You have built a generic pagination framework that every entity in your system must awkwardly fit into, like forcing every piece of furniture through the same IKEA allen wrench.

The honest version was always:

// UserRepository — boring, explicit, correct
async findActiveUsersForAdmin(page: number, limit: number) { /* ... */ }

// OrderRepository — different domain, different query
async findOrdersForDashboard(filters: OrderDashboardFilters) { /* ... */ }

// ProductRepository — nobody else's problem
async findPublishedProductsWithInventory(categoryId: string) { /* ... */ }

Yes, they all paginate. Yes, they all query a database. That's infrastructure similarity, not domain knowledge. Users, orders, and products don't share a reason to change — they share a SQL dialect. Conflating those two is how you end up with a BaseEntityManagerFactoryHelperUtil and a Jira ticket titled "refactor findPaginated (blocked: needs architect approval)."

Pagination is not a domain concept. It's a transport detail. Your repository layer is not a place to build a query DSL because SELECT statements rhymed once.

The Principle You Actually Need: AHA

Sandi Metz — of Practical Object-Oriented Design fame — offers the antidote:

AHA: Avoid Hasty Abstractions.

The rule: prefer duplication over the wrong abstraction.

A wrong abstraction is worse than duplication because:

Duplication is visible and easy to fix
A wrong abstraction is load-bearing, hard to see, and expensive to undo
People are afraid to delete abstractions, so they pile parameters on top until it collapses

The heuristic she and others suggest: wait for the third time. Once — write it. Twice — note the repetition. Three times — now think about what abstraction, if any, makes sense. By then you have enough examples to see the actual shape of the knowledge, not just the accidental shape of the code.

When DRY Is Right

To be fair to the principle: DRY is genuinely critical in the right places.

Business rules. The formula for calculating interest, the rule for what makes a user "active," the threshold for triggering an alert — these must live in exactly one place. When the business logic changes, you want to change exactly one thing.

Configuration. A base URL hardcoded in twelve files is twelve places a typo can happen. That's rightfully DRY.

Data schemas. Your database schema and your validation schema should not diverge because you copy-pasted them. Derive one from the other.

The test for whether something should be DRY: if this thing needs to change, how many places need to change with it, and do those places share a reason to change?

If yes — DRY it.

If they just look similar today — leave it.

The Real Anti-Pattern DRY Is Trying to Fight

DRY's real enemy was never "duplicate code." It was duplicate knowledge — the same business rule, scattered across the system, slowly drifting out of sync.

The nightmare scenario: your pricing logic is in the database trigger, the API controller, the frontend calculation, and a comment in a Slack message from 2019. When pricing changes, you find three of them. The fourth one quietly disagrees for six months, occasionally giving users the wrong number, and you never know why.

That's what DRY is for. Not for making your formatName function 40% more reusable.

A Checklist for Before You Abstract

Before you extract that abstraction, ask:

Is this duplicate knowledge, or duplicate shape? Two things can look alike for different reasons.
Can I name this abstraction clearly? If you're reaching for processEntityData or handleThing, stop. The abstraction isn't real yet.
What happens when one usage changes? If you can't change the abstraction without worrying about the other usages, it's too coupled.
Am I doing this because it's right, or because repetition makes me uncomfortable? Valid question. The answer matters.

Closing

DRY is a heuristic, not a commandment. It was written to fight a specific enemy: knowledge duplication causing systems to rot. It was not written to make your codebase a shrine to abstraction.

The best codebases I've read had a little repetition in them. Deliberate repetition. The kind where someone clearly decided "these two things look alike but they're not the same thing, and I'm going to leave them separate so they can evolve separately."

That's not laziness. That's wisdom.

Write the thing twice if you have to. Your future self, reading the code at 11pm with no context, will thank you for the clarity.

Minimal Code Doesn’t Mean Stable Code

Adam - The Developer — Tue, 26 May 2026 04:15:08 +0000

The argument sounds reasonable: fewer lines of code mean fewer bugs. Simpler to review, easier to reason about, less surface area for defects. Sounds great. It's true. But it's also incomplete.

The problem starts when backend developers treat production systems like homework assignments. In a single-process app:

you control execution. You know the order. Threads might race, but at least they share the same memory and clock.

Once you have APIs talking to databases, webhooks firing at midnight, async jobs on a queue, and three replicas behind a load balancer, the failure modes multiply: connections drop, messages arrive out of order, clocks disagree, and partial failures show up at 3 AM on Tuesdays.

Trimming code doesn't make any of that go away. It just hides the complexity until something breaks.

When Minimal Code Meets Production

Consider what happens when your minimalist masterpiece meets reality:

Your service temporarily loses connection to the database for 30 seconds. Your code has no timeout logic. Requests hang. Users refresh. More requests queue up. Eventually something breaks.

Two instances process the same webhook because you thought "that probably won't happen." No idempotency key, so the charge runs twice. Your balance sheet now has an extra $50,000 in it. Your accountant is confused. Your manager is less confused.

A worker crashes mid-operation. There's no recovery mechanism. The transaction is abandoned in an inconsistent state. Your data is now in a state that violates every assumption you made about how it should look.

A retry storm after a downstream blip hammers your API because nothing backs off or deduplicates. Rate limits trip. Legitimate traffic gets dropped. You're debugging an outage caused by code that "handled errors" by logging and returning.

None of these are prevented by writing less. They're prevented by writing the boring safeguards you skipped because they looked redundant.

What Production Actually Requires

Modern backend systems need safeguards that simple applications never had to think about:

Idempotency. Every operation must be safe to retry. A payment webhook redelivered, a queue message processed twice, a client that retries on timeout—all of these need a way to recognize "already done." Operation IDs, version numbers, dedupe keys. Not glamorous. Required.

Timeouts. Requests to other services need deadlines. Without them, cascading failures happen silently and gradually consume all your resources. Your code will just sit there, waiting, like a phone call that never connects.

Compensation Logic. When a multi-step operation fails partway through, something has to undo the work already committed. You can't abandon a half-finished saga and hope nobody notices. That's more code than assuming success. People skip it anyway.

Conflict Detection. When two writers touch the same record—two API instances, a retry overlapping with the original request—you need version checks, timestamps, or optimistic locking. Pretending conflicts don't exist works until two updates land in the wrong order.

Observability. Logging, metrics, and traces that let you reconstruct what happened when something fails. At 3 AM, you'll wish this existed. When something breaks and you have no logs, you'll understand why this matters.

You can't delete these and call it simplification. You're just moving complexity from your editor into your on-call rotation.

Less Code vs. Less Noise

Kill redundant abstractions, dead logic, and speculative frameworks. That's good discipline.

Deleting retry wrappers, validation, circuit breakers, or idempotency checks because they "add noise" is a different move.

You're betting stability on dependencies you don't control. When the database hiccups, the partner API times out, or Kubernetes reschedules a pod mid-request, the system doesn't get simpler. It gets wrong.

The Test

If your app runs more than one instance, talks to other services, or processes work asynchronously, these questions will eventually matter:

If a process dies mid-operation, can the system detect it and recover correctly?
If a message is delayed several seconds, what actually happens?
If two workers attempt the same operation at once, is the result deterministic or a coin flip?

If you can't answer all three with specific mechanisms—not vibes, not "we'll fix it in prod"—the codebase isn't simple. It's fragile.

Write the safeguards. Handle the failure modes. The goal isn't more lines for their own sake; it's making hidden complexity visible before production does it for you.

The Mid-Dev Paradox: Why Juniors Are Chill and Mid-Levels Will Reorganize Your Code at 3 AM

Adam - The Developer — Wed, 20 May 2026 09:58:51 +0000

Here's a thing nobody talks about in the "building a healthy engineering culture" TED talks: junior developers are not the problem. They're predictable. They ask questions. They listen. They know what they don't know, which is half the battle.

The mid-level developer? Now there's your chaos agent.

The Tier List (Controversial, I Know)

Juniors: "I don't understand this. Can you explain it?"
Translation: easy, good faith problem. You explain it. They learn. Maybe they code it a weird way, but at least they'll tell you before shipping. These people are trying not to sink the boat.

Mids: "Yeah, I read a Medium article about this architecture pattern once."
Translation: oh no. They now know juuuust enough to be confident, not enough to see all the edges they're missing. They're about to refactor your entire codebase because TypeScript stricter settings are "table stakes for any serious project" (they read an article).

Seniors: "We could do it that way, but let's think about what breaks in six months."
Translation: calm, because we've seen it break in six months before.

Why Juniors Are Actually Great

A junior asked why the onboarding docs were three years out of date. We laughed. Then realized: none of us had updated them because we all just knew how things worked now. New person had to learn from Slack messages and asking people questions. We'd optimized ourselves into a bottleneck.

Here's the thing about juniors: they haven't been beaten down yet. They still think documentation should exist. They still think things should be findable. Revolutionary concepts, I know.

You point them at a task, they get stuck, they ask where the docs are, and you realize there aren't any. Or they're scattered across four different Slack threads from 2021. They don't know yet that this is normal. They think "onboarding" means something other than "asking random people questions until you figure it out."

The risk with a junior is they'll point out all the gaps and make you feel bad about it. The upside is they're collaborative about fixing it. They're not trying to prove anything. They're just trying to do the job and not feel lost the whole time.

The Mid-Dev Energy Crisis

Mids are where things get spicy.

They've shipped something. Maybe it worked, maybe it kind of worked, maybe it caught fire but they're not thinking about that right now. The point is: they have success weight. They're no longer a question mark—they're a contributor with opinions.

But here's where it gets fun. They've read enough to be dangerous, not enough to be wise.

The Mid-Dev's Greatest Hits:

The Architecture Reorganization: "I've been thinking... what if we moved everything to microservices? Distributed systems are the future. I watched a talk." No strategic reason. No pain point being solved. They just watched a talk.
The Framework Rewrite: "Okay but what if we rewrote the whole thing in [new framework]?" Why? "Better DX." Whose DX? Their DX for writing new code while everyone else owns production incidents.
The Premature Abstraction: Four months into the project, they've created a custom hook ecosystem so complex that only they understand it. Junior tries to use it, asks for help, gets a 40-minute explanation of prop-drilling alternatives nobody asked for.
The Aggressive Code Review: They're reviewing a junior's PR. The code works. It's readable. It passes tests. They leave 12 comments asking why the developer "didn't consider using a custom hook" or "didn't memoize aggressively" or "didn't think about server rendering" even though it's a form in an admin panel that hits 30 users a month.

The mid-dev is learning that they can have opinions, and they're exercising that power like they just got access to a 2002 Honda Civic and need to test the engine.

Why This Happens (And It's Not Their Fault)

Here's the uncomfortable truth: mids are in the danger zone of confidence versus competence. They're past the "I don't know anything" phase but not yet in the "I know what I don't know" phase.

The Dunning-Kruger effect is real, but it's not really about stupidity. It's about scale. A junior's worked on one thing. A mid's worked on three to five things. That feels like a lot. It feels like they've seen the patterns.

Until they haven't. Until they learn (the hard way) that "best practice" depends on context. That premature optimization isn't just bad—it's actively hostile to shipping. That code that's boring and works beats code that's clever and breaks at 2 AM.

The thing is, every senior developer alive was a mid once. Most of us pushed something completely unnecessary to production while congratulating ourselves on our architecture skills. Most of us spent a week optimizing something that didn't matter. That's not a failure—that's training.

What Actually Works

If you're a senior managing a mid:

Don't tell them they're wrong—that just makes them defensive. Instead, ask them questions:

"What would break if we do this?" (Often: silence, then they realize something.)
"How long will the refactor take? What's the payoff?" (This makes them do math. Math is humbling.)
"Can we ship the simple version first and refactor if we hit actual problems?" (This teaches patience.)

Give them ownership of something that can break a little bit without destroying the business. Let them experience consequences without trauma. This is how you turn a mid into a senior.

If you're a mid reading this:

Look, you're doing great. You're learning fast, you're getting stronger, you're building real things. The fact that you're in this uncomfortable middle zone means you're growing. That's good.

But here's the move: start asking seniors why instead of telling juniors what. When you're about to suggest a rewrite, ask a senior if they've seen that problem before. When you're reviewing code, ask yourself if you're protecting the system or protecting your ego.

The seniors you respect aren't the ones with the cleverest solutions. They're the ones who know when simple is better. You can get there faster than you think, but only if you stay curious instead of confident.

The Real Insight

Juniors are dangerous in ways we expect—they might not write optimal code, they might miss edge cases. We've built systems to catch that (code review, testing, etc). We expect juniors to be junior.

Mids are dangerous in ways we don't expect. They're good enough that we trust their judgment. They're confident enough that they don't ask for second opinions. And they've read just enough Medium articles to be genuinely convinced they're right.

The thing that separates a mid from a senior isn't skill—it's humility. It's knowing that "I don't know" doesn't mean you're not good at this; it means you're paying attention.

So yeah, keep your juniors close. Let them ask questions. Appreciate that they still think code should be boring and work-y instead of clever and break-y.

And the mids? Keep them curious. Give them hard problems. Have them explain their solutions to someone who wasn't part of the decision. Let them fail small.

The goal is to make juniors into mids and mids into people who remember what it felt like to be certain about everything.

⚔️ Go vs Java: The Minimalist vs The Enterprise Veteran

Adam - The Developer — Mon, 11 May 2026 06:12:47 +0000

No sides. No agenda. Just two languages walking into a bar and us watching what happens.

The Setup
The Contenders
A Quick Origin Story
Language Philosophy: Complexity vs. Simplicity
Performance: JVM vs Native Binary
Concurrency: Goroutines vs Virtual Threads
Ecosystem & Libraries: The Forest vs The Toolshed
Tooling: Go's Discipline vs Java's Buffet
Team Learning Curve: The First Month Matters
- Go: Steep and Short
- Java: Gradual and Endless
- The Team Implication
- In Practice
Where Each One Shines
- Go is great for:
- Java is great for:
The Honest Answer

⚔️ The Setup

I decided to write this because I've been drowning in content where people compare languages like they're picking a religion. "This is better than that, that is better than this," and they're mostly just optimized for outrage.

I've been writing Java for a long time. Fell in love with it early—the way it handles threads, the concurrency model, the entire ecosystem around it just clicked. For a while I genuinely thought Java was the language where threading finally became practical and not a complete nightmare.

Full transparency: I also wanted to write Java because back then, knowing Java meant programmers would praise you at parties. There was definitely ego in it. (Okay, there was a lot of ego in it.) But the reasons I still reach for it now are actually technical and only somewhat ego-driven.

Then Go came along. Started writing it about two years ago and I've been enjoying it. Built two distributed systems at work with it. But it makes you do things manually, the syntax feels weirdly alien the first time you see it, and the ecosystem has this vibe of "I hope this library doesn't get abandoned next month."

No hate on Go. I genuinely love using it.

So here we are—I'm writing this (technically during a very boring class about a week ago) to actually break down what these languages are good at, so you can make a smarter choice than "everyone's using X so we should too."

🥊 The Contenders

Two languages dominate a lot of backend conversations right now. One has been around since the disco era, survived the dot-com bust, and somehow became the backbone of half the world's enterprise software. The other was built by Google engineers who were tired of waiting for C++ to compile, and it became the quiet workhorse behind Docker, Kubernetes, and half of modern infrastructure.

Java and Go. The veteran and the minimalist. The cathedral and the toolshed.

Neither is objectively better. Both are genuinely excellent at different things. This post isn't here to crown a winner. It's here to help you understand what each one is actually good at, so you can make a smarter call the next time someone says "so what stack are we using?"

Let's get into it.

🏁 A Quick Origin Story

Java was born in 1995 at Sun Microsystems, led by James Gosling, with one promise: Write Once, Run Anywhere. The JVM meant your compiled bytecode could run on any machine. This was revolutionary at the time. Java rode that wave into enterprise dominance and never really left.

Go (or Golang) was created at Google in 2009 by Rob Pike, Ken Thompson, and Robert Griesemer. These three people have more programming language credentials than most of us will ever accumulate. Their frustration? C++ build times were destroying their productivity. Their solution? A language that was fast to compile, fast to run, and simple enough that you couldn't shoot yourself in the foot too badly.

Different eras. Different problems. Different philosophies.

🧠 Language Philosophy: Complexity vs. Simplicity

This is where the two languages diverge most dramatically. Not in syntax, but in worldview.

Java believes in giving you tools. Lots of tools. Generics, inheritance, abstract classes, interfaces, annotations, lambdas, streams, optional, records, sealed classes. Java has a solution for every pattern, and then a pattern for every solution. It trusts you to assemble them wisely.

Go believes in taking tools away. Go has no classes (just structs). No inheritance. No generics until recently (Go 1.18, 2022). No exceptions, just error values returned explicitly. The Go team's philosophy is almost aggressively minimalist. If a feature could be abused, they'd rather not include it.

// Go error handling: explicit, everywhere, always
file, err := os.Open("data.txt")
if err != nil {
    return fmt.Errorf("failed to open file: %w", err)
}
defer file.Close()

// Java: exceptions handle the unhappy path separately
try {
    var file = new FileReader("data.txt");
    // do stuff
} catch (IOException e) {
    throw new RuntimeException("failed to open file", e);
}

Neither approach is wrong. Java's exception model keeps the happy path clean. Go's explicit errors mean you cannot forget to handle failure. The compiler won't let you ignore an error value without being deliberate about it.

Go's philosophy produces code that a new team member can read on day one. Java's philosophy produces code that can model genuinely complex domains with precision.

Dig deeper if: You care about this. Go's design FAQ and Java's language evolution tell very different stories about how languages grow.

⚡ Performance: JVM vs Native Binary

Go compiles to a native binary. You run go build, you get a self-contained executable that starts in milliseconds. It's like handing someone a knife—they just use it.

Java runs on the JVM, which is more like handing someone a full kitchen. There's setup time (the JVM initializes), there's a warm-up period where the JIT compiler figures out what code you're running a lot (and starts optimizing it), but once it knows what's happening, it can produce machine code that's genuinely competitive or sometimes better than Go for sustained workloads.

Scenario	Go	Java
Cold start	🟢 Milliseconds	🟡 Seconds (improving with GraalVM)
Peak throughput (warmed up)	🟡 Very fast	🟢 Can match or beat Go
Memory footprint	🟢 Small	🟡 Larger baseline
Serverless / short-lived processes	🟢 Natural fit	🟡 JVM overhead hurts
Long-running services	🟡 Great	🟢 JIT optimization pays off

The tradeoff: Go's predictable, instant startup is perfect for environments where things are constantly spinning up and down. Java's startup cost disappears if the process lives for weeks—the JIT warmup happens once, and then you get increasingly optimized code.

GraalVM native images exist if you want Java's ecosystem with Go's startup speed, but you're adding complexity to your build. It's a bridge, not a solution.

Dig deeper if: TechEmpower benchmarks if you like staring at numbers.

🔀 Concurrency: Goroutines vs Virtual Threads

Go's concurrency story used to be the unreachable dream for everyone else. Goroutines are lightweight, greenthread-style concurrency that the Go runtime manages for you. You can spawn tens of thousands without breaking a sweat:

// Launch 10,000 concurrent tasks. No ceremony.
for i := 0; i < 10_000; i++ {
    go func(id int) {
        doSomethingBlocking(id)
    }(i)
}

Channels are your communication layer—they're the part that makes goroutines actually elegant instead of just fast:

ch := make(chan string)

go func() {
    ch <- "hello from another goroutine"
}()

msg := <-ch

This mental model (goroutines + channels) became foundational to Go. It made high-concurrency systems feel operationally approachable. That's why Docker, Kubernetes, Prometheus—all the infrastructure that had to handle millions of goroutines—are written in Go.

Java had a problem here. For years, the answer to "how do I handle thousands of concurrent requests?" was "spawn a thread per request" or "use a thread pool and hope." It worked, but it didn't feel right. You could feel the language fighting you.

Then Java 21 brought Virtual Threads. Same idea as goroutines—lightweight, JVM-managed concurrency. But here's the thing: they look exactly like regular Java threads. No new syntax, no new mental model:

// Java 21: 100,000 virtual threads. Same old executor API.
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 100_000).forEach(i ->
        executor.submit(() -> doSomethingBlocking())
    );
}

The real difference: Go requires you to think in a new way. Goroutines and channels are a genuinely elegant paradigm, but they're different from how most languages do concurrency. Java's virtual threads let you keep thinking the old way—submit work, forget about it, let the runtime handle the threads.

Go's approach produces more elegant concurrency code when you're building from scratch. Java's approach is pragmatic when you have existing blocking code or when you don't want to learn a new concurrency philosophy just to handle concurrent requests.

Both solve the same problem. Go solved it first and more elegantly. Java solved it later and more "you don't have to change anything."

Dig deeper if: The Go Blog on goroutines or JEP 444: Virtual Threads.

🌲 Ecosystem & Libraries: The Forest vs The Toolshed

Java's ecosystem is vast. I'm talking millions of artifacts in Maven Central. Whatever you need exists somewhere. Database drivers, HTTP clients, payment processors, ML frameworks—multiple mature options, probably more than you want to choose from. The Spring ecosystem alone is essentially its own platform. Spring Boot, Spring Data, Spring Cloud, Spring Security. Teams build entire careers knowing just that one thing deeply.

The tradeoff: Abundance creates paralysis. You're choosing between 47 JSON libraries and second-guessing yourself. A "simple" Spring Boot project pulls in hundreds of transitive dependencies. You're managing a forest, and sometimes you can't see the trees.

Go's ecosystem is younger and more curated. The standard library is actually good—HTTP servers, JSON encoding, crypto, testing are all production-quality and baked in. The community has filled in the gaps with solid packages: gin, echo, gorm, cobra. But sometimes you hit the edge. A niche domain where nothing exists, and now you're writing it yourself.

The tradeoff: You make fewer decisions, have fewer dependencies to worry about, and your binaries are smaller. But occasionally you're building something the ecosystem hasn't solved yet.

Here's where it matters: For small, bounded services (webhooks, rate limiters, health checkers, internal tools), Go's minimal approach keeps things clean and understandable. You grab the standard library, maybe add one focused package, and you're done. For complex enterprise systems (multi-tenant SaaS with user roles, audit trails, compliance logging, payment integration), Java's ecosystem saves you months of building. Spring Data handles the database complexity that would be a pain to build. Spring Security handles authentication scenarios that would take forever to get right.

// Go: 8 lines, no dependencies
http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
    w.WriteHeader(http.StatusOK)
    fmt.Fprintln(w, `{"status": "ok"}`)
})
http.ListenAndServe(":8080", nil)

// Spring: more setup, but it's assuming you'll build an actual system on top
@RestController
public class HealthController {
    @GetMapping("/health")
    public Map<String, String> health() {
        return Map.of("status", "ok");
    }
}

The Go version is simpler when you actually need simplicity. The Spring version pays dividends when complexity is inevitable.

Dig deeper if: pkg.go.dev or mvnrepository.com (warning: you will feel overwhelmed).

🛠️ Tooling: Go's Discipline vs Java's Buffet

Go ships with an opinionated standard toolchain:

go fmt: formats your code. Non-negotiable. Everyone's Go code looks the same.
go test: testing built in, no framework needed
go vet: catches common mistakes
go mod: dependency management, built in since Go 1.11
go build: one command, one binary

There are no arguments about Go tooling. It's just there, it works, and the whole Go community uses the same tools.

Java's tooling is more of a choose-your-own-adventure:

Build tools: Maven or Gradle (religious war ongoing since 2012)
Testing: JUnit + Mockito + AssertJ + maybe Testcontainers + maybe Spock
Formatting: Checkstyle? Google Java Format? Your lead's personal preferences from 2015?
Dependency management: Maven Central or JitPack or that internal Nexus your company runs that nobody fully understands

The Java tooling ecosystem is powerful, flexible, and the source of at least 30% of new developer onboarding time.

The tradeoff: Go's rigid tooling means less time arguing about style and setup, but also less flexibility if you have unusual needs. Java's flexible tooling means you can optimize for your exact situation, but you have to make more decisions upfront.

Dig deeper if:

Go tooling: go help in your terminal is genuinely great.
Java: the Maven docs or Gradle docs depending on which side of history you're on.

👥 Team Learning Curve: The First Month Matters

This is where language choice gets practical in ways that benchmarks completely miss.

Go: Steep and Short

Week one with Go is rough. The syntax looks wrong to you: defer, goroutines, channels, interfaces without explicit implementation. You'll write code that compiles but doesn't feel right. You'll stare at a pointer receiver and wonder why it exists.

But then something shifts. By week three, you're productive. There's just not enough to learn. Go is intentionally simple—it has fewer corners, fewer patterns, fewer ways to paint yourself into a corner. You get to the end of the learning curve faster because there is an end.

After a month, you can pick up any Go codebase and understand it. The style is consistent because gofmt is non-negotiable. There's usually one way to do things, so debates are settled by the language itself.

Java: Gradual and Endless

A new Java developer is productive fast. Spring Boot handles so much boilerplate. IntelliJ is powerful enough that you can write working code without really knowing what you're doing. By week one, you've shipped something.

But productive ≠ competent. The learning curve doesn't end, it just gets less steep.

Generics and wildcards: "What's a ? super T?"
Inheritance hierarchies: "Why does this class extend AbstractSomething which implements Interface-Whatever?"
Dependency injection: "How did this bean get instantiated?"
Streams vs for loops: "Which should I use?"
Checked vs unchecked exceptions: "Should I throw this or declare it?"
Annotations: "Is this magic or is it explicit?"

After a month, you ship features. But they're not idiomatic. You copy patterns without understanding them. You build things the complex way because Java can do complexity, so you assume it should.

After 6 months, you start thinking in Java. After a year, you're actually dangerous.

The Team Implication

Go teams scale horizontally. Hire three junior developers, and by week four they're all contributing meaningfully. Code reviews are fast because there's less to argue about. The language enforces consistency. New people can't accidentally introduce wildly different patterns because the language doesn't allow them.

Java teams scale with depth. Hire three senior engineers who know Spring inside-out, and they can architect complex systems. But hire three mid-level developers, and you'll spend months establishing patterns. The payoff is that once you have that shared understanding, you can build systems that would be awkward in Go.

In Practice

Go: New developer → valuable by day 3 → production-ready code by day 20
Java: New developer → visible output by day 5 → stops making seniors cringe by day 90

If your team is mostly junior and turns over frequently, Go reduces friction. People ramp up before they leave. If your team is senior and stable, Java's richness becomes an asset. You can mentor through the complexity, and the codebase can express sophisticated requirements.

Neither is better. They're different onboarding curves with different endpoints.

🏢 Where Each One Shines

Go is great for:

Cloud-native infrastructure: Docker, Kubernetes, Terraform, Prometheus—all Go. They needed to handle the concurrency problem (goroutines managing millions of containers), and Go's lightweight concurrency made high-scale infrastructure feel operationally approachable. Few mainstream languages made this density practical at the time.
Microservices and APIs: Small binary, fast startup, low memory. When you're deploying dozens of services to containers that spin up and down constantly, Go's millisecond startup matters operationally. The JVM's seconds are a constant background friction in that scenario.
CLI tools: Single binary, no runtime, just works. Ship a Go executable to users and they run it. That's it.
Network-heavy services: Goroutines handle tens of thousands of concurrent connections efficiently. If you're building something that lives at the edge (proxy, load balancer, API gateway), this becomes an operational advantage.
Teams with high turnover or a strong consistency preference: The language enforces one way of doing things. New people ramp fast. Debates about style disappear because gofmt is non-negotiable.

Java is great for:

Complex enterprise domains: The type system (generics, sealed classes, records) lets you model intricate business logic precisely. When requirements change three years later, the compiler helps you find everything that needs updating. Java makes you be explicit about contracts, and that pays off over time.
High-throughput, long-running services: Once the JVM warms up—which happens once, then stays warm for weeks—the JIT produces increasingly optimized code. In services running continuously and handling millions of requests, this optimization compounds. You get better performance the longer it runs, the opposite of microservices.
Large, stable teams: Onboarding takes longer, but once your team knows the patterns, Java's explicitness becomes a feature. You can architect complex systems and have everyone understand them.
Data-heavy applications: Hibernate, Spring Data, the JPA ecosystem—they've solved a lot of hard database problems. Complex queries, transactions, migrations, relationship management. Go's database story works, but Java's is more mature and battle-tested.
Existing Java investment: You have code that works, people who know it, and switching costs are real. Modern Java (21+) is genuinely better to work with than it used to be. Virtual threads solved a real weakness. Stay and improve rather than rewrite.
Systems that need long-term evolution: Java's type system helps you reason about changes years later. The language pushes you toward being explicit about constraints and contracts. That discipline pays off when requirements get complex.

🤷 The Honest Answer

Pick Go if you're building infrastructure tooling, CLIs, or containerized microservices where startup time and memory footprint actually matter operationally. Pick it if you want to move fast without debating style guides. Pick it if your team is junior and you don't have time to babysit learning curves.

Pick Java if you're building something genuinely complex and you need a type system that grows with your requirements. Pick it if you already have Java in your organization and switching would be a nightmare. Pick it if your team is senior and stable—the language rewards expertise and knowledge accumulation.

The honest truth is that the language is rarely the bottleneck. Architecture, database design, team communication, deployment infrastructure—those matter more. But choosing the right tool for your constraints does save you from fighting friction that shouldn't exist.

Both are genuinely good at what they're designed for. You're not picking between "good" and "bad." You're picking between "good for this" and "good for that."

Write Code That's Easy to Delete: The Art of Impermanent Software

Adam - The Developer — Sat, 02 May 2026 08:22:42 +0000

We obsess over making code last. Maybe we should obsess over making it leave gracefully.

There's a quote that's been living rent-free in my head for years:

"Write code that is easy to delete, not easy to extend."
— Tef, programming is terrible

The first time I read it, I pushed back. Isn't the whole point to write code that survives? That scales? That you can build on top of?

Then I spent a weekend trying to rip out a logging library from a three-year-old codebase. It had quietly spread into 40 files. Removing it felt like surgery on a patient who had grown bones around a sponge.

The Lie We Tell Ourselves

When we write code, we tell ourselves a flattering story: this will be here in five years, so I should make it robust, reusable, and extensible.

But the data doesn't support this story. Most features get changed within months. Many get cut entirely. The average production codebase has entire directories that haven't been touched in years — not because they're perfect, but because everyone is too afraid to delete them.

We write code as if it's load-bearing. Usually, it isn't.

The irony is that the more we try to make code "permanent" — wrapping it in abstractions, coupling it into shared utilities, weaving it through the system, the harder it becomes to change. We've traded adaptability for the illusion of durability.

What "Easy to Delete" Actually Means

It doesn't mean write throwaway code. It doesn't mean skip tests or ignore structure.

It means: design for reversibility.

When you write a feature, ask yourself: if this needed to go away tomorrow, what would that look like?

If the answer is "a 400-line PR touching 20 files," something went wrong at the design stage — not the deletion stage.

Easy-to-delete code tends to share a few traits:

1. It lives in one place

Duplication gets a bad reputation. The DRY principle is good advice, but taken to its extreme, it creates code that's deeply entangled. When the same function is reused in eight different contexts, you can't change it for one context without worrying about all the others.

Sometimes, a little duplication is the price of independence. Two modules that both have a formatDate function can each evolve or disappear without consequences.

2. It has a clear boundary

The hardest code to delete is the code that has leaked everywhere. The database client that got imported into UI components. The config object that got passed twelve layers deep. The utility function that became load-bearing infrastructure.

Boundaries are what make deletion safe. An isolated module, a clean interface, a service behind a well-defined API... these are things you can remove, replace, or rewrite without holding or thinking through your breath.

3. It doesn't know too much

Code that's easy to delete tends to be ignorant but in the best way. It doesn't know about the rest of the system. It takes inputs, does its job, returns outputs. It doesn't reach out and grab global state. It doesn't mutate things it didn't create.

Ignorant code is also testable code, which is no coincidence ( I actually didn't wanna add this part for some personal reasons )

4. It's hidden behind a seam

Feature flags. Adapter layers. Interface abstractions. These aren't just engineering formalism — they're deletion handles. A feature behind a flag can be switched off in seconds. Code behind an interface can be swapped without the callers noticing.

The strangler fig pattern exists precisely for this reason: wrap the old thing, build the new thing alongside it, then delete the old thing once it's isolated. The seam is what makes that possible.

A Different Way to Think About Abstraction

We often reach for abstraction to avoid repetition. But the best reason to abstract something is to isolate it or to give it a name and a box so that you can change or remove it without touching everything else.

Think about logging. You could scatter console.log calls everywhere. That's easy to write and immediately painful to change. Or you could route all logging through a single logger module. Now if you want to swap logging libraries, or add context, or silence it entirely — you only touch one file. ONE.

The abstraction isn't there because logging is complex. It's there because logging is a thing that might change or disappear, and you want that to be painless.

Abstract at the seams, not in the middle.

Deletability as a Code Review Lens

Here's something I've started doing in code review: asking not just "does this work?" but "what would it take to remove this?"

It reframes things in a useful way.

A PR that adds a new feature and touches 15 files is a warning sign — not necessarily because it's wrong, but because it's announcing a high cost of future change. A PR that adds the same feature through a single, well-bounded module is leaving a cleaner footprint.

You can extend this to architecture decisions. Before adding a new dependency, ask: "what does removing this look like in two years?" Some dependencies are fine because they're small, stable, or isolated. Others are like introducing an invasive species. They grow into everything and become impossible to root out.

Impermanence Is Not Defeatism

There's a Zen concept sometimes translated as impermanence — the idea that things arise, exist for a time, and pass away. This isn't pessimism. It's just an accurate description of how things work.

Software is the same. Features come and go. Products pivot. Requirements change. The code you're writing today will be partially or wholly replaced. That's not failure — that's how living software works.

Writing for impermanence means accepting this, and designing accordingly. It means your goal isn't to write code that can never be removed. It's to write code whose removal is cheap.

The engineers who built systems that are still running 30 years later didn't achieve that by making the code impossible to touch. They achieved it by writing code that was easy to reason about, easy to isolate, and when the time came, it's easy to replace piece by piece.

In Practice: A Checklist

Before you commit something, it's worth a quick gut-check:

Could I delete this feature with a single PR? If not, why not?
How many files does this touch? More isn't always worse, but it should feel intentional.
Is this module aware of things it shouldn't be? Imports, globals, side effects.
If this dependency disappeared tomorrow, how bad would it be? Could you swap it in an afternoon?
Is this abstraction making things easier to change, or just avoiding repetition?

None of this means paralysis. You don't need to design every microservice like it might vanish. But developing an instinct for deletion cost with the same way you develop an instinct for performance or readability, it'll quietly make your codebases healthier.

The Code You Don't Have to Write

There's a final point worth making: the easiest code to delete is the code you never write.

Every feature is a liability. Every abstraction is a maintenance surface. Every dependency is a relationship you're now in. The code that doesn't exist has no bugs, no coupling, no deletion cost.

This doesn't mean build nothing. It means be deliberate. When you feel the urge to add a new layer of abstraction, to generalize something that's only been used once, to build for a use case that might never arrive... pause.

Maybe the right move is to wait. To write the minimal thing. To leave room for deletion.

Because software that can change easily is software that can survive. And the secret to changeability isn't clever architecture or brilliant abstractions.

It's knowing that what you built today can be gracefully taken apart tomorrow.

" SaaS in 2026 Is the Plumbing, Not the Hype "

Adam - The Developer — Thu, 30 Apr 2026 03:20:11 +0000

SaaS as reliable plumbing for fragile agents

arunkant

Apr 29

Why I'm Building SaaS in 2026

#saas #ai #agents #workflows

4 min read

Why High-Performing Teams Look Like They Do Nothing

Adam - The Developer — Mon, 27 Apr 2026 06:46:12 +0000

There is a belief quietly embedded in some engineering cultures that suffering equals seriousness. That if your team is not always reachable, not always slightly panicked, not always racing something, then they must not be working hard enough.

This belief is wrong. And it is worth naming clearly, because it does real damage.

The Confusion

Challenge and stress are not the same thing.

Challenge is being handed a problem you have never solved before and being trusted to figure it out. It is learning something hard. It is designing a system under real constraints. It is disagreeing with a technical decision and having to defend your position with evidence. Challenge stretches you. When it is over, you feel like you grew.

Chronic stress is your phone buzzing at 10pm. It is a deadline moved up without explanation. It is the ambient anxiety of knowing you must always appear available, always appear busy, always appear to be giving more. When it is over, you feel hollowed out. And then it starts again.

Some managers treat the second thing as if it were the first. They see responsiveness and call it ownership. They see exhaustion and call it passion. They create urgency as a management style, not because the work demands it, but because urgency feels like leadership.

Why This Happens

It is not always malicious. A lot of it comes from a simple measurement problem.

Stress is visible. You can see who responds fastest. You can see who is online at midnight. You can see who never pushes back on a deadline. These signals are easy to read, easy to reward, and easy to confuse with performance.

Genuine challenge is harder to observe. Deep thinking is invisible. The best engineering decisions often look like nothing happened, because a problem was caught early. The developer who said "we should not build this yet" and saved the team three months of rework does not have a story that makes it into the all-hands.

So the proxy gets promoted: availability, urgency, perpetual motion.

What It Costs

People in chronically stressed environments often look highly productive for a while. They respond fast. They ship things. They are visibly busy.

But the quality of their thinking degrades. Their decisions get narrower. They stop exploring better options and start choosing the fastest acceptable one. Their appetite for hard problems shrinks, because they do not have the cognitive space to sit with difficulty. They start optimizing for speed over correctness, for appearing capable over actually being capable.

And eventually, the best ones leave. Not always loudly. Sometimes they just get quieter, do what is asked, and start looking elsewhere. The people who stay longest in high-stress, low-challenge environments are often those with fewer options, not those with the most to contribute.

What Real Challenge Looks Like

This is not an argument against hard work, tight timelines, or high standards. Those things are real, and good engineers often want them.

Real challenge tends to have a few properties:

It requires thinking, not just doing. The constraint is intellectual, not just temporal.
There is genuine ownership. The person doing the work has some say in how it gets done.
The pressure is contextual, not permanent. There are hard sprints and then there is recovery. The urgency is tied to real circumstances, not manufactured as a default state.
Failure is information, not catastrophe. People can take risks without dreading consequences.

Paranoia is not a feature. Misery is not a signal of commitment. A team that is always stressed is not a team that is being challenged. It is a team that is being depleted.

Silence Can Be the Sound of Quality

I experienced this firsthand when I was leading a team.

We were, by most measures, the quietest team around. Low communication overhead. Calm standups. Not a lot of noise in the incident channels. And the reason was simple: we had very few bugs, and when something did get fixed, it stayed fixed. We were not constantly putting out fires because we were not constantly starting them.

But I heard through the grapevine that other teams thought we were not doing much. Because we were not loud. Because we were not visibly scrambling.

Meanwhile, the teams that were most vocal, most communicative, most frantically active were dealing with recurring issues, patches on top of patches, the same problems resurfacing in slightly different shapes. That busyness was real. The work was real. But a significant portion of it was self-generated, the cost of not getting things right the first time.

The irony is sharp: doing quality work made us invisible. And being invisible got mistaken for being idle.

This is what happens when communication volume becomes a proxy for productivity. The team fighting fires all day is easy to see. The team that quietly prevented the fires does not have a highlight reel.

A Note to Managers

If your team seems disengaged, it is worth asking whether you have been offering them challenge or just stress. The two feel similar from the outside, especially if you are the one setting the pace.

Challenge requires trust. It means giving someone a genuinely hard problem, stepping back, and letting them work through it. That is harder to do than creating urgency. It requires believing that thinking is work, that slowness can be wisdom, and that the goal is excellent output over a career, not maximum output over a quarter.

The teams that do the most interesting, lasting work are rarely the ones running on panic. They are the ones who are genuinely absorbed in hard problems, who have space to think, and who know the difference between a real fire and a manufactured one.

That distinction is worth protecting.

The Developer Who Reviews Everything and Ships Nothing

Adam - The Developer — Sat, 18 Apr 2026 06:28:10 +0000

You've seen this person. Maybe you've worked with them for years.

They leave 40 comments on your PR. Variable names, spacing philosophy, whether your abstraction is "truly necessary," a link to a 2014 blog post about hexagonal architecture. The review sits open for a week. Then two.

Meanwhile, their own tickets age quietly in the backlog. Untouched.

Before We Go There

Most strict reviewers are not villains.

A lot of them have been burned. They've watched a rushed merge take down production at 2am. They've inherited a codebase where "we'll clean it up later" compounded for three years into something unmaintainable. Strictness in review often comes from real scar tissue. That's not dysfunction. That's experience talking.

This article isn't about those people.

It's about a specific, observable pattern: the developer whose review activity is consistently high, whose shipping activity is consistently low, and whose involvement reliably increases cycle time without a corresponding increase in outcome quality. That pattern has a real cost and it rarely gets named out loud.

So let's name it.

The Pattern

It doesn't require mind-reading. It shows up in the data.

PRs they author are rare. When they do appear, they're small, low-risk, or six weeks overdue. PRs they touch accumulate long threads, mostly non-blocking comments that aren't labeled as such, leaving authors to guess what actually needs to change. Review cycles on their queue run longer than the team average. Features that slip usually have their fingerprints somewhere in the timeline.

That's the shape of it. Measurable. Repeatable. Worth paying attention to.

Where They Put Their Time

Senior engineers have limited hours. Where those hours go is a signal.

A senior spending eight hours a week in code review and two hours writing code has made a choice. Sometimes that's the right call — architecture, incident response, debugging gnarly production issues, mentorship. Real contributions that don't show up in merge counts.

But when the same person's review comments outnumber their merged commits by a factor of ten, quarter after quarter, you're looking at someone who has concentrated their influence in the one place where they can evaluate others without being evaluated themselves.

That asymmetry is the tell.

What It Actually Costs

When review cycles drag on for days, the effects compound quietly.

The author loses context. They've moved on mentally to the next problem. When they return to address 30 comments, they're doing archaeology on their own work.

Junior developers learn that shipping is scary. That there's always something wrong. That the bar is impossibly high, so maybe it's better to ask fewer questions and wait for someone to tell you what to do.

Momentum dies. Not in one dramatic moment, but comment by comment, week by week.

And the developer with the high standards? Present at every standup. Very visible. Very engaged. Zero shipped features to show for the sprint.

Nitpicking Is Not Mentorship

There's a version of this that gets laundered through mentorship language.

"I'm just trying to teach them." "How else will they learn?" "I wouldn't be doing my job if I let this slide."

Genuine mentorship explains tradeoffs. It asks questions instead of demanding changes. It approves code that's good enough while offering perspective on what could be better next time.

What it doesn't do is make someone feel like their work is never good enough, while that same reviewer's own code somehow never faces the same gauntlet.

If your "mentorship" only flows one direction and none of your mentees can ship without your sign-off on 40 line items, that's not mentorship. That's a bottleneck with good branding.

The Accountability Gap

Here's a diagnostic worth running.

Track for one month which developers on your team ship production code. Not who reviews, not who comments — who actually merges working features to production. Then look at who has the most comments open across other people's PRs.

A large gap between those two lists is worth investigating. Not a verdict. Seniors do invisible work that won't show up in a merge count, and that work genuinely matters.

But here's the cut: if someone's review involvement is consistently high, their direct output is consistently low, and the team's cycle time is getting worse, "I do invisible work" becomes a harder argument to sustain. Shipping isn't the only form of contribution. But consistent absence from shipping alongside heavy review influence is a smell, and pretending otherwise doesn't make it go away.

Fixes With Actual Teeth

The standard advice is: add review SLAs, separate blocking from non-blocking comments, track cycle time. All correct. All worth doing. All also pretty easy to quietly ignore.

If the pattern is entrenched, you need something sharper.

Cap non-blocking comments. If a reviewer leaves more than five non-blocking comments, they roll them into a summary or they stay quiet. Unlimited low-stakes commentary costs the reviewer nothing and costs the author a morning. Change the economics.

Require a patch for strong objections. If a reviewer argues an approach is wrong, they should be able to show an alternative. Not to embarrass anyone — because it forces the objection to get concrete. A lot of "this architecture is problematic" comments evaporate the moment someone has to write the better version.

Make the ratio visible. Track review comments opened vs. PRs merged per person, alongside cycle time per reviewer. Don't make it a performance metric. Just make it visible. Sunlight is usually enough.

Know who actually has veto power. Not every PR needs every senior. Be explicit about who is a required approver versus who is optional feedback. When everyone with an opinion is a required approver, you've handed veto power to whoever is most willing to hold out longest.

Raising the Bar vs. Holding the Door Shut

You can tell the difference by asking one question: does this person's involvement make the team ship more, or less?

If every PR they touch becomes a negotiation, if every week they're reviewing has longer cycle times than the weeks they're out, if junior developers dread their feedback instead of seeking it — that's your answer.

Raising the bar means the team gets better over time. Patterns become consistent. People grow and ship with more confidence.

Holding the door shut means nothing gets through without a fight, nobody proposes anything ambitious, and your most capable people quietly start updating their resumes.

The Mirror

When did you last ship something? When did you last put your own code up for the same level of scrutiny you apply to others?

If your presence in the review process reliably slows shipping more than it improves outcomes, you are not raising standards. You are taxing the team.

The engineers who actually elevate a codebase over time make things better and faster simultaneously. That's the bar. It's harder than leaving comments.

Your Caching Strategy Is Not a Strategy

Adam - The Developer — Mon, 06 Apr 2026 04:46:45 +0000

You have a slow endpoint. Someone suggests Redis. You add Redis. The endpoint gets faster. You ship it. Six months later you are debugging a production incident where users see stale data, your cache hit rate is 12%, and you have no idea what is actually in Redis anymore.

That is not a caching strategy. That is a prayer with an expiry time.

This post is not here to roast you. It is here to give you the patterns, the code, and the mental model to do this right.

Caching Is a Contract
The Three Classic Patterns (And When to Use Each)
Build a Cache Client Worth Using
Cache Key Design: More Important Than It Looks
Cache Invalidation: The Part Everyone Skips
- TTL vs. Event Driven Invalidation
The Thundering Herd and How to Solve It
- Solution 1: Jitter
- Solution 2: Stale While Revalidate
- Solution 3: Distributed Lock on Cache Miss
Observability: Know What Is Actually Happening
The Decision Checklist Before You Add a Cache
Putting It All Together

Caching Is a Contract

Before you touch Redis, understand what you are agreeing to.

Caching is a contract. You are telling your system: "I accept that this data may be slightly wrong for a period of time, in exchange for speed." Most teams sign that contract without reading it.

Before you add any cache entry, answer these four questions:

What is the acceptable staleness window for this data?
Who invalidates this entry and when?
What happens when the cache is cold?
What happens when the cache is wrong?

If you cannot answer all four, you do not have a caching strategy. You have optimism.

The rest of this post is about answering each of those questions with real code.

The Three Classic Patterns (And When to Use Each)

There are three fundamental ways to integrate a cache with your database. Most teams only know one and use it everywhere.

Pattern	How It Works	When to Use It
Cache Aside	App checks cache, misses go to DB, app writes to cache	Default. Works well for most read heavy workloads.
Write Through	Every write goes to DB and cache together, atomically	Read heavy data that changes infrequently. Keeps cache always warm.
Write Behind	Write to cache immediately, flush to DB asynchronously	Very high write throughput: analytics, metrics, event ingestion, rate limiting counters.

Most engineers default to cache aside everywhere, which is fine until it is not. Write behind in particular is underused. When you are recording analytics events or incrementing rate limit counters, you do not need each write to round trip to a database. Write to Redis, flush to Postgres in batches. Your database handles a fraction of the load.

The important thing is that you choose consciously. Each pattern has tradeoffs. Write behind carries real risk of data loss if Redis fails before the flush. That is acceptable for a view counter and unacceptable for a financial transaction. Know which one you are dealing with.

Build a Cache Client Worth Using

Before diving into patterns, establish a typed, reusable cache client. This becomes the foundation for everything below.

import { createClient, RedisClientType } from "redis";

export interface CacheOptions {
  ttl: number;      // base TTL in seconds
  jitter?: number;  // max random seconds to add (prevents stampedes)
  stale?: number;   // extra seconds to serve stale while revalidating
}

export interface CacheEntry<T> {
  value: T;
  cachedAt: number;
  expiresAt: number;
}

export class CacheClient {
  private client: RedisClientType;

  constructor(redisUrl: string) {
    this.client = createClient({ url: redisUrl }) as RedisClientType;
  }

  async connect(): Promise<void> {
    await this.client.connect();
  }

  protected getUnderlyingClient(): RedisClientType {
    return this.client;
  }

  private effectiveTTL(options: CacheOptions): number {
    const jitter = options.jitter
      ? Math.floor(Math.random() * options.jitter)
      : 0;
    return options.ttl + jitter;
  }

  async get<T>(key: string): Promise<CacheEntry<T> | null> {
    const raw = await this.client.get(key);
    if (!raw) return null;
    return JSON.parse(raw) as CacheEntry<T>;
  }

  async set<T>(key: string, value: T, options: CacheOptions): Promise<void> {
    const ttl = this.effectiveTTL(options);
    const staleTTL = ttl + (options.stale ?? 0);

    const entry: CacheEntry<T> = {
      value,
      cachedAt: Date.now(),
      expiresAt: Date.now() + ttl * 1000,
    };

    await this.client.setEx(key, staleTTL, JSON.stringify(entry));
  }

  async del(key: string): Promise<void> {
    await this.client.del(key);
  }

  async delByPattern(pattern: string): Promise<void> {
    const keys = await this.client.keys(pattern);
    if (keys.length > 0) {
      await this.client.del(keys);
    }
  }
}

The CacheEntry wrapper stores cachedAt and expiresAt alongside the value. This unlocks stale while revalidate later without a second Redis call.

Cache Key Design: More Important Than It Looks

This is one of the most overlooked parts of a caching system. Your key schema is an architectural decision, not a naming convention.

A good cache key answers five questions, in order:

app : v2 : user : 123 : profile
 ^     ^     ^     ^      ^
 |     |     |     |      shape or query variant
 |     |     |     entity ID
 |     |     entity type
 |     cache version
 app namespace

More examples:

app:v2:user:123:permissions
app:v2:feed:user:123:page:2:limit:20
app:v2:product:456:inventory:warehouse:uk

Bad keys look like this:

user:123
profile_123_v2
user_data_new_123
temp_user_123

No namespace means you cannot isolate patterns for deletion. No version means changing the shape of a cached object requires flushing all of Redis. No structure means you cannot delete "everything for user 123" with a single pattern.

The key schema also tells you something about your architecture. If your keys look inconsistent, your caching layer grew organically without a plan. Standardize the schema early and enforce it through a key builder:

const CACHE_VERSION = process.env.CACHE_VERSION ?? "v1";

export const keys = {
  userProfile:     (userId: string) =>
    `app:${CACHE_VERSION}:user:${userId}:profile`,
  userPermissions: (userId: string) =>
    `app:${CACHE_VERSION}:user:${userId}:permissions`,
  userFeed:        (userId: string, page: number, limit: number) =>
    `app:${CACHE_VERSION}:feed:user:${userId}:page:${page}:limit:${limit}`,
  userAll:         (userId: string) =>
    `app:${CACHE_VERSION}:user:${userId}:*`,
};

Now when you need to invalidate all data for a user, it is one call: delByPattern(keys.userAll(userId)).

To handle a breaking shape change, bump CACHE_VERSION in your deploy config. Old keys expire naturally. New requests populate the new shape. No coordinated flush against production Redis.

Cache Invalidation: The Part Everyone Skips

Most cache bugs are not "we cached the wrong thing." They are "we forgot to uncache it when the underlying data changed."

Here is the pattern that causes incidents:

// The read path is carefully thought through
async function getUserProfile(userId: string) {
  const key = keys.userProfile(userId);
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const profile = await db.findUser(userId);
  await redis.setEx(key, 3600, JSON.stringify(profile));
  return profile;
}

// The write path does not think about the cache at all
async function updateUserProfile(userId: string, data: Partial<User>) {
  await db.updateUser(userId, data);
  // cache is now wrong. silently. for the next hour.
}

The fix is to own both paths in the same service:

export class UserService {
  constructor(
    private db: Database,
    private cache: CacheClient
  ) {}

  async getProfile(userId: string): Promise<UserProfile> {
    const key = keys.userProfile(userId);
    const entry = await this.cache.get<UserProfile>(key);
    if (entry) return entry.value;

    const profile = await this.db.findUser(userId);
    await this.cache.set(key, profile, { ttl: 3600, jitter: 300 });
    return profile;
  }

  async updateProfile(userId: string, data: Partial<UserProfile>): Promise<UserProfile> {
    const updated = await this.db.updateUser(userId, data);

    // Write through: update cache immediately with fresh data
    await this.cache.set(keys.userProfile(userId), updated, {
      ttl: 3600,
      jitter: 300,
    });

    return updated;
  }

  async suspendAccount(userId: string): Promise<void> {
    await this.db.suspendUser(userId);

    // Permissions must be immediately consistent.
    // Never serve stale permission data. Delete, do not wait for TTL.
    await this.cache.del(keys.userPermissions(userId));
  }
}

Notice suspendAccount does not use write through. It deletes the permissions key outright. Serving a stale permission is a security issue, not a UX issue. The next read will hit the database and get the correct answer.

TTL vs. Event Driven Invalidation

These are two different tools for two different problems.

TTL invalidation is for data where being slightly stale is acceptable. Exchange rates, public blog posts, product catalog pages. Set a TTL and let entries expire naturally.

Event driven invalidation is for data where correctness matters. User permissions, account status, pricing. Delete or update the cache entry at the moment of the change, not on a timer.

Most systems use TTL for everything because it requires less upfront thinking. Then they get burned when a permissions update does not take effect for an hour. The fix is not to lower the TTL. Lowering the TTL is how you get a thundering herd.

The Thundering Herd and How to Solve It

A typical Redis hit takes 1 to 3ms. A typical database query takes 50 to 300ms. That means one cache miss can cost as much as 100 cache hits. At scale, getting this wrong does not just make things slow. It brings services down.

Imagine a hot cache entry expires at 3:00:00 AM. You have 500 concurrent users. At 3:00:01, all 500 get a cache miss simultaneously and fire a database query. Your database, handling 10 queries per second comfortably, suddenly receives 500 in the same second and collapses.

You just traded slightly stale data for a full outage.

Without protection:

500 requests ──► 500 DB queries ──► DB overwhelmed ──► Outage

With jitter + lock:

500 requests ──► 1 DB query ──► Cache filled ──► 499 served from cache

Three solutions, applied in layers.

Solution 1: Jitter

The simplest fix. Add randomness to expiry so entries do not all expire at the same moment. Already built into the CacheClient above via the jitter option.

// Without jitter: 500 entries for a popular endpoint all expire at 03:00:00
await cache.set(key, value, { ttl: 3600 });

// With jitter: entries expire anywhere between 3600 and 3900 seconds
// Stampede risk drops dramatically for zero added complexity
await cache.set(key, value, { ttl: 3600, jitter: 300 });

Add jitter everywhere. It costs nothing.

Solution 2: Stale While Revalidate

Serve the stale entry immediately. Trigger a background refresh. The next request gets fresh data. This is how HTTP caching has worked for decades.

Request ──► Cache hit? ──► Yes, and fresh? ──► Return immediately
                │
                │ Yes, but stale?
                ├──► Return immediately (user does not wait)
                │    └──► Trigger background refresh
                │
                │ No (full miss)
                └──► Fetch from DB ──► Populate cache ──► Return

type FetchFn<T> = () => Promise<T>;

export async function getWithStaleRevalidate<T>(
  cache: CacheClient,
  key: string,
  fetchFn: FetchFn<T>,
  options: CacheOptions & { stale: number }
): Promise<T> {
  const entry = await cache.get<T>(key);

  if (entry) {
    const isStale = Date.now() > entry.expiresAt;

    if (isStale) {
      // Serve the stale value immediately, refresh in the background
      void refreshInBackground(cache, key, fetchFn, options);
    }

    return entry.value;
  }

  // Full miss: fetch synchronously
  const value = await fetchFn();
  await cache.set(key, value, options);
  return value;
}

async function refreshInBackground<T>(
  cache: CacheClient,
  key: string,
  fetchFn: FetchFn<T>,
  options: CacheOptions
): Promise<void> {
  try {
    const value = await fetchFn();
    await cache.set(key, value, options);
  } catch (err) {
    console.error(`Background cache refresh failed for ${key}:`, err);
  }
}

Usage at call sites is one line:

const profile = await getWithStaleRevalidate(
  cache,
  keys.userProfile(userId),
  () => db.findUser(userId),
  { ttl: 300, stale: 600, jitter: 60 }
);

Users never wait on a cache refresh. The background task handles it. The next user gets the fresh value.

Solution 3: Distributed Lock on Cache Miss

For hot single keys, when a miss happens only one process should fetch and repopulate. Others wait briefly. This prevents 500 processes all querying the database for the same row at the same time.

import Redlock from "redlock";

export class LockedCacheClient extends CacheClient {
  private redlock: Redlock;

  constructor(redisUrl: string) {
    super(redisUrl);
    this.redlock = new Redlock([this.getUnderlyingClient()]);
  }

  async getOrFetch<T>(
    key: string,
    fetchFn: FetchFn<T>,
    options: CacheOptions
  ): Promise<T> {
    const entry = await this.get<T>(key);
    if (entry) return entry.value;

    const lockKey = `lock:${key}`;
    let lock;

    try {
      lock = await this.redlock.acquire([lockKey], 5000);

      // Re-check after acquiring the lock.
      // Another process may have already populated the cache while we waited.
      const recheck = await this.get<T>(key);
      if (recheck) return recheck.value;

      const value = await fetchFn();
      await this.set(key, value, options);
      return value;
    } catch {
      // Lock contention: fall back to a direct DB fetch rather than failing the request
      const value = await fetchFn();
      await this.set(key, value, options);
      return value;
    } finally {
      await lock?.release();
    }
  }
}

The re-check after acquiring the lock is critical. Without it, the second process acquires the lock and queries the database anyway even though the first process just populated the cache. This is the double checked locking pattern applied to distributed systems.

Observability: Know What Is Actually Happening

You cannot improve what you cannot see. Wrap your cache client with metrics once and label call sites with a pattern name.

import { Counter, Histogram, Registry } from "prom-client";

export class ObservableCacheClient extends CacheClient {
  private hits: Counter;
  private misses: Counter;
  private hitLatency: Histogram;
  private missLatency: Histogram;

  constructor(redisUrl: string, registry: Registry) {
    super(redisUrl);

    this.hits = new Counter({
      name: "cache_hits_total",
      help: "Total cache hits",
      labelNames: ["key_pattern"],
      registers: [registry],
    });

    this.misses = new Counter({
      name: "cache_misses_total",
      help: "Total cache misses",
      labelNames: ["key_pattern"],
      registers: [registry],
    });

    this.hitLatency = new Histogram({
      name: "cache_hit_duration_seconds",
      help: "Latency of cache hits",
      labelNames: ["key_pattern"],
      registers: [registry],
    });

    this.missLatency = new Histogram({
      name: "cache_miss_duration_seconds",
      help: "Latency of cache misses including the upstream fetch",
      labelNames: ["key_pattern"],
      registers: [registry],
    });
  }

  async getOrFetchObserved<T>(
    key: string,
    keyPattern: string,
    fetchFn: FetchFn<T>,
    options: CacheOptions
  ): Promise<T> {
    const start = performance.now();
    const entry = await this.get<T>(key);
    const elapsed = () => (performance.now() - start) / 1000;

    if (entry) {
      this.hits.inc({ key_pattern: keyPattern });
      this.hitLatency.observe({ key_pattern: keyPattern }, elapsed());
      return entry.value;
    }

    this.misses.inc({ key_pattern: keyPattern });
    const value = await fetchFn();
    await this.set(key, value, options);
    this.missLatency.observe({ key_pattern: keyPattern }, elapsed());
    return value;
  }
}

The three metrics that matter most:

Hit rate per key pattern, not aggregate. If your overall hit rate is 80% but a critical key pattern sits at 20%, the aggregate number is hiding a real problem. Always break this down by pattern.

Eviction rate. If Redis is evicting keys because you are out of memory, you are thrashing, not caching. A Redis hit at 1ms becomes meaningless if the key you need was evicted 30 seconds ago. Increase memory, shorten TTLs, or stop caching data that expires before it is ever read again.

Miss latency. At scale, a cache miss costs 50 to 300ms of database time. If your service depends on sub-10ms responses, one cold endpoint can blow your entire p99. Miss latency tells you exactly how bad the degradation is when your cache fails.

The Decision Checklist Before You Add a Cache

Not every performance problem needs a cache. Run through this before reaching for Redis.

Is the query actually slow or just called too often? N+1 patterns make caching look like the answer when a JOIN is. Profile the query execution plan before adding a cache layer on top of a structural problem.

Can the data be denormalized instead? If you always cache the same join result, consider materializing it in the schema. A cache is sometimes a workaround for a schema designed for write convenience rather than read performance.

Is this actually read heavy? If data is written more often than it is read, cache invalidation overhead exceeds the savings. You are paying the write cost twice: once to the database, once to update or invalidate the cache entry.

What is the cost of serving stale data? Product listings: probably acceptable. Account balance: no. Permissions and access control: never. Make this decision explicitly. Saying "we will just set a short TTL" is not an answer. It is a way of avoiding the question.

What is your cold start story? If your service falls over every time it restarts because the cache is cold, write through caching or a warming script is the fix, not hoping traffic is light during the deploy window.

Putting It All Together

Here is a service that uses everything from this post: typed versioned keys, write through on mutations, stale while revalidate on reads, jitter throughout, immediate delete for permissions, and full observability.

export class ProductionUserService {
  constructor(
    private db: Database,
    private cache: ObservableCacheClient
  ) {}

  async getProfile(userId: string): Promise<UserProfile> {
    return getWithStaleRevalidate(
      this.cache,
      keys.userProfile(userId),
      () => this.db.findUser(userId),
      { ttl: 300, stale: 600, jitter: 60 }
    );
  }

  async updateProfile(userId: string, data: Partial<UserProfile>): Promise<UserProfile> {
    const updated = await this.db.updateUser(userId, data);

    // Write through: fresh data goes straight to cache on every mutation
    await this.cache.set(
      keys.userProfile(userId),
      updated,
      { ttl: 300, stale: 600, jitter: 60 }
    );

    return updated;
  }

  async updatePermissions(userId: string, permissions: Permission[]): Promise<void> {
    await this.db.updatePermissions(userId, permissions);

    // Access control data is deleted immediately, never served stale
    await this.cache.del(keys.userPermissions(userId));
  }
}

Reads use stale while revalidate so users never block on a cache refresh. Profile writes use write through so the cache stays warm after every mutation. Permission changes delete immediately because serving a stale permission is a security issue, not a UX issue.

Closing

The teams that handle caching well treat it as a first class architectural concern. They document cache contracts: what is cached, for how long, what triggers invalidation, and what the acceptable staleness window is. They test cold start and stampede scenarios explicitly. They monitor cache health with the same seriousness as database health.

The teams that handle caching poorly add Redis when things get slow and ship it.

Both approaches work right up until they do not. The difference is that the first team knows exactly what breaks and why when it does. The second team opens their laptop at past midnight and starts reading documentation for the first time or throw in " pls help me, redis no work, idk what is redis no more " into ChatGPT.

The patterns in this post are not theoretical. They are the things you wish were already in the codebase when the incident starts. Put them in before it does.

DEV Community: Adam - The Developer

When Software Started Writing Software: A Developer’s History of AI

Table of Contents

1. The Symbolic Era: Intelligence as Logic (1950s–1980s)

2. Statistics Quietly Eats Symbols (1990s–2000s)

3. Deep Learning Breaks the Ceiling (2012–2017)

4. The Transformer and the Birth of "General-ish" Intelligence (2017–2022)

5. From Chatbot to Coworker: The Agentic Turn (2023–Today)

So What Changed, Really?

There Is No Perfect Solution in Software Development: Every Decision is a Tradeoff

Table of Contents

What Every Engineer Needs to Know About Tradeoffs

Classic Tradeoffs You'll Face

Performance vs. Readability

Flexibility vs. Simplicity

Speed to Market vs. Technical Debt

Scalability vs. Cost

Security vs. Convenience

The CAP Theorem: What It Actually Means

The Pattern: How Good Decisions Actually Get Made

How to Make Better Tradeoff Decisions

The Mark of Experience

The Hidden Machinery Behind Background Jobs

Table of Contents

What We Think Is Happening

Layer 1: Your Application Code

Layer 2: The Network Stack and the Kernel

Layer 3: Inside the Broker

Redis

RabbitMQ

Kafka

Layer 4: The Event Loop, and What Is Actually Powering It

How It Evolved

Layer 5: The Worker, Acknowledgments, and What "At Least Once" Actually Means

Layer 6: The Things That Quietly Go Wrong

What "Fast" Actually Means

The Full Journey, Summarized

Closing

When Duplicate Code Is the Better Design

What DRY Actually Says (and Doesn't)

The Taxonomy of DRY Crimes

Crime #1: Abstracting Coincidental Similarity

Crime #2: The Abstraction That Needs a Manual

Crime #3: DRY Across Wrong Boundaries

Crime #4: The Generic Repository That Ate Your Domain

The Principle You Actually Need: AHA

When DRY Is Right

The Real Anti-Pattern DRY Is Trying to Fight

A Checklist for Before You Abstract

Closing

Minimal Code Doesn’t Mean Stable Code

When Minimal Code Meets Production

What Production Actually Requires

Less Code vs. Less Noise

The Test

The Mid-Dev Paradox: Why Juniors Are Chill and Mid-Levels Will Reorganize Your Code at 3 AM

The Tier List (Controversial, I Know)

Why Juniors Are Actually Great

The Mid-Dev Energy Crisis

Why This Happens (And It's Not Their Fault)

What Actually Works

The Real Insight

⚔️ Go vs Java: The Minimalist vs The Enterprise Veteran

Table of contents

⚔️ The Setup

🥊 The Contenders

🏁 A Quick Origin Story

🧠 Language Philosophy: Complexity vs. Simplicity

⚡ Performance: JVM vs Native Binary

🔀 Concurrency: Goroutines vs Virtual Threads

🌲 Ecosystem & Libraries: The Forest vs The Toolshed

🛠️ Tooling: Go's Discipline vs Java's Buffet

👥 Team Learning Curve: The First Month Matters

Go: Steep and Short

Java: Gradual and Endless

The Team Implication

In Practice

🏢 Where Each One Shines

Go is great for:

Java is great for: