DEV Community: Adam - The Developer

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

Comments 29

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.

Episode 2: I Was a Junior Developer and I Must Be Stopped

Adam - The Developer — Thu, 02 Apr 2026 03:36:54 +0000

Welcome back.

Last episode, we reviewed a Laravel function that used three loops to reconstruct an array it already had, fired two database queries per item instead of one, and named a variable $r_arr with the confidence of a man who has never once been held accountable for anything.

It was a good one, some of us liked it.

So today, we are reviewing my hotel invoice generator. It is a PHP class called ExcelController. It imports guest data from an uploaded Excel file and exports a personalised invoice for each guest, packed into a zip file for download.

It was never merged.

The room numbers are completely random.

My senior opened the PR. He read through it. He left seven comments. He never raised his voice. He never sent a follow-up Slack. He just reviewed it with the quiet, deliberate calm of a man who has already accepted his fate and is simply choosing, each day, to keep showing up anyway.

Here it is:

class ExcelController
{
    public function import(Request $request, ImportedFile $filedata, User $user, Excelconfig $config)
    {
        try {
            $file = $request->file('file');
            if (!$file) {
                return redirect()->back()->with('error', 'Please choose a file to import');
            }

            $spreadsheet = IOFactory::load($file);
            $numSheets = $spreadsheet->getSheetCount();
            if ($numSheets > 1) {
                return redirect()->back()->with('error', 'Excel file has more than one sheet.');
            }

            Excel::import(new DataImport, $file);
            $this->export($filedata, $user, $config);
            return redirect()->back()->with('success', 'File imported successfully.');
        } catch (\Exception $e) {
            DB::rollBack();
            return redirect()->back()->with('error', 'File import failed: ' . $e->getMessage());
        }
    }

    public function export($filedata, $user, $config)
    {
        $getfile_name = $user->where('id', 1)->pluck('default_file')[0];

        $file_path = base_path("/storage/app/main_file/$getfile_name");
        if (file_exists($file_path)) {
            $file = $file_path;
        }
        $file = base_path("/storage/app/main_file/main_file.xls");

        $num_copies = count($filedata::all()) - 1;
        $spreadsheet = IOFactory::load($file);

        $guest_names = $filedata::all()->pluck('guest_name');
        $invoice_number = $filedata::all()->pluck('reservation_number');
        $payment_date = $filedata::all()->pluck('payment_date');
        $room = "Room" . " " . rand(1, 19);
        $nights_stayed = $filedata::all()->pluck('number_nights_stayed');
        $price = $filedata::all()->pluck('total_revenue');

        $zip = new ZipArchive;
        $zip_name = now()->format('Ymd_His') . '.zip';
        if ($zip->open(storage_path('app/' . $zip_name), ZipArchive::CREATE) === TRUE) {
            for ($i = 1; $i <= $num_copies; $i++) {
                $zip_file_name = 'Guest' . $i . '.xlsx';
                $worksheet = $spreadsheet->getActiveSheet();

                $message_index = $i - 1;

                $_guestNameRow = $config->where('id', 1)->pluck('guest_name')[0] ?? 'A21';
                $_invoiceNumRow = $config->where('id', 1)->pluck('invoice_number')[0] ?? 'B15';
                $_dateRow = $config->where('id', 1)->pluck('payment_date')[0] ?? 'B17';
                $_roomRow = $config->where('id', 1)->pluck('room')[0] ?? 'B21';
                $_quantity = $config->where('id', 1)->pluck('nights_stayed')[0] ?? 'C21';
                $_unitPrice = $config->where('id', 1)->pluck('unit_price')[0] ?? 'D21';
                $_amountPrice = $config->where('id', 1)->pluck('amount_price')[0] ?? 'E21';
                $_amountTotal = $config->where('id', 1)->pluck('amount_price_row_total')[0] ?? 'D34';
                $_unitTotal = $config->where('id', 1)->pluck('unit_price_total')[0] ?? 'E34';

                $spreadsheet->getActiveSheet()->setCellValue($_guestNameRow, $guest_names[$message_index] ?? null);
                $spreadsheet->getActiveSheet()->setCellValue($_invoiceNumRow, $invoice_number[$message_index] ?? null);
                $spreadsheet->getActiveSheet()->setCellValue($_dateRow, $payment_date[$message_index]);
                $spreadsheet->getActiveSheet()->setCellValue($_roomRow, $room);
                $spreadsheet->getActiveSheet()->setCellValue($_quantity, $nights_stayed[$message_index] ?? null);
                $spreadsheet->getActiveSheet()->setCellValue($_unitPrice, ((float)$price[$message_index] / (int)$nights_stayed[$message_index]) ?? null);
                $spreadsheet->getActiveSheet()->setCellValue($_amountPrice, $price[$message_index] ?? null);
                $spreadsheet->getActiveSheet()->setCellValue($_unitTotal, ((float)$price[$message_index] / (int)$nights_stayed[$message_index]) ?? null);
                $spreadsheet->getActiveSheet()->setCellValue($_amountTotal, $price[$message_index] ?? null);

                $writer = new Xlsx($spreadsheet);
                ob_start();
                $writer->save('php://output');
                $file_contents = ob_get_clean();
                $zip->addFromString($zip_file_name, $file_contents);
            }
            $zip->close();

            header("Content-Type: application/zip");
            header("Content-Disposition: attachment; filename=$zip_name");
            header("Content-Length: " . filesize(storage_path('app/' . $zip_name)));
            readfile(storage_path('app/' . $zip_name));
            exit;
        }
    }
}

