DEV Community: Om Keswani

The "Let's Take This Offline" Trap

Om Keswani — Sat, 27 Jun 2026 12:10:04 +0000

It was a Wednesday morning standup, the kind where everyone's camera is on but nobody really wants to be there. Maya, our backend lead, mentioned she was blocked on the payment service schema. She'd posted a proposal doc five days ago. Twelve comments. Four emoji reactions. No decision.

"Let's take this offline," our engineering manager said, with the practiced ease of someone who'd said it a hundred times. "We don't need to solve it here."

Maya nodded. I nodded. The standup ended thirty seconds early. Progress.

Except there was no progress.

Over the next week, the doc grew like something feral. Fifteen comments became thirty. Someone added a "TL;DR" that was itself too long to read. Someone else proposed a completely different approach in the margin of comment seventeen, and nobody acknowledged it. The thread didn't converge. It branched, tangled, and then went quiet. The last comment was a thumbs-up emoji from Dan, our staff engineer, posted at 11:47 PM on a Friday. We all interpreted it as agreement. Maya later told me she interpreted it as exhaustion.

Two sprints later, the schema still wasn't decided. We were coding against a temporary interface that someone had built "just to unblock things" and that temporary interface was now serving real customers. The payment service had no official owner. The decision hadn't been postponed. It had evaporated.

I remember sitting with Maya after an incident review—something had broken because the temporary schema didn't handle edge cases—and she said, quietly, "I don't even know who's supposed to decide anymore. Everybody's too polite to just say 'this is what we're doing.'" She wasn't angry. She sounded defeated.

That was the moment I understood what we'd built. Our team wasn't async-first. We were conflict-avoidant wearing the costume of good process. The docs, the threads, the carefully worded Slack messages—they weren't making decisions easier. They were making it possible to never make one at all.

The fix wasn't what I expected. We didn't abandon writing things down. We just stopped pretending that written debate alone could close a loop. We started scheduling what Maya later called "decision windows." Fifteen minutes. No status updates. No screen sharing a half-finished document. Just the three people who actually had context, sitting in a call, with one rule: someone has to leave that call having typed the decision into the doc.

The first one was awkward. We disagreed. Someone had to say "I think we should go with A, and here's why I'm not going to wait for more data." There was a pause, and then the decision got written down. It wasn't perfect. It was done.

What surprised me was what happened to the async discussions after that. They got sharper. People stopped writing essays designed to impress nobody in particular. They laid out trade-offs like adults who knew a real conversation was coming. The doc became a pre-read, not a destination. And Maya, who had been silently carrying the weight of every unmade decision, started looking less exhausted.

The "let's take this offline" habit didn't disappear overnight. But now when someone says it, there's a follow-up question baked into the team culture: "Great—who's scheduling the window?" If nobody steps up, we all know. We're not being thoughtful. We're just letting the thing die politely.

It turns out a decision isn't a document. It's a moment. And moments don't happen in comment threads. They happen when two people look at each other—on a screen or across a table—and one of them says the thing that's been waiting to be said out loud.

The Blameless Postmortem That Still Blames You

Om Keswani — Thu, 18 Jun 2026 13:08:13 +0000

You’ve been in that retro. The slide already says This is a blameless postmortem. Someone pastes a Slack timeline, a facilitator reminds the room to focus on systems not people, and a fresh Jira epic swallows the action items. You nod along, camera off, and you think the same thing you’ve been thinking for six months: I still feel like I’m being written up.

We got fluent in the vocabulary of psychological safety years ago. Nobody asks “who broke this?” anymore. We ask “what allowed this failure mode?” and we mean it. Yet for a lot of engineers — especially the ones quietly absorbing operational chaos — the postmortem has shape-shifted into something uglier. It’s become a surveillance document that wears a learning-opportunity mask.

Here’s how it actually works. The incident timeline lands in a shared folder, and an innocent question floats up in the thread: “Was the alert acknowledged before the escalation policy triggered?” Sounds factual. But it’s really a timestamp with your name on it, and it’s sitting there while your manager drafts quarterly feedback. The system doesn’t have to point a finger. It just has to record who touched what, and when, and let a well-trained imagination fill in the rest.

