sharath odepalli

  Stop Saying “Improved Performance” Say What You Actually Changed Early in my career, I used to write lines like: Improved performance Built a scalable system Optimized cost Enhanced reliability They sounded good. They were also meaningless. Over time, I realized something uncomfortable: Vague language makes strong engineering look average. And strong engineering deserves precision. Why “Fuzzy” Engineering Hurts You When you say: “Improved performance” No one knows: By how much? Compared to what? Under what load? With what trade-offs? It forces the listener to guess. And when people guess, they assume small impact. In reality, engineering impact is almost always tied to: A number A constraint A trade-off If those are missing, your work feels shallow even when it is not. The Rule I Follow Now I do not describe work unless I include at least one of these: A number. A constraint. A trade-off. That rule changed how I communicate. Instead of saying: “Improved API performance” Say: Redu...

  Define “Good” With 4 Numbers The simplest habit that makes engineering calmer Most engineering debates are not about code. They’re about undefined expectations. “This feels slow.” “This is not reliable.” “This is too expensive.” “This isn’t scalable.” The problem is not disagreement. The problem is that nobody defined what “good” actually means. Over time, I’ve started doing something simple before building anything meaningful: We define  four numbers . Not twenty metrics. Not vague goals. Just four numbers that align engineering, product, and leadership. 1. Latency Target What should this feel like for a normal user? Not what is technically possible. Not what is “acceptable in theory.” What should the experience actually feel like? If you do not define this early, you end up optimizing randomly. Is 800ms fine? Is 300ms expected? Does this flow need sub-100ms? When we define the latency expectation upfront, architecture decisions become easier: Caching becomes intentional Qu...

  Why Averages Lie and P95 Actually Matters For a long time, I looked at average latency and felt confident. Dashboards were green. Numbers looked healthy. Nothing seemed broken. And yet, users were complaining. Pages felt slow. Flows felt unreliable. Support tickets kept coming. That disconnect taught me an important lesson: Users do not experience averages. They experience the slow moments. The frustrating pauses. The one request that took far too long when it mattered. That is why P95 and P99 matter more than the average. The Problem With Averages Average latency tells you how the system behaves most of the time. But real user experience is shaped by the worst moments, not the common ones. If 95 out of 100 requests are fast, but 5 are painfully slow, users will remember the slow ones. Those slow requests often happen during peak load, degraded dependencies, or edge cases. Exactly when users need the system most. From a user’s perspective: A single slow login feels broken A delay...

  Code Reviews Don’t Fail. PRs Do. Most teams believe they have a “code review problem.” Reviews are slow. Feedback is inconsistent. Bugs slip through. Everyone feels blocked. But after working with multiple teams and systems, I’ve come to a different conclusion: Most teams don’t have a code review problem. They have a pull request problem. Reviews fail because PRs are hard to review. This blog is about fixing that. Why PRs Become Bottlenecks A pull request is a handoff. When that handoff is unclear, everything slows down. Here’s what usually goes wrong: The PR mixes multiple changes The intent is unclear Reviewers don’t know what to focus on Risk is hidden Context lives in someone’s head So reviewers either: take too long, or approve too fast without understanding Neither outcome is good. Treat PRs Like a Product The shift that helped me most was simple: Treat every PR like a product you are handing to another human. Your reviewer is your user. If the experience is confusing, they...

How to ship big changes safely without breaking trust I noticed something interesting on the SBI online banking website recently. There appears to be a refreshed UI rolling out, and what stood out to me is that users can switch between the old UI and the new UI. Whether SBI is using feature flags internally or not, that experience reflects a common pattern in mature engineering teams:  controlled rollout . When the product is critical and used by millions, you cannot afford a risky, all-at-once launch. You need a way to introduce change gradually, measure impact, and recover instantly if something goes wrong. That is exactly what feature flags enable. This blog explains what feature flags really are, why they matter for reliability, and how to use them in a clean, disciplined way. 1) What feature flags are, in plain terms A feature flag is a runtime switch that changes product behavior without requiring a redeploy. You ship the code, but it remains “off” for most users until you ex...

  How “Calls per Request” helps you catch hidden performance and cost bugs early Most “slow apps” are not slow because the database is bad. They are slow because a single request quietly triggers far more work than anyone expects. This pattern is commonly known as  N+1 queries , but in real systems it goes beyond databases. It becomes  N+1 work . And once it shows up, it hurts performance, reliability, and cloud cost at the same time. This blog explains what N+1 work looks like, why it is dangerous, and how to prevent it using one simple measurement:  calls per request . 1) What N+1 work actually is N+1 happens when something that should happen  once  happens  N times , usually because it sits inside a loop. A classic example: You fetch 100 orders. For each order, you fetch customer details. That becomes 1 query for orders + 100 queries for customers. But the same pattern appears outside the database too: One API request triggers 1 service call, then 3...