Take it in. Sit with it. Let it wash over you like a wave you saw coming from a mile away and decided not to move for.

Now. Let's go through it together. I recommend water. I recommend a snack. I recommend telling someone you love them before we start, just in case.

The `import()` Method, Which Does Not Import

public function import(Request $request, ImportedFile $filedata, User $user, Excelconfig $config)

Four injected dependencies. FOUR. Request. ImportedFile. User. Excelconfig. A full starting lineup. An ensemble cast. A heist crew assembled with purpose and intention.

And what does import() do with them? It validates the file exists, hands it to Excel::import(), and then — immediately, in the next breath, before the import has even had time to feel good about itself — calls $this->export() and passes all four dependencies over like a baton.

import() does not import. import() is a method that watches another method work and then takes credit at standup. import() is the guy who responds "yeah, we shipped that" while making eye contact with the person who actually shipped it, daring them to say something.

Three of the four injected dependencies are not used in import() at all. They exist solely to be forwarded. They showed up for a job they were not given, were immediately redirected, and had to pretend that was the plan all along.

My senior's very first comment on this PR was: "why does import() call export()?"

Not aggressive. Not horrified. Just a quiet, five-word question with a question mark that somehow conveyed the weight of every PR he had ever reviewed before this one.

I did not have a good answer. I replied anyway. The reply was not good.

The Rollback That Has Nothing to Roll Back

} catch (\Exception $e) {
    DB::rollBack();
    return redirect()->back()->with('error', 'File import failed: ' . $e->getMessage());
}

There is no DB::beginTransaction() anywhere in this class.

I want you to understand the full scope of what has happened here. DB::rollBack() is an instruction to undo a database transaction. A transaction that was never opened. There is nothing to undo. There has never been anything to undo. The database received this rollback instruction, checked its records, found no open transaction, shrugged in whatever way databases are capable of shrugging, and moved on.

This is not a bug. It's a philosophy. It's the worldview of someone who believes that calling rollBack() near a database operation is close enough. The vibes are correct. The implementation is a void.

It's like calling refund() on a purchase you never made. It's like issuing a formal apology for something you didn't do. It's like cancelling a reservation at a restaurant you never booked, and then waiting at home for confirmation that you don't have a table.

My senior's comment here was two words: "no transaction."

Two words. No question mark. No exclamation. Two words, written by a man conserving his energy for what he was about to find next.

User ID 1. Just User ID 1. Only Ever User ID 1.

$getfile_name = $user->where('id', 1)->pluck('default_file')[0];

This system has one user. His name is User ID 1. He is the client, the admin, the guest, and apparently the sole known resident of the hotel this invoice generator was built for. He has no colleagues. He has no hierarchy above or below him. He simply is, hardcoded and eternal, where('id', 1), forever.

Multi-tenancy is a concept this code has never heard of. Role-based access control is a myth, like dragons, or good variable names. There is only User ID 1. He is in the controller. He is in the database. He is in my code. He is everywhere. He always will be.

To be clear: this was a single-client internal tool. There technically was only one user. But still. To look at a codebase, decide that ->where('id', 1) is fine to hardcode into a controller, and commit it — that's not just a shortcut. That's a statement of values.

The `if` Block That Tried So Hard and Was Immediately Betrayed

$file_path = base_path("/storage/app/main_file/$getfile_name");
if (file_exists($file_path)) {
    $file = $file_path;
}
$file = base_path("/storage/app/main_file/main_file.xls");