The kicker is that nobody set out to build it this way. Teams genuinely believe thorough postmortems prevent recurrence, and thorough means attribution. Who logged in. Who merged. Who approved the rollback. The document collects all of it without malice, then quietly hardens into a competency paper trail. Come calibration season, a pattern of “always being in the timeline” — even if you were the one who caught the bug, stayed up, wrote the fix — gets read as a pattern of being close to incidents. And that’s a pattern that costs you.

I’ve watched people game this in real time. They learn to never be the last person to touch a config change. They make sure the incident commander role rotates away before the retrospective. They write action items so vague no single human can be tied to their completion. This isn’t laziness; it’s survival. When “blameless” means we won’t say it out loud but we’ll sure remember, smart people stop volunteering for the pager shadow rotation. They stop saying “I’ll own the fix.” They stop caring about the system and start caring about their paper trail.

The real giveaway isn’t what happens in the meeting — it’s what happens three weeks later, when a senior engineer quietly asks to be moved off on-call and leadership treats it like a motivation problem instead of a trust problem. Or when the action items that emerged from the incident aren’t new runbooks or circuit breakers, but a private coaching note: “Improve response time under pressure. Communicate more clearly in Slack during degraded state.” That’s not a system improvement. That’s a performance review bullet wearing a postmortem hoodie.

Real blameless culture doesn’t live in a meeting template. It lives in an institutional refusal to let incident timelines become résumé lines. It means postmortems celebrate the person who showed up five times in the log, not flag them as “risk exposure.” It means the overwhelming majority of action items are about automation, not about coaching conversations. Until that’s true, the word “blameless” will just be the new “we’re a family” — something you hear right before the part that hurts.

The Standup Theatre

Om Keswani — Sun, 14 Jun 2026 11:21:28 +0000

It’s 9:15 AM. You’re holding a coffee you didn’t want yet, listening to the fourth person in a row say, “Yesterday I worked on the API integration, today I’ll continue the API integration, no blockers.”

Nobody’s fooled. Everyone knows the API integration has been “continuing” for six days. But we all nod anyway, because the real goal of this meeting is no longer coordination. It’s performance.

Somewhere between the agile manifesto and the daily grind, standups stopped being about unblocking work and started being about proving you’re working. The audience shifted. People aren’t talking to their teammates anymore. They’re talking to the manager, the tech lead, the person who might whisper something in a one-on-one. Without anyone saying it, the three questions became a tiny audition. Can you sound productive in under sixty seconds?

The cost of this theatre is bigger than most teams admit.

Real engineering is messy. You spend a morning falling into a rabbit hole only to discover the problem was a misconfigured feature flag from two sprints ago. But “I traced a bug to an old flag and have no fix yet” sounds like you did nothing. So you paraphrase: “Making progress on the checkout issue.” That sanitised sentence protects you, but it buries crucial context. Your teammate who fixed that flag last month never hears about the fallout. The team repeats the same mistake next sprint because the truth never made it onto the board.

Then there’s the help that never arrives. A standup is supposed to surface blockers. But in a performative standup, admitting you’re stuck feels like saying you’re incompetent. So you don’t say it. You go back to your desk, open the same undocumented internal library, and spend another afternoon staring at the screen alone. The ten-minute conversation that could have saved you never happens, because you learned that the safest thing to say is “on track.”

And management loves it. Every day they hear a chorus of “on track,” and they walk away feeling secure. That’s the most dangerous part. A smooth standup isn’t a sign of health; it’s often a sign that problems are being hidden just well enough to blow up spectacularly three days before the sprint ends. The standup becomes the very thing that hides reality from the people who need to see it most.

I once worked on a team where a developer spent two weeks struggling with a flaky deployment pipeline. Every standup he said, “Still working on the deployment stuff.” Nobody asked follow-ups, because the standup was a status broadcast, not a conversation. Two days before launch, the pipeline collapsed entirely. We scrambled, people cancelled weekends, and the fix ended up taking a pair of engineers four hours. If one person had said, “Hey, that sounds painful, let’s look at it together after standup,” the entire crisis would have been a non-event. But the format didn’t invite that. The format invited performance.

How do you break out of it?

