DEV Community: Om Keswani

The Feature Factory Problem: How High-Velocity Teams Accidentally Kill Good Software

Om Keswani — Tue, 05 May 2026 10:26:53 +0000

There’s a moment in almost every fast-moving tech team when productivity starts to feel… off.

Releases are frequent. Sprint boards are always full. Metrics look great on paper. But underneath that velocity, something quietly breaks: the product itself.

This is the Feature Factory problem.

Shipping More, Thinking Less

In a Feature Factory, success is measured by output—how many features shipped, how fast tickets are closed, how packed the roadmap looks. It feels efficient. It looks impressive.

But here’s the catch: shipping features isn’t the same as solving problems.

Teams stop asking why a feature exists. Instead, they focus on when it will be delivered.

Over time, this creates software that feels bloated, inconsistent, and strangely disconnected from real user needs.

The Slow Death of Product Thinking

When velocity becomes the priority, product thinking becomes optional.

Engineers stop questioning requirements. Designers rush through decisions. Product managers become backlog managers.

No one owns the outcome—only the output.

Ironically, the faster the team moves, the less time they spend validating whether they’re building the right thing.

And that’s how good software dies: not with a bug, but with a backlog.

The Hidden Costs No One Tracks

Feature factories don’t fail immediately. In fact, they often look like top performers.

But the costs show up elsewhere:

Increasing technical debt that no sprint seems to fix
Features that overlap, conflict, or go unused
Onboarding that becomes harder with every release
Users who feel the product is “getting worse,” even as more is added

The system optimizes for speed, but accumulates chaos.

Why It Happens (Even to Smart Teams)

No team chooses to become a Feature Factory.

It usually starts with good intentions:

Pressure from leadership to “move faster”
Competitive fear—someone else might ship first
Misaligned incentives (output > impact)
Roadmaps treated as commitments instead of hypotheses

Gradually, questioning slows down. Execution speeds up. And the balance tips.

Breaking Out of the Factory

Escaping the Feature Factory doesn’t mean slowing down. It means building with intent.

A few shifts change everything:

Measure success by outcomes, not output
Treat features as experiments, not deliverables
Create space for engineers to challenge ideas
Prioritize deleting as much as adding
Regularly ask: “Would we build this again today?”

Good teams don’t just ship fast—they learn fast.

The Real Goal

Software isn’t valuable because of how much it does.

It’s valuable because of what it does well.

High-velocity teams don’t kill software because they move too fast. They kill it because they stop listening—to users, to signals, to doubt.

The best teams aren’t feature factories.

They’re learning systems.

And that difference shows up in every product you actually enjoy using.

Why Most Internal Developer Tools Fail (Even When the Tech Is Perfect)

Om Keswani — Sun, 03 May 2026 09:42:25 +0000

There’s a quiet graveyard inside most tech companies. It’s filled with beautifully engineered internal tools—fast, scalable, well-tested… and barely used.

On paper, these tools are perfect. In reality, they fail.

Not because of bad code. But because of bad assumptions.

The Illusion of “If We Build It, They’ll Use It”

Developers often build internal tools the same way they build external products—focusing heavily on performance, architecture, and clean abstractions. But here’s the catch: internal tools aren’t judged by elegance. They’re judged by convenience.

If your tool saves 20% compute time but adds 2 extra steps to a developer’s workflow, it’s already lost.

People don’t adopt tools because they’re powerful. They adopt them because they’re easy.

The Real Enemy: Friction

Every extra click, every confusing config, every unclear error message—these are small cuts that slowly kill adoption.

A developer under deadline pressure won’t explore your perfectly documented tool. They’ll fall back to whatever works right now—even if it’s inefficient or outdated.

The truth is simple:
The best tool is the one that doesn’t feel like a tool.

Built Without the User in the Room

A common pattern: internal tools are designed in isolation.

Engineers imagine the workflow. They predict use cases. They optimize based on assumptions. But they rarely sit with the actual users—other developers—and watch how work really happens.

The result? A mismatch between design and reality.

Real workflows are messy. They involve shortcuts, hacks, and habits that don’t show up in documentation. If your tool ignores that, it won’t survive.

Over-Engineering Kills Adoption

Ironically, the more “perfect” the tech, the worse the adoption can be.

Why?

Because internal tools don’t need to be perfect. They need to be useful immediately. Over-engineering often introduces:

Complex setup processes
Steep learning curves
Too many features nobody asked for

A simple script that solves one problem today will beat a sophisticated platform that promises everything tomorrow.

No Ownership, No Evolution

Many internal tools launch with excitement… and then slowly decay.

No one owns them long-term. Feedback isn’t prioritized. Bugs pile up. Eventually, the tool becomes just another thing developers avoid.

Internal tools aren’t one-time projects. They’re products. And products need continuous care.

The Fix Isn’t Technical

You don’t fix this with better frameworks or faster systems.

You fix it by changing how you think:

Start with the developer’s workflow, not your architecture
Reduce friction obsessively
Ship small, useful improvements instead of big, perfect systems
Treat internal tools like products—with users, feedback, and iteration

Final Thought

The uncomfortable truth is this:

A technically perfect tool that nobody uses is a failure.
A slightly imperfect tool that everyone relies on is a success.

If you want your internal tools to survive, stop chasing perfection.

Start chasing adoption.

Code Reviews Are Not Therapy: How Over-Politeness is Destroying Technical Quality on Your Team

Om Keswani — Tue, 28 Apr 2026 18:11:17 +0000

We’ve all seen it.

A pull request with hundreds of changed lines gets approved with:

LGTM.

And somehow that counts as a review.

Weeks later, a bug shows up in production, and everyone wonders how nobody caught it earlier.

Often, the answer is simple:

People saw issues — they just didn’t want to sound too critical.

When Politeness Becomes Avoidance

Respectful communication is important. But many teams confuse respect with never challenging anything directly.

Comments become overly soft:

“Maybe we could possibly consider another approach…”

when what they really mean is:

This design has problems.

That kind of over-politeness turns important feedback into optional suggestions.

And optional suggestions are easy to ignore.

Good Reviews Need Friction

Great code reviews are not supposed to be effortless.

They should include questions like:

Why use this abstraction?
What happens under edge cases?
Does this create future maintenance pain?

That friction isn’t conflict.

It’s engineering.

Without it, reviews become typo checks instead of quality checks.

“LGTM” Isn’t Always a Review

Sometimes “Looks Good To Me” really means:

I skimmed it
I’m busy
I trust someone else reviewed deeply
I don’t want to start debate

That’s approval, not review.

And there’s a difference.

Direct Feedback Isn’t Rude

Strong feedback doesn’t need to sound harsh.

Instead of:

❌ This is bad design.

Try:

✅ This may couple concerns too tightly — can we rethink it?

Clear feedback improves code.

Vague feedback protects comfort.

Only one improves systems.

Final Thought

Code reviews were never meant to be therapy sessions where nobody risks discomfort.

They exist to challenge ideas and improve software.

Sometimes that means saying:

This shouldn’t merge yet.

And that’s not being difficult.

That’s doing a proper review.

Context-Switch Hangover: How Daily Interruptions Destroy Code Quality

Om Keswani — Mon, 20 Apr 2026 16:00:52 +0000

It’s 10:07 AM and you’re finally locked in.

Your editor is full screen, the bug is loaded in your head, and for once the whole system actually makes sense. You can see the fix, the refactor, the clean path forward.

Then Slack pops.

“Got a sec?”

You alt‑tab, type a quick reply, check one more notification while you’re there, and jump back to your code… only to stare at it like someone shuffled the puzzle pieces. What was that edge case again? Why is this function even here? You’ve just met context‑switch hangover.

The “Quick Question” That Quietly Costs 20 Minutes

Most interruptions are disguised as harmless:

“Quick one about that endpoint.”
“Can you just jump on a five‑minute call?”
“Mind checking this log real fast?”

But your brain isn’t switching tabs, it’s unloading one mental model and loading another. Studies on knowledge work and software engineering keep landing in the same range: it often takes around 15–25 minutes to fully regain focus after an interruption, even when the interruption itself is just a minute or two.

So that 30‑second Slack reply quietly rents 20 minutes of your attention. Do that 10–12 times a day and your “eight‑hour” workday contains only a handful of real deep‑work windows, sliced into pieces too small for hard problems.

You don’t feel the cost right away. You just feel slower, more easily annoyed, and weirdly tired for the amount of “actual” code you shipped.

How Your Code Gets Dumber (Even When You Don’t)

When you’re deep in a feature or bug, you’re holding a fragile model in your head: how data flows, which calls matter, where the failure might be. Every interruption pokes holes in that model.

Research on breaks and code quality shows that when developers are forced into frequent or long gaps, they forget key details about the codebase—intent, assumptions, edge cases—and that forgetfulness shows up later as defects and maintainability issues. Under heavy context switching, you’re more likely to:

Patch symptoms instead of fixing root causes.
Leave weird naming or inconsistent behavior because you re‑enter the problem mid‑thought.
Ship code that “works today” but quietly grows technical debt.

Teams that look at their own workflows often find a clear connection between constant interruptions, more bugs, and slower delivery—even though everyone feels maxed out all day.

It’s not that you suddenly forgot how to code. You’re trying to write production‑grade software while your brain keeps rebooting.

Why Your Day Feels Busy but Empty

Time‑tracking studies on developers show a pattern that will feel familiar: once you subtract meetings, chat, and context switches, the actual hands‑on, focused coding time often shrinks to just a few hours.

That’s how you end up going home with this strange mix of:

“I worked non‑stop,” and
“I didn’t really do anything.”

It’s easy to internalize that as “I’m slow” or “my focus is terrible,” but research on developer productivity and burnout keeps naming interruptions and fragmented days as major culprits. The system you’re working in is hostile to deep work by default.

Shrinking the Hangover (Without Being That Developer)

You probably can’t fix your company’s culture this week, but you can make your own day less brutal. A few things that actually help in real teams:

1. Batch your replies instead of living in Slack.

Pick two or three specific times to clear messages—say 11:30 and 4:00—and let non‑urgent pings stack up until then. You’re turning a dozen tiny context switches into a couple of intentional ones.

2. Make focus time visible, not secret.

Block “deep work” on your calendar and set a clear status like “Heads down on checkout bug, checking Slack at 11:30/4:00.” Teams that normalize visible focus time tend to interrupt less and respect those blocks more.

3. Group similar work together.

If you’re doing feature work, triage, and interviews, try not to mix them every hour. Reviewing three PRs in a row is cheaper for your brain than bouncing between a PR, an incident call, and a totally different codebase.

4. Leave breadcrumbs for future you.

Interruptions will happen. Before you switch, take 20 seconds to write a one‑line “NEXT:” note in your editor or scratchpad, and when you return, re‑read the last few lines and that note before typing anything. Even simple re‑entry rituals help you rebuild context faster and avoid mistakes.

You’re never going to have a perfectly interruption‑free job as a developer. There will always be pings, “quick” calls, and surprise fires.

But you don’t have to accept a workday that guarantees a context‑switch hangover. Protect a couple of real focus blocks, batch the noise, and leave better breadcrumbs for yourself.

The work you’re proudest of—the elegant refactor, the bug you finally crushed, the design that just clicks—almost always comes from those rare quiet stretches where nobody bothers you. The more you create those on purpose, the more your day starts to feel like engineering again, not just endless tab‑switching with a side of code.

Onboarding Hell: 30 Days in a Broken Dev Environment

Om Keswani — Mon, 13 Apr 2026 16:43:19 +0000

On my first day on this team, the code compiled before I did.