We check whether a dynamic file exists. If it does, we assign it to $file. This is good. This is correct. This is the code doing exactly what code is supposed to do.

And then — on the very next line, with no condition, no ceremony, no acknowledgment whatsoever of what just happened — we overwrite $file with a hardcoded path to main_file.xls.

The if block is a ghost. It built $file with love and intention, watched it get immediately overwritten, and now haunts the codebase unable to affect anything, just flickering the lights occasionally to let us know it was here once and it mattered and we chose not to listen.

Every single guest received the same template. The dynamic file path never made it. The if block knew. It stood there and watched and couldn't stop it.

I think about this if block sometimes. I think about its optimism. I think about how it ran, found the file, did its job perfectly, and then got erased before it could even tell anyone.

We're not so different, the if block and I.

Six Queries. Same Table. In a Row. Like a Person Who Has Completely Lost the Plot.

$num_copies = count($filedata::all()) - 1;  // query 1
$guest_names = $filedata::all()->pluck('guest_name');       // query 2
$invoice_number = $filedata::all()->pluck('reservation_number'); // query 3
$payment_date = $filedata::all()->pluck('payment_date');    // query 4
$nights_stayed = $filedata::all()->pluck('number_nights_stayed'); // query 5
$price = $filedata::all()->pluck('total_revenue');          // query 6

Six. Six times. $filedata::all(). The same query. SELECT * FROM imported_files. Six full round trips to the database before the loop has even started. Six times I loaded the entire table into memory, grabbed one column off it, and threw the rest away, and then immediately did it again.

The correct code is one query followed by five collection operations:

$filedata = ImportedFile::all(); // once. just once. please.
$num_copies = $filedata->count() - 1;
$guest_names = $filedata->pluck('guest_name');

That's it. That's the whole fix. Load it once. It stays in memory. Use it five times. The database does not need to hear from you six times about the same table in the same second. The database is not a service counter. You don't need to take a new number each time.

If the database could file a complaint it would have. It did not, because databases are more professional than this code deserved.

The Room Number Is Random. I Need You To Understand That The Room Number Is Random.

$room = "Room" . " " . rand(1, 19);

I am going to say it plainly and I need you to receive it plainly:

The room number is randomly generated.

This is a hotel invoice generator. Its entire reason for existing is to produce legally adjacent documents that guests may use for expense reimbursement, business travel records, or billing disputes. A guest stays in Room 7. They receive an invoice. The invoice says Room 11. They ask for a corrected invoice. We regenerate it. It says Room 4. We regenerate it again. Room 17.

There is no floor. There is no ceiling on the chaos. There is only rand(1, 19), spinning eternally, indifferent to consequences, assigning rooms with the energy of a hotel that has completely given up on the concept of room assignments as a coherent system.

The data is there, in the uploaded file. The actual room number exists. It is a column. It was imported. It is sitting in the database. And instead of retrieving it, past me looked at the data, decided rand(1, 19) captured the spirit of the thing, and moved on.

My senior's comment on this line was: "the room number is random."

Not a question. Not a fix suggestion. Just a statement. An observation delivered by someone who had clocked what they were looking at, accepted it, and decided that documentation was the only appropriate response.

I replied: "yes I'll fix it."

He replied: "ok."

That was the entire conversation. We both agreed, silently, that there was nowhere productive to go from there.

Nine Queries Per Guest. Inside The Loop. Per Guest. Nine. Per Guest. Inside The Loop.