I’ve seen one trick work more often than any other: talk about the work, not the worker. Instead of going around the room person by person, walk the board from right to left—closest to done first. Ask about the tickets, not the humans. “What’s stopping this from shipping?” It becomes much harder to perform when the question is about a specific card. You can’t polish a stuck ticket into sounding like progress. You just have to say, “The payment service dependency hasn’t responded,” and suddenly that’s not a personal failure. It’s a fact. And facts invite help.

Another thing: let standups be awkward. A good standup occasionally has a moment of silence where everyone stares at a problem and realises they don’t have an immediate answer. That’s okay. If your standups never feel slightly uncomfortable, you’re probably not surfacing the real stuff. The goal isn’t a clean, reassuring daily ritual. The goal is to make invisible work visible, and invisible work is rarely tidy.

I’ve also seen teams kill standups entirely and replace them with asynchronous Slack threads. That can work, but only if the team already has enough psychological safety to be vulnerable in text. Otherwise, you just get polished bullet points instead of polished monologues—same theatre, different stage.

The standup isn’t the problem. It’s a neutral container. It becomes theatre when people learn that honesty has a cost and performance has a reward. Fix that, and a 15-minute circle can still do its real job: making sure nobody fights the monster under the stairs alone.

So tomorrow morning, when someone says “no blockers,” maybe pause and ask, “Really? Even that nasty logging bug from yesterday?” You might just find that the show is over and the real work begins.

The Slack Dependency: How Instant Messaging Replaced System Design

Om Keswani — Sat, 06 Jun 2026 09:37:07 +0000

A new engineer joins the team.

On their first day, they ask a simple question:

"Why does this service call that API before writing to the database?"

Nobody knows.

The documentation doesn't mention it.

The architecture diagram is two years old.

The code doesn't explain it.

Eventually, someone replies:

"Search Slack. I think we discussed it last year."

After twenty minutes of scrolling through old threads, buried between emoji reactions and unrelated conversations, they finally find the answer.

And that's when they discover a strange truth about modern software teams:

The most important documentation isn't in the documentation.

It's in chat history.

Most organizations believe they have a documentation problem.

Many actually have a dependency problem.

Over time, Slack, Teams, Discord, and other messaging platforms become the unofficial source of truth for technical decisions.

Why was a service split into two?

Search Slack.

Why is that database query intentionally slow?

Search Slack.

Why can't we remove that feature flag?

Search Slack.

Critical engineering knowledge slowly migrates from systems into conversations.

At first, this feels efficient.

A quick message gets a quick answer.

No need to update a document.

No need to schedule a design review.

No need to maintain a knowledge base.

Just ask the team.

The problem is that conversations solve today's question while creating tomorrow's confusion.

Every answer delivered through chat disappears into an endless stream of new messages.

The team gains speed in the moment but loses memory over time.

The result is a hidden form of technical debt.

Not code debt.

Knowledge debt.

The system becomes increasingly dependent on people remembering things.

The architecture exists in someone's head.

The deployment process exists in a private conversation.

The reasoning behind critical decisions exists in a Slack thread from fourteen months ago.

As long as the right people stay on the team, everything appears fine.

Then someone leaves.

And suddenly nobody understands why certain parts of the system exist.

This is one reason onboarding feels so painful in many engineering organizations.

New developers aren't learning the system.

They're learning how to navigate years of fragmented conversations.

Instead of reading clear documentation, they're performing digital archaeology.

Every answer requires digging through old channels, forgotten threads, and messages written for people who already understood the context.

The organization hasn't lost knowledge.

It's simply buried.

Ironically, most teams don't intend for this to happen.

Chat tools are designed for communication, not long-term memory.

But because communication is easier than documentation, the path of least resistance wins.

A five-minute Slack message replaces a thirty-minute design document.

A quick explanation replaces a written decision record.

Eventually, the conversation becomes the system.

The danger isn't that Slack contains useful information.

The danger is when Slack becomes the only place that information exists.

Because chat history is not architecture.

It is not documentation.

And it is not a reliable way to preserve institutional knowledge.

A healthy engineering organization treats conversations as the beginning of documentation, not the replacement for it.

Otherwise, every technical decision eventually turns into a scavenger hunt.

And every new engineer inherits the same challenge:

Building software while searching thousands of messages to understand why it works in the first place.

Why Every "Quick Fix" Eventually Becomes a Core Dependency

Om Keswani — Sat, 06 Jun 2026 09:34:52 +0000