The laptop arrived, the Slack pings started, and then reality hit: no onboarding doc, no setup guide, just a half-joking “shout if you get stuck” in a crowded channel. Within hours, I was deep in dependency hell, trying to piece together a working dev environment from half-remembered comments and year-old threads.

By the end of week one, I’d written exactly zero meaningful lines of product code. I had, however, cloned five repos, broken three local databases, and learned that “it works on my machine” is apparently an approved troubleshooting strategy. And the worst part? This isn’t rare. Many companies effectively accept that a new engineer will spend weeks just figuring out where things are instead of building anything useful.

Day 1–7: Fighting the Environment, Not the Problem

In a healthy team, your first week is about understanding the product, the architecture, and the people. Here, it was about understanding why nothing worked the same way twice. The official “setup guide” was a stale README, last updated three CTOs ago. Half the scripts referenced services nobody could explain. One command casually dropped the entire local database if you ran it with the wrong flag.

Most days started the same way: pull latest, run the bootstrap script, hit an error, paste it into chat, wait. Senior devs would answer in shorthand or point to yet another internal link that assumed you already knew how everything fit together. It wasn’t that people were hostile; they were just too busy shipping to step back and notice how much time and morale the broken onboarding was burning. Research suggests new developers can spend a huge chunk of their first months just wrestling with their environment instead of writing code, and I was living proof.

Zero Documentation, Maximum Guesswork

No documentation doesn’t mean “no information.” It means the information lives in people’s heads, private Slack DMs, and random Notion pages you only discover by accident. Every question felt like a mini investigation: who owns this service, where is the config, why are there three versions of the same API spec?

The unspoken onboarding process was “just ask,” which sounds friendly but actually shifts all the burden onto the new person. You don’t know what you don’t know. You don’t want to spam senior engineers. You don’t know which answers are tribal hacks and which are actual standards. This kind of unstructured, undocumented onboarding is a hidden tax: juniors feel lost, seniors burn time repeating the same explanations, and the team as a whole moves slower than anyone realizes.

What documentation did exist was often worse than nothing: outdated, contradicting reality, or full of “TBD” sections that were clearly never revisited. Outdated docs don’t just fail to help; they actively create confusion and erode trust. Once you’ve been burned a couple of times, you stop believing any doc you see and fall back to “just ask,” which is how teams get stuck in a perpetual cycle of interruptions and re-explaining.

The Psychological Side: From Excited to Invisible

There’s also a quieter cost. You join excited to contribute, to prove the hiring process wasn’t a mistake. After a couple of weeks of being blocked by missing access, broken scripts, and conflicting instructions, that excitement turns into embarrassment and doubt. You start apologizing for asking “too many” questions, even though the real problem is the system, not you.

Poor onboarding is one of those things leaders underestimate until they see the retention numbers. When your first few weeks are defined by confusion and chaos, it’s easy to mentally check out or start quietly browsing job boards. Studies and industry reports keep pointing out that ineffective onboarding is tightly linked to slower time to productivity, disengagement, and early turnover—sometimes within the first 45 days.

How I Learned to Survive the First 30 Days

I wish I could say the solution came from some grand organizational fix, but it didn’t. It started with a mindset shift: if the system is broken, treat survival as a project. The goal for my first month stopped being “be fully productive” and became “reduce confusion for future me.”

Here are the tactics that actually helped:

Create your own mini playbook. Every time I figured something out—how to run a subset of tests, how to seed local data, which repo owned which endpoint—I wrote it down in one place. Not in ten stickies, not in random notes, but in a living doc I could search and share.
Default to over-communication. Instead of silently struggling, I started posting short daily updates: what I tried, what broke, what I think is blocking me. This turned “random questions” into a visible pattern of friction that my lead could actually act on.
Anchor on one real task. The turning point was getting a small, end-to-end task: a tiny bug fix that touched the front end, an API, and a database migration. That one task gave me a realistic path through the system that no diagram ever could. A lot of onboarding guides now explicitly recommend giving new devs small, meaningful tasks instead of vague “explore the codebase” homework, and I understand why.
Find a “shadow mentor,” even if it’s unofficial. There’s always that one engineer who knows where the skeletons are buried and doesn’t mind screen-sharing for 15 minutes. I leaned on that person more deliberately—respecting their time, but also recognizing that those sessions were worth more than another day of blind stumbling.

If You’re a Dev Walking Into This

If you’re about to join a team with a shaky onboarding process, go in with your eyes open. Assume the docs are incomplete. Assume the setup scripts lie. Don’t take it personally when you feel slow; you’re operating with missing context. Measure your progress not by how much code you merge in week one, but by how much invisible map you’re building: which services matter, who owns what, where truth actually lives.

And whenever you fix something confusing—whether it’s a broken command in the README or a missing step in an environment setup—leave the campsite a bit cleaner than you found it. Update the doc, add the comment, write the script. It feels small, but this is how onboarding debt gets paid down: one frustrated developer deciding that the next person should suffer a little less than they did.

The irony of onboarding hell is that the people who feel its pain most acutely are the ones with the least power on day one. But if enough of us treat those first 30 days as an opportunity to document, to surface friction, and to insist on better, we slowly turn “this is just how it is” into “how did we ever tolerate that?”

The Six-Month Onboarding Lie: Why Most Teams Never Really Let New Developers Join the Real Work

Om Keswani — Sat, 28 Mar 2026 12:35:43 +0000

There’s a quiet lie a lot of engineering teams tell themselves:

“Onboarding takes six months. That’s just how it is.”

On paper, it sounds reasonable. Plenty of HR articles say it takes anywhere from a few months up to a year for a new hire to reach “full productivity,” especially in complex or technical roles. Six months feels like a safe middle number.

But in day‑to‑day reality, that “six months” line often turns into something more dangerous: an excuse. It’s a way to justify new developers spending half a year orbiting the real work without ever being pulled into the actual core of the team.

That’s not an onboarding problem. It’s a trust, ownership, and culture problem.