for ($i = 1; $i <= $num_copies; $i++) {
    $_guestNameRow = $config->where('id', 1)->pluck('guest_name')[0] ?? 'A21';
    $_invoiceNumRow = $config->where('id', 1)->pluck('invoice_number')[0] ?? 'B15';
    $_dateRow = $config->where('id', 1)->pluck('payment_date')[0] ?? 'B17';
    // six more of these

Nine. $config->where('id', 1). Nine times. Per iteration. Inside the loop.

This is the same row. It is always the same row. It was the same row on the first iteration. It will be the same row on the hundredth iteration. The config table does not update between guests. The laws of physics have not changed. The database did not go anywhere. The row is still there, completely unchanged, waiting patiently to be fetched for the 847th time.

100 guests: 906 total queries. And that's on top of the 6 we fired before the loop even started, which we haven't forgiven yet.

The fix is to fetch the config once. Before the loop. Assign it to a variable. Use that variable. The database would send a fruit basket. The database would cry. Not from sadness. From relief.

My senior left his longest comment here. Four sentences. Query optimization. N+1 problems. Eager loading. The works. It was generous. It was thorough. It was the kind of comment you leave when you genuinely believe the person on the other side can be better.

I read it. I understood approximately 60% of it. I said "thanks, will fix."

The PR was closed the next day. Not merged. Closed.

`$message_index`, a Variable That Means `$i - 1` and Wants You to Know It

$message_index = $i - 1;

The loop starts at 1. Arrays start at 0. We need $i - 1. This is fine. This is correct. I have no complaints about the arithmetic.

What I have complaints about is the name.

$message_index. In a hotel invoice generator. There are no messages. There has never been a message. No message is sent, received, composed, parsed, or gestured at anywhere in this codebase. But the variable needed a name, and the name it received was $message_index, with the full confidence of someone who is naming things based on vibes and hoping nobody asks follow-up questions.

It's not wrong. It functions. But it's like naming a file document1_FINAL_v3_USE_THIS_ONE_actually_final.xls. Technically a name. Technically communicating something. Not the something it thinks it's communicating.

The Ghost of PHP 4, Given the Keys to a Laravel Application

header("Content-Type: application/zip");
header("Content-Disposition: attachment; filename=$zip_name");
header("Content-Length: " . filesize(storage_path('app/' . $zip_name)));
readfile(storage_path('app/' . $zip_name));
exit;

We are inside a Laravel controller. Laravel has a response system. It has response()->download(). It is one line. It is documented. It handles headers automatically. It does not require you to manually compute Content-Length. It does not require you to call readfile() like you're writing a blog post about PHP in 2005. And it absolutely does not require you to call exit to kill the entire PHP process when you're done.

But we didn't do that. Instead we reached back through time, found PHP 4, handed it a zip file, said "you know what to do," watched it do a little dance with raw header() calls, and then exited out of existence.

exit. Not return. exit. We terminated the process. We didn't return a response. We didn't let Laravel wrap up gracefully. We just... left. Walked out mid-conversation. The framework stood there, holding the door open, waiting for a response object that was never coming.

The Final Tally

things that went wrong:
- import() that exists to not import:                                     ✅
- DB::rollBack() haunting a transaction that was never born:              ✅
- if block built $file perfectly then watched it die immediately:         ✅
- SELECT * fired 6 times on the same table, consecutively, on purpose:    ✅
- 9 config queries per guest inside the loop, 100 guests = 906 total:     ✅
- room numbers: rand(1, 19). not the actual room. a random room. always:  ✅
- $message_index: means $i-1, works nowhere, explains nothing:            ✅
- exit. just exit. in a Laravel controller. in the year of our lord:      ✅

PR comments left by senior:                                               7
PR comments addressed:                                                    0
PR status:                                                           closed

The Verdict

This code never shipped. The PR was closed. My senior reviewed every line of it, the phantom rollback, the six identical queries, the rand(1, 19) that could have ruined an expense report, all of it — and he left real comments with real explanations, like someone who looked at this disaster and somehow still saw a person who could learn.

He didn't laugh in the thread. He didn't forward it to anyone. He didn't bring it up in the next sprint. We agreed, without ever agreeing, to never speak of it, the way you agree to never speak of certain things that happen at work parties, certain things that happen on difficult deployments, certain things you open in a PR at 11am on a Tuesday and close by lunch.

But here is what I think about, now that I am far enough away from it to think:

He reviewed it anyway. That's the part that stays with me. He could have closed it in thirty seconds. He didn't. He went through it. He explained the N+1 problem to someone who didn't fully understand it yet. He noted the rollback. He pointed at the room number, stated plainly that it was random, and waited.

That's not a small thing. That is, in fact, the whole thing.

If you're a senior reading this: I see you. I know what it costs. Every comment you write on a PR from someone still figuring it out is a small act of faith that they will eventually figure it out. That faith is not nothing.

If you're a junior reading this: somewhere there is a folder. Not a literal one, maybe. But your senior has a folder. Full of PRs that keep them up. You are in that folder. The random room numbers are in that folder.

Do better. They're rooting for you. They reviewed the whole thing. They always do.

Episode 1: I Was a Junior Developer and I Must Be Stopped

Adam - The Developer — Tue, 31 Mar 2026 04:15:12 +0000

We all start somewhere.

Some developers begin their careers writing clean, well-structured code, carefully following best practices, naming variables properly, and writing tests like responsible adults.

Others start by shipping a few bugs here and there, learning, improving, and slowly developing their own style.

And then there's me.

Today, we are reviewing a function I wrote years ago that is somehow still running in production, untouched, unbothered, and — against all odds — still working. No one has dared to refactor it. No one has tried to rewrite it. It has achieved something most code never will:

It became too scary to change.

This function is called multipleUpdate.
It lives in a Laravel application.
It updates multiple items.
I think.

Here it is, in all its glory:

public function multipleUpdate(
    Scenario $scenario,
    Request $request
) {
    $r_arr = intval($request->right_arr);
    $id_array = $request->item_number ?? $r_arr;
    $name_ja_array = $request->name_ja ?? null;
    $name_en_array = $request->name_en ?? null;
    $type_array = $request->type ?? null;

    $added = []; // final res
    array_push($added, $r_arr);
    $difference = [];

    for ($i = 0; $i < count($id_array) - 1; $i++) {
        array_push($difference, $id_array[$i + 1] - $id_array[$i]);
    }

    for ($i = 0; $i < count($difference); $i++) {
        array_push($added, $r_arr += $difference[$i]);
    }

    for ($i = 0; $i < count($added); $i++) {
        if ($scenario->items()->where('item_number', $added[$i])->exists()) {
            $scenario->items()->where('item_number', $added[$i])->update([
                'name_ja' => ($name_ja_array[$i] ?? $request->default_name_ja) ?? null,
                'name_en' => ($name_en_array[$i] ?? $request->default_name_en) ?? null,
                'kind' => ($type_array[$i] ?? $request->default_type) ?? null,
            ]);
        } else {
            $scenario->items()->create([
                'scenario_id' => $scenario->id ?? null,
                'item_number' => $added[$i] ?? null,
                'name_ja' => $name_ja_array[$i] ?? null,
                'name_en' => $name_en_array[$i] ?? null,
                'kind' => $type_array[$i] ?? null,
            ]);
        }
    }
}

Take a moment. Let it wash over you. I'll be here.

Now let's go through it together, line by line, like a crime scene investigator who is also crying.

The Mysterious `$r_arr` Variable

// oh cool, a variable named $r_arr. what does r stand for? right? raw? random?
// who the hell knows. the author was apparently too busy to leave a single hint.
$r_arr = intval($request->right_arr);

$r_arr. Short for right_arr, which comes from the request field right_arr.

What is "right"? Right as in correct? Right as in direction? Right as in the author just started typing and committed before their brain caught up?

We will never know. There are no comments. There is no documentation. There is only $r_arr, staring back at you, completely unashamed.

Sir, This Is an Int

// sir this is an int. you are about to count() and loop over a single goddamn int.
// i genuinely hope you tested this. i genuinely fear that you did.
$id_array = $request->item_number ?? $r_arr;

The variable is called $id_array. It implies an array. It promises an array. It has the word array right there in the name.

The fallback is $r_arr, which we just established is an int.

So if $request->item_number is missing, $id_array is a single integer, and we are about to call count() on it, loop over it, and index into it like it's an array.

PHP, famously lenient, will try its best. PHP will not succeed.

The `?? null` Epidemic

// breaking news: local developer discovers that $request->name_ja ?? null
// and $request->name_ja are the same fucking thing. more at 11.
$name_ja_array = $request->name_ja ?? null;
$name_en_array = $request->name_en ?? null; // still doing it. unbelievable.
$type_array = $request->type ?? null;       // i am losing my mind.

$x ?? null means: "if $x is null, use... null."

This is the coding equivalent of a safety net made of holes. It is null, wearing a seatbelt, driving into a wall.

The author wrote this three times in a row. On three separate lines. Without stopping to wonder if something had gone wrong in their life.

The Comment That Explains Nothing

$added = []; // final res

"final res."

Final result? Final response? Final resignation letter?

You cannot write // final res and then disappear like a deadbeat dad. Come back. Explain yourself. We deserve that much.

Also: array_push($added, $r_arr) to append a single value. The author could have written $added[] = $r_arr. It's shorter. It's faster. It doesn't make me feel things.

But they didn't. They used array_push. For one value. And then kept going.

The Round Trip to Nowhere

Now we reach the heart of it. The crown jewel. The part that made me go outside and stand in a field for ten minutes.

// oh no. oh hell no. i see where this is going and i am grabbing you by the shoulders.
// you're going to calculate the gaps between IDs, aren't you.
// you absolute disaster of a human being.
for ($i = 0; $i < count($id_array) - 1; $i++) {
    array_push($difference, $id_array[$i + 1] - $id_array[$i]);
}

// and NOW you're adding them back together. you took [10, 12, 15],
// blew it up into [2, 3], and then painstakingly rebuilt [10, 12, 15].
// you did a round trip to absolutely nowhere and burned CPU cycles for the privilege.
// i am genuinely asking: are you okay? do you need water?
// did someone hurt you?
for ($i = 0; $i < count($difference); $i++) {
    array_push($added, $r_arr += $difference[$i]);
}

Let me walk you through what's happening here.

We have an array of IDs: [10, 12, 15].

Loop one: compute the differences between consecutive IDs. [2, 3].

Loop two: add those differences back, cumulatively, to reconstruct... [10, 12, 15].

We took the array. We destroyed it. We rebuilt it. We are exactly where we started.

This is a mathematical round trip that accomplishes zero. The only thing it changes is $r_arr, which started life as a request input, briefly became a loop accumulator, and is now something else entirely.

$r_arr has had more identity changes in one function than most people have in a lifetime. Leave $r_arr alone. $r_arr has been through enough.

The Database Loop of Sadness

We are now in loop three. The database loop. God help us.

for ($i = 0; $i < count($added); $i++) {
    if ($scenario->items()->where('item_number', $added[$i])->exists()) {
        $scenario->items()->where('item_number', $added[$i])->update([...]);
    } else {
        $scenario->items()->create([...]);
    }
}

Two database queries per item. One to check if it exists. One to update or create it.

No transaction wrapper. No bulk operation. Just a prayer and a dream that nothing fails halfway through and leaves the database looking like it was updated by a raccoon who found a keyboard.

And then there's this:

$scenario->items()->create([
    'scenario_id' => $scenario->id ?? null,
    'item_number' => $added[$i] ?? null,
    ...
]);

$scenario->id ?? null. We dependency-injected $scenario into the function signature. Laravel loaded it, validated it, handed it to us on a silver platter. If $scenario->id is null at this point, ?? null is not saving us. Nothing is saving us. Say your goodbyes.

$added[$i] ?? null. We are inside the loop that iterates over $added. $added[$i] is guaranteed to exist. The ?? null is not a safety net. It is a tiny umbrella in a drink that is already on fire.

The Method That Was Right There the Whole Time

Here is the part that gets me.

Laravel has had updateOrCreate() since version 5.3.

$scenario->items()->updateOrCreate(
    ['item_number' => $added[$i]],
    [
        'name_ja' => $name_ja_array[$i] ?? $request->default_name_ja,
        'name_en' => $name_en_array[$i] ?? $request->default_name_en,
        'kind'    => $type_array[$i] ?? $request->default_type,
    ]
);

One method. One query. Handles both cases. No manual existence check. No separate create/update branch.

It was sitting right there the whole time, like a golden retriever waiting by the door.

And I looked it in the face, said "no thanks," and wrote a three-loop differential equation instead.

I'm not angry at myself.

I'm disappointed.

(I am absolutely furious.)

The Final Tally

crimes committed:
- 3 loops to rebuild the array we already had:                       ✅
- up to 2N db queries with zero transaction safety:                  ✅
- $r_arr living three different lives in one function:               ✅
- ?? null deployed purely as emotional support:                      ✅
- updateOrCreate() left completely untouched like a jilted lover:    ✅
- "final res" as a comment explaining nothing:                       ✅

And yet.

And yet.

It works. It has always worked. It is running in production right now, at this very moment, as you read this. No one has touched it. No one will. It works and that is the most infuriating part of all of this.

The real multipleUpdate was the trust issues we developed along the way.

If you have code like this living rent-free in your production environment — code that works, code that you are afraid to touch, code that you wrote and no longer recognize — I want you to know: you are not alone.

We all have a multipleUpdate. Some of us just haven't found ours yet.

Episode 2 coming whenever I'm emotionally ready.

Resume-Driven Development Is Quietly Killing Your Product

Adam - The Developer — Wed, 25 Mar 2026 06:51:34 +0000

There is a conversation that happens in engineering teams all over the world, constantly, and it almost always goes the same way.

Someone proposes a new project. Before the requirements are even clear, before anyone has talked to a user, before the scope has been defined, someone opens their mouth and says: "What if we used this for the Rust rewrite?" Or: "This could be a great chance to try out that new edge runtime." Or: "I've been wanting to get some GraphQL experience."

And just like that, the technical decision has been made. Not by the problem. By someone's LinkedIn headline in 18 months.

This is Resume-Driven Development. It is everywhere. Almost nobody talks about it honestly. Partly because it's awkward to name, and partly because most of the people who should be naming it are also doing it.

What It Actually Looks Like

RDD rarely announces itself. It doesn't walk into the room wearing a sandwich board. It hides inside reasonable-sounding language, nodding along to the business requirements before quietly steering the conversation toward whatever technology someone bookmarked last weekend.

"We need something more scalable." Scalable to what? You have 200 users. Postgres hasn't broken a sweat. What you actually need is three more customers, not a distributed event-driven microservices architecture that requires four new AWS services, a dedicated DevOps hire, and someone brave enough to own the on-call rotation.

"The developer experience with this new tool is so much better." For whom? For the one engineer who spent two weekends learning it and is now the team's only expert? That is not better DX. That is a bus factor of one wearing a conference lanyard.

"We should use what the industry is moving toward." The industry is moving toward approximately forty things simultaneously and half of them will be deprecated before you finish the migration. Bun, Deno, whatever JavaScript framework launched last Tuesday, that new database that promises to replace all other databases while also making coffee. The industry is always moving. Products still need to ship.

The giveaway is always the same: the technology choice happens before the problem is fully understood. The cart is so far in front of the horse it has its own Kubernetes cluster.

The Honest Reason This Happens

Let's just say it plainly. The job market for developers rewards people who have used the new thing more than it rewards people who deeply understand boring, proven things. A resume with Kubernetes, GraphQL, and a trendy new runtime gets more recruiter messages than a resume that says "kept a Rails monolith running smoothly for five years and scaled it to a million users."

The incentives are completely misaligned with good engineering.

So developers, who are rational people, optimize for what the market rewards. They look for projects where they can justify using the new thing. They advocate for the new thing in architecture discussions. They get the experience on paper. Then they move on, often right around the time the true cost of that decision starts showing up in sprint retrospectives.

The product is not their primary concern in that moment. Their career is. That is human. That is understandable. It is also quietly catastrophic for the companies on the receiving end who wonder why everything takes so long and costs so much.

RDD Is Not the Actual Problem

Here is where most essays like this go wrong: they treat RDD as the villain. It is not.

Wanting to grow your skills is healthy. Wanting to work with modern tools is healthy. Advocating for better technology on your team is healthy. If developers never pushed to try new things, we would all still be writing SOAP XML by hand and arguing about tabs versus spaces in Vim. Some of us would enjoy that. Most of us would not.

The real problem is not that someone wanted to use a new tool. The real problem is that nobody stopped to have an honest conversation about what the business actually needed before the new tool got greenlit.

RDD becomes toxic at exactly the moment when the technology choice gets made in a vacuum. When nobody asked "what are we trying to accomplish in the next six months?" When nobody checked whether the existing stack had actually failed or was merely unfashionable. When the pitch was "this is better" without anyone defining better for whom, by what measure, over what time horizon.

A team that wants to use Rust and has a genuine performance problem that Rust would solve? Great. Go forth and rewrite. A team that wants to use Rust because a senior engineer just finished a side project in it and the current service is written in Go and works perfectly fine? That is RDD doing damage in a fleece vest and acting like it's doing the company a favor.

The difference is a conversation. A specific, slightly uncomfortable conversation where someone asks "what does the business need right now" and everyone has to sit with the answer even if it is boring.

What It Costs When That Conversation Doesn't Happen

The costs of undiscussed RDD are almost never measured because they happen slowly and diffusely and get attributed to other causes.

A team picks a new framework because it is exciting and nobody pushed back with requirements. Six months later, onboarding takes twice as long because the framework has steep learning curves and opinionated patterns that new hires have to unlearn their previous experience to adopt. That cost does not get traced back to the framework choice. It gets called "hiring is hard."

A team builds on a cutting-edge but immature library because it looked great at the time and the business case was hand-wavy. Two years later, the maintainer abandons it. Now the team owns it. That cost shows up as "tech debt" in a planning meeting, orphaned from the original decision that created it.

A team introduces a microservices architecture to a product that did not need one because someone wanted the experience. Local development becomes a nightmare involving Docker Compose files that nobody fully understands. Debugging a request means tracing it across six services. Deployments are complicated. None of this gets credited to the architectural decision. It gets called "complexity" as though complexity is weather that just rolls in and there is nothing to be done about it.

The engineers who made those choices are often long gone by the time the costs fully materialize. They have the experience on their resumes. The company has the mess. And a new round of engineers eager to rewrite it all in something more modern.

The Boring Stack Works

There is a version of this essay that collapses into a "just use Rails" post and I want to resist that because it misses the point. The point is not that new technology is bad. The point is that the decision should follow from the problem, and following from the problem requires first understanding the problem, which requires talking to the people who have the problem.

Boring, mature, well-understood technology has compounding advantages that are consistently undervalued because they are invisible. You do not see the bugs that did not happen because the ORM is stable. You do not see the hours not spent reading documentation for a library that has fifteen years of Stack Overflow answers covering every possible mistake. You do not see the hires who got productive in two weeks instead of two months because they already knew the stack.

Boring technology has been debugged by thousands of teams in thousands of situations. The edge cases are documented. The failure modes are known. When something breaks at 3am, someone has already written the blog post about it and the fix is four lines.

You are paying the price of novelty whether you account for it or not. The question is whether you made that tradeoff deliberately or just kind of drifted into it because the senior engineer seemed really enthusiastic in that one architecture meeting.

When New Technology Is Actually the Right Call

There are real situations where reaching for something new is the correct engineering decision. When the problem genuinely cannot be solved well with mature tools. When performance requirements are extreme and you have actual benchmarks showing existing tools fail. When the new technology has enough production adoption that its failure modes are understood rather than theoretical. When the team has the bandwidth to absorb the learning cost without stalling product delivery.

The difference in all these cases is that the technology choice follows from a requirement. You started with a real constraint. You evaluated options against it. You chose the best fit.

That is engineering. It is also, not coincidentally, a much easier decision to defend when things get hard and someone above your pay grade starts asking questions.

What is not engineering is starting with "I want to use X" and working backward to a justification. What is especially not engineering is doing that without ever asking the product manager, the founder, or the customer what they actually need from the next six months of development.

The Conversation That Makes the Difference

The question that almost never gets asked before a major stack decision is embarrassingly simple: what does this business need to be true in twelve months, and how does this technology choice help or hinder that?

Not "what's interesting." Not "what's scalable in theory." Not "what would be impressive in a conference talk." What does the business need.

That question is boring to ask. It often produces boring answers. A monolith. A managed database. Server-rendered HTML. A framework your entire team already knows. Things that do not make for interesting blog posts but do make for products that ship on time and do not require a tribal knowledge handoff every time someone quits.

The engineering leader's job, in part, is to make sure this conversation happens before the exciting choice gets made. That means creating space for someone to say "we want to try this, and here is how it maps to what we actually need" and requiring that the second half of that sentence be filled in with something real, not vibes.

If someone can genuinely make the case that the new tool serves the business, then by all means use the new tool. Put it on the roadmap. Put it on your resume. You earned it honestly. The goal was never to ban ambition. The goal was to make sure ambition and business reality are at least on speaking terms before you start the sprint.

The new framework will not save your product. The exciting database will not fix your architecture. The Rust rewrite will not make your users happier.

But a team that openly discusses what they want to learn, weighs it honestly against what the business needs, and makes a deliberate choice? That team can pick almost anything and make it work.

The technology was never really the point. The conversation was.

DEV Community: Adam - The Developer

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:

🤷 The Honest Answer

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

The Lie We Tell Ourselves

What "Easy to Delete" Actually Means

1. It lives in one place

2. It has a clear boundary

3. It doesn't know too much

4. It's hidden behind a seam

A Different Way to Think About Abstraction

Deletability as a Code Review Lens

Impermanence Is Not Defeatism

In Practice: A Checklist

The Code You Don't Have to Write

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

Why I'm Building SaaS in 2026

Why High-Performing Teams Look Like They Do Nothing

The Confusion

Why This Happens

What It Costs

What Real Challenge Looks Like

Silence Can Be the Sound of Quality

A Note to Managers

The Developer Who Reviews Everything and Ships Nothing

Before We Go There

The Pattern

Where They Put Their Time

What It Actually Costs

Nitpicking Is Not Mentorship

The Accountability Gap

Fixes With Actual Teeth

Raising the Bar vs. Holding the Door Shut

The Mirror

Your Caching Strategy Is Not a Strategy

Table of Contents

Caching Is a Contract

The Three Classic Patterns (And When to Use Each)

Build a Cache Client Worth Using

The `import()` Method, Which Does Not Import

The `if` Block That Tried So Hard and Was Immediately Betrayed

`$message_index`, a Variable That Means `$i - 1` and Wants You to Know It

The Mysterious `$r_arr` Variable

The `?? null` Epidemic