A production issue appears at 4:52 PM on a Friday.

Customers are affected. Alerts are firing. Leadership wants updates. Nobody has time for a perfect solution.

Someone suggests a workaround.

"Let's patch it for now. We'll clean it up next sprint."

Everyone agrees.

The patch goes live.

The incident ends.

The team moves on.

And that's usually the moment a temporary fix begins its journey toward becoming permanent infrastructure.

Most engineers assume technical debt is created by poor engineering decisions.

In reality, some of the most stubborn technical debt starts as a completely reasonable decision made under pressure.

The quick fix wasn't reckless.

It was practical.

It solved the immediate problem, reduced business impact, and allowed everyone to sleep that night.

The problem is what happens afterward.

Nothing.

The next sprint arrives, but priorities change.

A customer request becomes urgent.

A new feature gets scheduled.

Another production issue appears.

The cleanup task quietly slips into the backlog.

Then it slips again.

And again.

Eventually, nobody talks about it anymore.

The workaround survives long enough to become part of the system.

This is where software systems develop a strange kind of organizational memory.

New engineers join the team and see the workaround already in place.

To them, it isn't a workaround.

It's simply how the system works.

Documentation starts referencing it.

Monitoring dashboards depend on it.

Other services integrate with it.

New features are built around its behavior.

Without anyone making a conscious decision, a temporary patch becomes a core dependency.

The most dangerous part is that quick fixes rarely create immediate problems.

If they constantly broke production, teams would remove them quickly.

Instead, they usually work.

Not perfectly.

Not elegantly.

But well enough.

And "well enough" is often all a system needs to survive for years.

The temporary script created for a one-time migration becomes part of every deployment.

The emergency API endpoint becomes a business-critical integration.

The shortcut database field becomes essential for reporting.

What was once considered technical debt slowly transforms into infrastructure.

Years later, someone finally proposes removing it.

The response is almost always the same.

"Are we sure nothing depends on it?"

Nobody knows.

The engineer who created it left two years ago.

The original ticket is long gone.

The documentation is incomplete.

And after years of integrations, assumptions, and hidden dependencies, removing the fix suddenly feels riskier than keeping it.

So it stays.

Not because anyone believes it's the right solution.

Because nobody can confidently prove it's safe to delete.

The irony is that quick fixes are not the enemy.

Every engineering team needs them occasionally.

Production incidents don't wait for perfect architecture.

The real mistake isn't creating a shortcut.

It's failing to assign an expiration date to it.

Because software has a habit of preserving yesterday's compromises long after everyone forgets why they were made.

And if a temporary solution survives long enough, it stops being temporary.

It becomes the system.

The next time you hear someone say, "We'll fix it properly later," remember:

Later is where most core dependencies come from.

Why Most AI-Generated Code Never Survives a Production Incident

Om Keswani — Fri, 29 May 2026 11:21:55 +0000

The code was perfect. Until production met reality.

A few months ago, a developer on a team I knew fixed a bug in under ten minutes.

A quick prompt to an AI assistant. A clean-looking solution. Tests passed. Pull request approved.

Everyone was impressed.

Three weeks later, the same code helped trigger a production incident.

Not a dramatic outage. The worst kind.

Some users were affected. Others weren't.

Logs looked normal. Monitoring dashboards were green. Support tickets slowly started piling up.

The engineer who merged the change opened the code and started reading.

Then came the uncomfortable moment:

"I know this works. I just don't know why."

That's when I realized something.

AI has made writing code easier than ever.

But production incidents were never about writing code.

They're about understanding systems.

The Difference Between Coding and Owning

Most software feels brilliant on the day it's merged.

Production doesn't care.

Production introduces weird customer behavior, forgotten edge cases, network failures, outdated dependencies, and assumptions nobody remembers making.

That's why the most valuable engineer during an incident usually isn't the person who wrote the most code.

It's the person who understands how everything connects.

They know which service tends to fail first.

They remember why a strange workaround exists.

They can look at a symptom and trace it back to a cause.

That knowledge doesn't come from generating code.

It comes from living with it.

The Confidence Problem

The biggest risk with AI-generated code isn't that it's wrong.

It's that it looks right.

The code is clean.

The variable names make sense.

The structure feels professional.