The Myth of “Full Productivity”

Most companies treat “time to full productivity” as a vague HR metric instead of a concrete engineering responsibility. You hear the same phrases everywhere:

“It takes 3–6 months to ramp up in a complex codebase.”
“You can’t expect real impact before the first performance cycle.”
“They’re still onboarding; let’s not give them anything risky yet.”

Underneath that language is a more honest translation:

We haven’t done the work to make our systems understandable.
We haven’t designed starter problems that actually matter.
We don’t know how to safely put a new engineer in the path of real impact.

So we package all of that up and call it “onboarding.”

Because other teams do it too, it feels normal. If your last company took months to let you ship a meaningful feature, a slow ramp at the next place just feels like “how the industry works.” But “industry average” is not the same thing as “healthy.”

The Fake Work We Give New Developers

When a team doesn’t know how to let new people touch the real system, it creates fake work that looks productive but doesn’t move anything that matters.

You’ve probably seen some of these patterns:

1. “Starter” tickets that don’t matter

Tiny UI text changes, dead‑code cleanup, or toggling a config flag no customer will ever notice. Great for day one, unacceptable for week eight.

2. Shadowing as a permanent state

The new hire “shadows” seniors in meetings, calls, and incident reviews — but never actually owns a decision, a commit, or a slice of the system.

3. Endless environment and permissions hell

Weeks disappear into VPN issues, missing access, and half‑documented local setup. All of this time quietly gets filed under “onboarding,” even though most of it is preventable with a bit of upfront work.

4. Documentation scavenger hunt

There’s no learning path. Just a graveyard of Notion pages and Confluence docs. The new engineer is told to “read the docs and ping if anything’s unclear,” which usually translates to “wander around and good luck.”

Each of these, on its own, sounds defensible. Taken together, they mean that by month three a “new” developer’s Git history is still mostly chores and drive‑by fixes, not real features or decisions.

Why Teams Don’t Let New Devs Touch Core Systems

It’s tempting to blame complexity: “Our domain is hard,” “Our stack is old,” “We’re in a regulated industry.” Those things might be true, but they’re rarely the root cause.

Underneath, you usually find a mix of:

Fear of outages

The senior folks know exactly how fragile the core system is. Letting a new person in feels risky, so they keep the “real” work in a tiny inner circle.

No safety rails

There’s no staging environment that behaves like production, the test suite is flaky or barely exists, and observability is weak. In that world, giving anyone new real responsibility isn’t just scary — it’s reckless.

Hero culture

A few “indispensable” engineers carry most of the context. They’re always firefighting and never have time to turn their knowledge into something reusable or design work that’s safe for newcomers.

Lazy management narratives

It’s easier to say “onboarding just takes six months here” than to admit “we don’t know how to expose core systems without blowing things up.”

So the compromise becomes: keep new developers close enough to feel busy, but far enough away that nothing can really break.

From the outside, it still looks like progress — there are standups, tickets, and commits. From the inside, the new hire can tell they’re not actually part of the engine yet.

The Psychological Damage of Perpetual Onboarding

Staying in “not quite trusted yet” mode for months quietly wrecks people.

For the new developer:

Imposter syndrome deepens.

If you’re still not allowed near core paths after three months, you don’t think “this system is badly structured.” You think “I must not be good enough.”
Initiative gets punished in slow motion.

You suggest taking on deeper work and repeatedly hear, “maybe later, once you’re more familiar.” Eventually you stop asking.
Your growth curve flattens early.

Real growth comes from owning risk: designing features, handling incidents, making tradeoffs. If you’re shielded from that, you stagnate.

For the team:

“Long onboarding” becomes part of the culture.

New hires are told to expect a slow start. Nobody feels personally responsible for changing that.
Senior devs stay permanently overloaded.

Because new people never get true ownership, the same two or three names end up on every critical path project, every incident, every migration.

The end state is boringly predictable: seniors burn out, new devs disengage, and leadership wonders why velocity feels terrible even though headcount has gone up.

The Six-Month Excuse vs. a Real Onboarding Target

Here’s the uncomfortable bit:

You don’t need six months for a developer to contribute to real work.

You might need six months (or more) for them to fully master the system — but that’s a different conversation.

High‑functioning teams separate these two ideas.

They aim for milestones like:

Within the first week

The new engineer has a real commit merged that touches user‑visible behavior or production code paths — protected by tests, review, and guard rails.
Within the first month

They own a small but meaningful slice of functionality: a feature, a workflow, one service endpoint, something they’re clearly responsible for.
Within the first three months

They’re participating in incidents, architecture discussions, or cross‑team projects, not as silent observers but as contributors.

Notice what’s missing: “Wait six months before they touch anything important.”

When research talks about 3–9 months or even longer to reach “full productivity,” it’s describing the time to reach peak effectiveness, not a justification to keep people on the sidelines for half a year.

How to Let New Developers Join the Real Work (Without Burning Everything Down)

If you’re a senior engineer or a manager, this is the part you actually control. The goal isn’t “onboard faster” in the abstract; it’s “create safe ways for new people to do meaningful work quickly.”

Here are a few practical moves.

1. Design a real “first feature” on purpose

Don’t just throw a random bug at the new hire.

Pick a change that touches real code paths but is easy to roll back.
Make sure there are tests in place — or take the opportunity to add them.
Pair on the design, then let them drive the implementation and the PR.

The milestone isn’t “they merged something.” It’s “they experienced the whole loop: spec → code → review → deploy → feedback.”

2. Expose them to risk, but with guard rails

Instead of hiding new developers from dangerous parts of the system, make those parts safer.

Invest in staging environments that behave like production.
Strengthen automated tests around core flows.
Use feature flags and solid rollback plans so mistakes are survivable.

You’re not just improving onboarding; you’re hardening the entire system.

3. Give them a meaningful area of ownership early

By month one or two, a new engineer should own something you’d absolutely notice if it broke:

A small service.
A specific API endpoint and its SLOs.
A feature flag they are responsible for sunsetting.

Ownership is what turns “I’m new here” into “I’m accountable for this.”

4. Turn tribal knowledge into a product

If the only way to learn is “grab 30 minutes with Alice,” you are guaranteeing long ramp times.

Instead:

Turn repeated questions into docs, runbooks, or short internal videos.
Record incident reviews and architecture walkthroughs, then index them somewhere easy to search.
Build a simple, opinionated “start here” path: what to read, in what order, and why it matters.

Every time a new hire has to dig through old Slack threads for basic context, you pay the onboarding tax again.

If You’re the New Developer Stuck in the Six-Month Lie

Sometimes you’re not the one with formal power to change the system. You still have options.

Push for real work early.

Ask: “What’s a small but real piece of functionality I can own end‑to‑end this month?” That question alone forces your lead to think beyond cosmetic tickets.
Shadow with intent, not passively.

When you sit in incident calls or design reviews, map systems, write things down, and follow up with specific questions. Turn what you see into your own documentation.
Trace tickets to outcomes.

Before you pick something up, ask who cares about it and how they’ll know it worked. If nobody can answer, there’s a good chance you’re being handed busywork.
Measure your own ramp.

Note when you first ship something real, when you first help resolve an incident, when you first make a design call. Those moments say more about your growth than any “onboarding complete” date.

You may not be able to fix the culture alone, but you can refuse to let it define your sense of competence.

The Lie Only Survives If We Let It

Saying “onboarding takes six months here” is easy. It sounds mature, professional, and especially reasonable in complex domains.

But if, six months in, your new engineers:

still haven’t owned a feature,
still aren’t in the rotation for serious work, and
still don’t feel trusted around core systems,

that’s not onboarding. That’s institutionalized underutilization.

The teams that win over the long term won’t be the ones with the fanciest onboarding slide decks. They’ll be the ones that treat new developers as real engineers from week one — and build systems, processes, and culture that are safe and robust enough to make that trust real.

What Code Reviews Really Measure — And Why Your Best Engineers Hate Them

Om Keswani — Mon, 16 Mar 2026 14:09:25 +0000

Riya opened her laptop to a wall of red badges: seventeen pull requests waiting for her review.

She was the staff engineer everyone trusted with “the important stuff,” which meant every risky change, every migration, every cross‑team integration had her name on it. Somewhere under that pile was the design doc she actually wanted to work on. She sighed and clicked the first PR anyway.

It was a 900‑line diff. The description said only: “Fix stuff, please review.”

Riya skimmed. The change touched a payment flow she’d helped design two years ago. There were branching conditionals stacked on top of already‑messy logic, a couple of “just in case” flags, and a new helper with a name that meant nothing.

She knew what this really needed: to be split into three smaller changes, with a conversation about the underlying assumptions. That would take a few hours. The dashboard on the TV outside, though, only cared that “Time to First Review” stayed low.

“Okay,” she muttered. “Nits it is.”

Two comments on naming. One suggestion for extracting a method. A question about a null check. She hit “Approve,” closed the tab, and opened the next PR.

By the time she got to number five, the patterns were obvious. Huge PRs from rushed teammates. Vague descriptions. Review comments from others fixated on indentation, brace style, and whether a map should be called data or items. Nobody was asking, “Is this the right thing to build?” or “Are we about to make this system harder to change for the next five years?”

It wasn’t that no one cared. It was that the whole system pushed them away from caring. Leaders watched graphs of review speed and PR throughput. Devs optimized for whatever kept those graphs happy. Plenty of teams had quietly discovered that code review, done badly, was now the slowest, most frustrating part of shipping features.

Later that afternoon, a junior engineer, Aarav, pinged her.

“Hey Riya, any chance you can look at my PR? It’s been stuck a while.”

She opened it. Another big change. Aarav had threaded a new feature into a part of the codebase everyone avoided.

“Why so big?” she asked in the comments.

He replied almost immediately.

“Last time I split it up, it took three times as long to get merged. People kept asking for ‘the full picture.’ Figured I’d just send one big thing and get it over with.”

There it was, in writing: the survival strategy the team had taught him. Don’t take risks. Don’t touch scary code unless you can sneak the change in once. Don’t argue style. Don’t propose bolder refactors. Just get past the reviewers.

For a moment, Riya thought about just doing what everyone else did: pick a few safe comments, ask him to rename a function, and move on. Instead, she DM’d him.

“Walk me through what you’re trying to do. No IDE. Just talk.”

They jumped on a call. Twenty minutes later, they had sketched a much smaller first step: one refactor to untangle the worst part of the flow, behind a feature flag. A second PR could layer the new feature on top. A third could clean up the old code path once they were confident.

“That sounds… nicer,” Aarav said. “I didn’t know we were allowed to do that.”

“Allowed?” Riya laughed. “We should be begging people to do that.”

After the call, she stared at the endless PR list again. It wasn’t just the code that needed refactoring. It was the whole way they were treating review.

The next week, at their engineering sync, she told a story instead of showing another metric chart.

She described her average day: the flood of notifications, the pressure to be “fast,” the feeling of signing off on changes she hadn’t had the time to truly understand. She told the Aarav story—how he’d learned to send huge PRs because “that’s what gets merged here.” She admitted she’d started avoiding the hardest reviews because they meant conflict, long threads, and no visible credit.

Then she asked a simple question: “If we looked only at our review data, what would we think we care about? And does that match what we say we care about?”

Silence, then a few nods. Someone joked about “the sacred graph of PR cycle time,” but nobody defended it too hard.

They made three small changes that day.

First, they agreed on a “normal” PR size and wrote it down. Anything far bigger needed a clear reason in the description. Second, they set an expectation that every author would answer four questions in their PR: what problem this solved, why this approach, what the trade‑offs were, and what reviewers should focus on. Third, they decided that style nits belonged to linters and formatters, not humans, and spent an afternoon tightening their tooling.

None of this was revolutionary. There was no shiny new platform, no AI assistant promising to review their code for them. But within a couple of weeks, Riya noticed that her review queue felt different. PRs were smaller. Descriptions were clearer. She could say “no” to being tagged on everything and still feel the team was safe.

The work was still there. Some days her notifications still exploded. There were still awkward conversations and disagreements. But reviews felt less like a political stage and more like the conversation they were supposed to be: a few people, looking at a small slice of change, trying to leave the code a little better than they found it.

One evening, as she closed the last PR of the day, Riya caught herself thinking something she hadn’t felt in a long time.

“This one was actually fun.”

The Hidden Cost of ‘Clean Code’: When Over-Engineering Quietly Kills Shipping Velocity

Om Keswani — Tue, 03 Mar 2026 17:01:00 +0000

Every engineer has been there. You see a function that’s a little messy, a class that’s a bit bloated, and the instinct kicks in: rewrite, refactor, generalize. The goal is “clean code,” but the side effect is often weeks of over‑engineered abstractions that barely ship, or worse, ship too late to matter.

What “Clean Code” Usually Becomes

“Clean code” is usually sold as readable, maintainable, and well‑structured. In practice, it often turns into layers of abstraction so generic they’re hard to follow, premature optimizations that nobody benchmarked, and a separation of concerns so stretched that a small change ripples across ten files instead of one.

When every small change needs a new interface, a new decorator, and a new configuration object, what you really have is not lean code, just more code with a shiny label.

How Over‑Engineering Slows Shipping

Shipping velocity is the gap between decision and delivery. Over‑engineering quietly compresses that gap through:

Longer review cycles because the diff is sprawling and the intent is buried under patterns.
Higher bus‑factor stress because no one understands the “elegant” solution except the original author.
Fear of touching working code because the mental model is too heavy to navigate.

The result is a codebase that looks great in architecture diagrams but feels painful to ship anything meaningful in.

The Trade‑Off No One Talks About

The tension is real: you want code that will last, but you also need a product that ships. The over‑engineering trap is believing those goals are mutually exclusive when they’re actually a spectrum.

Useful questions to ask instead of defaulting to “let’s design this perfectly”:

Will this abstraction ever be reused in practice, or is it a one‑off?
If we shipped this without the pattern, how much worse will maintenance be in six months?
Who exactly will thank us for this extra layer a year from now?

Many of the patterns we add are for imagined future maintainers, not the people who are actually shipping features today.

“Clean Code” Anti‑Patterns Worth Naming

Common symptoms that your “clean code” efforts are really over‑engineering:

Creating a microservice for a workflow that clearly belongs in a single bounded context.
Adding a full‑blown state‑management layer for a page that will never grow beyond a few components.
Building a plugin system for a feature that will never have more than one consumer.

These are not inherently wrong, but they become over‑engineering when they precede actual evidence of need.

A More Pragmatic Way to Write Code

Staying pragmatic does not mean writing spaghetti. It means deliberately compromising on “perfect” architecture when the payoff is uncertain. Useful habits:

Start stupid. Solve the immediate problem in the simplest reasonable way.
Embrace small, local refactorings. Improve code as you touch it, not as a big upfront project.
Measure the cost. Track how long PRs take, how often they get stuck, and whether abstractions are actually reused.

A codebase that evolves iteratively is often more maintainable than one that is “perfectly cleaned up” but never shipped.

Reframing “Clean Code” as Team Leverage

The real metric of “clean code” is not how many design patterns it uses, but how easily your team can ship new value on top of it. Clean code is code that:

New teammates can reason about with minimal context.
Allows changes without a cascade of unrelated tests and constants.
Does not require a ceremony review of five diagrams before anyone can touch it.

When your abstractions actively reduce the cognitive load of shipping, they earn their place. When they only make the codebook look more impressive, they should be questioned.

Wrapping Up

“Clean code” is a useful compass, not a destination. The hidden cost of over‑engineering is that it slows down the very thing it was meant to protect: maintainability over time.

By treating some of our favorite patterns as hypotheses instead of defaults, and by measuring the real‑world impact on shipping velocity, we can keep code clean in a way that actually serves the product, not just our own sense of craftsmanship.

The Partial Rewrite Trap: When Management Says "Refactor" But Means "Rewrite in Disguise"

Om Keswani — Wed, 18 Feb 2026 15:32:17 +0000

Picture this: Your codebase is a 10-year-old dumpster fire. Deploys crawl at snail pace, bugs lurk in every corner, and every feature add feels like defusing a bomb blindfolded. You stand up in the all-hands, slides gleaming: "We need a rewrite." Management leans in, nods sagely: "Smart. Modernize it. Refactor strategically."

Translation? No fat budget. No six-month war chest. Just "chip away incrementally" while pretending it's not a full gut job. Boom—you're in the Partial Rewrite Trap. The silent team-killer where hope rises with each commit, then crashes in dependency hell. I've escaped it twice. Here's the unvarnished playbook to spot it, dodge the burnout, and hijack it for a win.

The Trap Snaps Shut: Spot the Warning Shots

It creeps up sly. "Just clean this one service," they say. Next sprint? That service touches everything. Red flags screaming:

"Low-risk tweaks" that spawn 10x the tickets.
Zero QA breathing room—you're prod-testing by stealth.
Metrics chasing refactored LOC, ignoring real wins like sub-100ms APIs.

Worst part? The gaslighting. You eviscerate the payment engine but standup-speak: "Optimized transactions." Team's fried, demoing crumbs while PMs howl for dashboards. Three months deep, you're 10% through and questioning your life choices.

Survival Mode: Build Your Lifeboat Now

Don't drown quietly. Weapon one: Debt Ledger. Hack a Google Sheet or Notion dashboard. Log every slash: "Auth latency: 1.2s → 180ms. Errors: 4% → 0.2%." Screenshots, graphs. When timelines skid, flash it: "Look, we're delivering."