And because it looks convincing, it's easy to skip the hardest question:

Do I actually understand what this is doing?

Most of the time, that question doesn't matter.

Until production breaks.

Then it matters a lot.

Because debugging isn't about reading code.

It's about understanding behavior.

Production Is Where Context Wins

When systems fail, the answers are rarely sitting inside a code snippet.

They're hidden in things AI can't easily see:

A decision made six months ago.
An undocumented dependency.
A customer workflow nobody considered.
A "temporary fix" that became permanent.

Production systems are full of history.

And history doesn't fit neatly into a prompt.

That's why incident response feels less like programming and more like detective work.

You're gathering clues, testing assumptions, and trying to explain something that shouldn't be happening.

The Real Skill

AI will continue getting better at generating code.

There's no reason to pretend otherwise.

But the engineers who stand out won't be the ones who can generate code the fastest.

They'll be the ones who can explain why a system behaves the way it does.

Because when a production incident starts at 2 AM, nobody asks:

"Who wrote this?"

They ask:

"Who understands this?"

And those are two very different skills.

The future may require fewer keystrokes.

But it will always require understanding.

And production has a way of exposing the difference.

The Myth of “Ownership”: How Ambiguous Responsibility Quietly Breaks Production Systems

Om Keswani — Thu, 14 May 2026 08:15:02 +0000

Everyone talks about ownership in engineering teams.

“We need stronger ownership.”
“Who owns this service?”
“Take ownership of the issue.”

But after working on real production systems, I’ve realized something uncomfortable:

Most systems don’t actually have owners.
They have temporary caretakers.

And that difference quietly breaks production more often than bad code does.

A few months ago, our team had a production incident that looked simple at first.

An API started timing out randomly. Nothing catastrophic — just enough to frustrate users and flood Slack with alerts.

The strange part? Every team involved believed the issue belonged to someone else.

Backend thought infrastructure caused it.
Infrastructure thought the database team changed something.
Database team pointed toward networking.
Networking team said traffic patterns looked normal.

For nearly four hours, everyone investigated the problem while simultaneously avoiding responsibility for the system itself.

Eventually, we found the root cause:
a “temporary” retry mechanism added by a former engineer months earlier.

No documentation.
No monitoring around it.
No clear owner.

Just production code sitting silently until traffic exposed it.

And honestly, that’s when I stopped believing most companies understand ownership at all.

In theory, ownership sounds clean.

One team owns one service.
Responsibilities are defined.
Problems get solved quickly.

Reality is messier.

Production systems evolve faster than org charts do.

Engineers switch teams.
Priorities change.
Services get copied, renamed, partially rewritten, or abandoned halfway through migrations.

Over time, systems become shared territory where everyone can deploy changes, but nobody fully understands the consequences.

That’s where dangerous failures start.

Because unclear ownership creates a psychological loophole:
“If everyone is responsible, nobody feels responsible enough.”

And the scariest production issues usually grow inside that gap.

The biggest misconception is that ownership means writing the code.

It doesn’t.

Real ownership means:

understanding operational risks
maintaining documentation
cleaning up old decisions
responding during incidents
saying “this system is unhealthy” before it becomes an outage

But those tasks are invisible work.

They don’t appear in sprint demos.
They don’t impress stakeholders.
They rarely help promotions.

So teams naturally optimize for visible progress instead.

New features get celebrated.
System maintenance becomes “later.”

And “later” eventually becomes a 3 AM production incident.

What makes this worse is modern engineering culture loves distributed responsibility.

Microservices. Platform teams. Shared tooling. Internal frameworks.

Individually, these ideas make sense.

But combined carelessly, they create systems where critical behavior is scattered across five repositories and three teams.

Now debugging production isn’t just technical work.

It becomes organizational archaeology.

You’re not tracing requests anymore.
You’re tracing accountability.

The hardest lesson I’ve learned is this:

Most outages are not caused by a single catastrophic mistake.

They happen because small unanswered questions accumulate over time.

Who maintains this?
Who reviews risky changes?
Who gets alerted?
Who understands failure modes?
Who cleans up legacy behavior?

If those answers are unclear, the system is already unstable — even if everything looks healthy today.

Because production reliability is less about software architecture and more about clarity.

And clarity is surprisingly rare in growing engineering teams.

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?”