Tactic two: Strangler Fig on Steroids. Encapsulate legacy turds in thin wrappers. Yank services out surgically. Feature flags gate everything. Test slices via Lambda shadows or K8s blue-green deploys. Day one? Bake in rollback scripts. Execs drool over "risk-free."

Time shield: Demand Debt Fridays—one day per sprint, locked to KPIs like "halve P0 alerts." Resistance? Hit 'em: "Last outage cost $8k/hour. This pays for itself."

Hijack the Wheel: Turn Trap into Triumph

Stop groveling—sell it. Ditch "refactor." Call it Progressive Migration: "New beast grows beside the corpse. Traffic flips module-by-module." Arm yourself with dashboards: Queries 3x faster. Tickets crushed 60%. Data slays doubt.

Seal the deal with a Migration Metro Map. Sketch it like subway lines: Stop 1 (Auth Overhaul), Stop 3 (Payments Pivot), Grand Central (Cutover). Owners named, dates etched, gates brutal: "80% traffic shifted or we halt." Vague vibes die; accountability reigns.

Team fuel: Kill Club Fridays—10 mins, devs nominate next victims. Rotate "Module Assassins" for ownership without burnout. Slack RIP posts: "2008 JSON parser: yeeted to /dev/null. 🎉" (Okay, one emoji for morale.)

Trench Warfare Truths: What They Don't Teach at Conferences

Unpopular? Partial rewrites crush Big Bangs 8/10 times. Full rewrites tank 70% on scope vomit; increments let you course-correct live. One crew I knew nuked 5-hour deploys to 8 minutes—zero "rewrite" uttered, pure stealth victory.

Dark side: Sunk cost black hole. 6 months in, <25% migrated? Torch it. Fork the half-new mess to cold storage. Pitch hard numbers: "$250k/year dual-code drag vs. $400k clean rewrite." Dollars > denial.

Level Up or Get Stuck Forever

This trap doesn't just test code— it forges street-smart leaders. Conquer it, you're the wizard who alchemized sludge into silk. Flub it, you're the eternal janitor of two codebases.

Next "R-word" ban? Grab the reins. Ledger it. Flag it. Migrate it. Steer hard right—your career (and sleep) thanks you.

Your ugliest refactor war story? Vent below. I devour 'em.

The Hidden Career Trap of Becoming Your Team’s ‘Human Abstraction Layer’ (and How to Escape It)

Om Keswani — Thu, 12 Feb 2026 16:50:25 +0000

You've probably been there. A complex legacy system needs a tweak. Everyone turns to you because "you just know how it works." At first, it's flattering. Then it becomes your prison.

This is the Human Abstraction Layer trap. You're not just a developer—you're the living API docs, mental model, and tribal knowledge repository for spaghetti code no one else understands. Your team moves fast because of you, but you're stuck in neutral.

Spotting the Trap Early

It starts innocently. A quick Slack ping: "Hey, how does auth flow through the monolith again?" You explain. Then it's daily rituals—debugging obscure bugs, translating business logic from 2018 commits, or fielding questions on why that one endpoint flakes under load.

Signs you're the HAL:

Your calendar fills with 15-minute "quick questions" that stretch to hours.
Onboarding new hires? They shadow you for weeks.
Deployments halt if you're on PTO. Literally.

I fell into this at a fintech startup. Our Ruby on Rails app had grown tentacles into microservices nobody owned. I became the guy who could trace a payment failure from frontend to Kafka without blinking. Velocity spiked short-term, but my growth stalled.

Why It Kills Your Career

Teams love a HAL—it's cheaper than refactoring. But for you:

No high-impact work: You're firefighting, not architecting.
Burnout accelerator: Cognitive load rivals air traffic control.
Promotion black hole: Managers see you as "irreplaceable infrastructure," not leadership material.
Skill atrophy: You're expert in yesterday's mess, not tomorrow's tech.

Data backs this. Studies like those from GitClear show "bus factor 1" teams crumble under attrition. But the real pain is personal: I once spent a sprint untangling a 5k-line class because "you're the only one who gets it." Meanwhile, peers shipped ML features and got promoted.

Unpopular opinion: This trap is often self-inflicted. Saying "yes" to every rescue cements your role. Teams exploit it because it works—until you leave.

The Escape Blueprint

Breaking free requires strategy, not heroism. Here's the playbook I used to claw out.

1. Document Ruthlessly, Then Delegate

Don't hoard knowledge—weaponize it. Create living docs:

Mental model maps: Draw the system's data flow in Excalidraw. Pin it in Slack.
Runbooks for pain points: "Payment retry logic? See docs/retry-flow.md."
Pair with juniors: Turn "ask me" into "teach them."

I spent two weeks on a "Monolith Survival Guide." Usage spiked; my interruptions dropped 60%.

2. Force Ownership Rotation

Propose a "tech debt tax": Every sprint, two engineers must pair on a legacy module. Rotate strictly.

Pitch it as risk mitigation: "What if I'm hit by a bus?"
Use it to nominate successors: "Alex crushed auth last rotation—let them own it."

This distributed the load without big rewrites.

3. Refactor with Surgical Precision

Target the hotspots. Not the whole mess—just the 20% causing 80% pain.

Strangling: Wrap legacy in thin adapters. New code calls the wrapper.
Metrics first: Flame graphs or strace to prove the debt's cost.
Celebrate wins: "Deployed without me—team velocity +15%."

My escape project: Extract auth to a gRPC service. Took a month, but now it's self-serve.

Escape Tactic	Effort Level	Impact
Living Docs	Low	High
Ownership Rotation	Medium	High
Surgical Refactors	High	Highest

4. Reset Expectations Upward

Talk to your manager: "I'm bottlenecking innovation. Let's fund debt reduction so I can lead greenfield work."
Frame it business-first: velocity, retention, scalability.

If ignored? Polish your resume. HALs are common in stagnant orgs.

Life After Escape

Six months post-escape, I led a greenfield service in Go. Promotions followed. The old monolith? Still kicking, but with three "me's" maintaining it.

The trap feels heroic until it isn't. You're not a cog—you're the engineer who builds freedom for the team, including yourself. Spot it, map it, kill it.

Next time someone pings "quick question," reply with a doc link. Watch the layers peel away.

Why Your Senior Developers Leave (And Why They Never Come Back)

Om Keswani — Mon, 02 Feb 2026 16:20:21 +0000

Hey folks, let's talk about something I've seen way too many times: why your best senior developers just... ghost you. And not just leave, but never look back, no matter how much you beg or throw money at them. I've been there—worked with these wizards who could untangle any mess, then poof, gone. It's not the paycheck. It's deeper. Let me break it down like we're grabbing coffee.

That Quiet Breaking Point

Juniors burn out loud, right? "This bug sucks!" Seniors? They just hit a wall nobody notices. They've already crushed the learning curve. What grinds them down is the endless crap: digging through decade-old spaghetti code, back-to-back meetings that kill their flow, and bosses treating big-picture architecture like a post-it note.

Picture this: guy at my old fintech spot spends half a year ripping apart a payments monster just to let the feature team breathe. Crickets on the praise. Next week? Same drill elsewhere. He bounces to a chill consultancy. CTO calls with fat raise? Nah, I'm good. Trust's busted.

Ownership That's Not Ownership

We slap "ownership" on seniors like it's a gift. Nah. Real ownership is deciding what dies, what scales, and having the muscle to make it happen. Instead, they get to say "no" without power, dream big without buy-in, and watch juniors pile up because nobody built leverage.

They want systems that run without them babysitting. You give 'em more juniors to wrangle. They see the trap: forever in maintenance hell. Door slams.

What They Crave	The Trap You Spring
Build once, scale forever	Fix it every sprint, hero
Shape the product vision	Chase Jira tickets
Delegate without drama	Everyone lines up for your rubber stamp
Bets on the long game	EOW ship-or-die panics

Burnout Hits Different

Junior burnout: flashy frustration. Senior style: silent killer. Every outage they called out months ago? Internal scar. Tech debt they flagged years back? Now it's their fault. It festers.

And context-switching? Brutal. Seniors need big blocks of deep thinking to architect properly. But standups, "quick" reviews, fires everywhere—day's shredded. They lose half their output, easy. They dip not to nap, but to get their brain back.

Craft Gets No Respect

They stick around for the work itself. When you trash it, they're out:

Endless meetings > actual coding.
Junk local setups and busted pipelines.
Promotions that sound fancy but mean squat.
Mentoring every team while shipping their own load.

Exit interview: "Great opportunity elsewhere." Real talk: "You quit caring about my superpowers."

Why No Boomerang?

Give juniors cash, they bite. Seniors? They've reset their life. Coming back means same BS, different day. Why swap peace for stock promises when freelance pays double, half the headache?

The ones who dip and return? Short-term chaos like layoffs. Your baked-in dysfunction? That's a forever no.

Fix It for Real

Raises won't cut it. Build stuff they respect:

Ring-fence time for refactoring the rot.
No-meeting days, async everything.
Let 'em axe projects, build teams, own roadmaps.
Advisory gigs when they wanna step back.

Your seniors spot the iceberg from miles out. Let 'em slip away quiet, and you're stuck with juniors paddling toward it. They'll cheer you from afar—building cooler stuff at saner shops. Don't sleep on this.

Why You’re Burning Out From Shipping (Not the Code You Love)

Om Keswani — Sun, 25 Jan 2026 14:02:40 +0000

You remember that flow state—the one where hours disappear into clean commits and elegant abstractions.

The joy of solving a hard problem, the quiet confidence of tests passing.

Now contrast that with a 2 AM PagerDuty alert ripping you out of sleep.

Developers don’t burn out from coding.

They burn out from shipping inside a chaos factory.

The Friday 5 PM Release Roulette

The feature is solid.

Tests are green.

CI is smiling.

Then reality shows up.

Staging falls over. QA finds an edge case no one imagined.

A harmless-looking dependency update detonates prod preview.

Suddenly it’s hour five of “just one more fix” while stakeholders hover, refreshing Slack like hawks.

This isn’t coding fatigue.

It’s the chaos tax—the cognitive overload of debugging under time pressure, uncertainty, and visibility.

Teams spend 3× more mental energy managing broken releases than building features in the first place.

On-Call: The Invisible Ball and Chain

You ship.

You celebrate.

Then the leash snaps tight.

Every deploy carries a silent question:

Will this one wake me up tonight?

On-call developers lose up to 25% of deep sleep per week, turning success into anxiety and pride into paranoia.

The code was fun.

The waiting is what breaks you.

Tech Debt: Your Own Frankenstein Monster

That “quick hack” to hit the deadline?

It never died.

Now builds take 45 minutes instead of 2.

Hotfixes trigger regressions.

Fixing one bug births three more.

Each release feels like punishment for past decisions made under pressure.

Shipping becomes rework theater—motion without progress, effort without satisfaction.

You’re not moving forward; you’re paying interest on yesterday’s shortcuts.

Escape the Grind — Ship Like You Mean It

Burnout isn’t inevitable.

Bad shipping habits are.

Automate ruthlessly: canary deploys, feature flags, one-click rollbacks
Kill release roulette: Wednesday ships only—no weekend heroics
Respect on-call: rotate fairly, limit blast radius, pay back sleep debt
Track what matters: celebrate cycle-time drops like major code wins

Smooth shipping restores joy to development.

When releases stop feeling like gambles, coding becomes creative again—and keystrokes regain their meaning.

Ship calmly.

Ship deliberately.

Ship like you actually want to be here tomorrow.