Tech Lead: We need to rewrite the entire backend.
Developer: Why?
Tech Lead: It's messy.
Developer: It's been running in production for 4 years without a single outage.
Tech Lead: But the code isn't clean.
Developer: The users don't read the code.
Tech Lead: It'll be easier to maintain.
Developer: For who? The 3 of us who understand it right now?
Tech Lead: We'll use microservices this time.
Developer: We have 200 daily users.
Tech Lead: ...but what about scale?
Developer: We will cross that bridge when we get to 200,000 users.
"Let's rewrite it" is the most expensive sentence in software development 😭
Has your team ever rewritten something that didn't need rewriting? 👇
Every piece of software I use which used to be originally produced with a lot of care has gotten shitty. Just to make a list from top of my head...
1. Starting with this site. I used to give an example of how the Twitter mobile app was epitome of saving list scroll state across app lifecycle and even app death, all the way back in 2016 when teaching mobile development to my students. Today, most tweets > 2 day old if I open, the replies do not load, I don't get notifications for DMs, and random parts of it don't work at random times.
2. MacOS which was once more polished than Windows on the UI and as hackable as Linux from inside out - now randomly freezes, has kernel panics, needs disabling needless safety features all they way from safe mode to get basics working or toning down the horrible glass UIs.
3. Spotify used to be one of my favourite products, having great offline-first experiences, seamless sync across devices, handover of songs midway between phone, desktop, car, etc. Now the app can't even load offline downloaded playlists properly when internet is down, sync almost never works, UI glitches, watch app can't figure out how to play on headphone, or when to sync from phone to watch.
4. Whatsapp - one of the most performant apps, with solid delivery rates even with as slow as 2G/EDGE internet, now actually has dead-end UI flows (when sending photos, trying to edit it can lead to an unknown state), message deliveries often don't work even on solid internet, and media uploads frequently need retries.
5. Microsoft's entire office suite which used to be a workhorse product - something so reliable, that non-tech people would never touch Google Sheets with a 10-foot pole and threaten to resign if they didn't have a proper desktop app license of MS Office. Now they push you towards the cloud versions which work way worse than Google Workspace, and have add tons of React UI elements in the Desktop apps that makes then visibly slow and janky and large Excel sheets even crash sometimes.
Most of these were on the trajectory of enshittification before wide-scale agentic coding or Claude-driven development was even all that common.
The entire industry is in a phase where everyone is just building things because it is their job, and the era of care, and sincere craftsmanship of products has mostly come to an end.
The software industry has done everything in it's power to reduce technically competent people to Ticket Jockeys. Get The Ticket, Fix The Ticket, Push the Ticket. If you're very lucky the team will all get together and have Ticket Meeting, lead by an experienced Ticket Manager.
Hot take: it's because people are bad at setting up an enviromnent for their Clankers to interact with prod in a safe, non destructive way.
We've been conditioned into thinking that letting them interact with prod is a recipe for disaster. This came from people who were trying to YOLO their way into this, and now all we can think of is that we've seen these overly dramatic stories about how agent deleted their prod DB or something. PEBKAC.
Most software engineers are facing an identity crisis bordering on depression.
As CTOs aggressively evangelize tokenmaxxing, a class divide ensues.
The lazy. The lazy push code. They don't write it. They don't manually test it. They don't even read it. They're on autopilot. See Jira ticket, prompt for task, submit code. Many of them are barely on their computer the whole day. A comment on the PR asking why they did this? The lazy ask AI. A Slack message? The lazy ask AI. Need to prepare for standup? The lazy ask AI. As long as it sounds enough like them and isn't detected. Some of the lazy are even overemployed, and work multiple jobs. The lazy smart ones get away with this, and even rewarded. After all, software engineering for the lazy is just a dance to convince your colleagues you're smart and hard working.
The craftsmen. The craftsmen are tired. Very tired. 15 PRs in queue. Slack blowing up. The entire burden of review falls on the craftsman. The burden of understanding. They try. They work their way through the code, thoughtfully commenting to improve what ships. The response? A lazy: "That's a clever idea! You're absolutely right." with an incorrect change. It's fine, the craftsman says. I can fix them. They write a doc urging his colleagues to be better. The next day? 20,000 line PR to review. Day after day, their workload grows. Bugs seep into production. No one seems to care. Another round of AI is thrown at it. Their animosity to their colleagues rises. Eventually, they give up. It's just not what it used to be. The craft they loved is dead. They eventually wake up, a lazy.
This isn't all companies. Many companies are genuinely more productive, adopt the right set of principles and practices around AI development and have highly talented teams that trust each other. It tends to happen in bigger companies that are 10+yrs old with a higher talent variance. But it happens. A lot.
Caching doesn't reduce load. It shifts load.
You put Redis in front of your DB. Great. Now 99% of reads hit the cache.
But that means your DB is used to handling 1% of traffic. It's been chilling.
The moment that cache goes down, 100% of traffic hits a database that hasn't seen real load in weeks.
Your DB doesn't slow down. It falls over.
This is called a thundering herd. And it happens exactly when you're already having a bad day...xD
Fable isn't the first.
In 1999 the department of defense blocked exports of the PowerMac G4 for crossing the 1 gigaflop threshold.
Steve Jobs turned it into an ad.
When you join a new organization, it is quite natural to feel a strong urge to fix things. Let me ruffle some feathers here...
You will notice processes, tools, or practices that feel inefficient, outdated, or even wrong. Maybe the team uses Jira instead of Linear, Java instead of Go, MongoDB instead of MySQL (for a use case), or Tabs instead of Spaces. It will be tempting to point it all out immediately. Resist that urge.
Do not get overwhelmed by outrage. Every organization has quirks, and yours is no exception.
Complaining loudly in your early days won't make people rally behind you. You may be right, but what you lack is context. What looks foolish from the outside might have made perfect sense at the time.
So, start by asking why. Be curious. Ask questions, and listen closely. The more context you gather, the clearer the rationale will become.
At first, focus on integrating rather than fixing. Show reliability, do good work, and build relationships. Once you have established credibility, you'll find that people are more open to your perspective. That's when you can choose your battles carefully.
Keep this simple framework in mind:
- Ask why before suggesting what
- Listen more than you speak
- Build trust before pushing change
- Pick one thing, not everything
Prove your ideas with small wins, and show that you understand the context. Over time, you will gain the influence to bring major changes and improvements.
You can't fix everything on day one, but you can ruin trust in one.
Hope this helps.
We just wrapped our annual performance review at Sahi.
Nobody got promoted. And we love it.
@Sahi_HQ is 2.5 years old, and we've consciously avoided internal job levels and fancy designations. Every engineer is a "Software Engineer." Every PM is a "Product Manager." That holds across the company.
Having built and led 1000+ people organizations at @amazon and @Swiggy , I carry painful memories of what traditional org structures — levels, titles, ladders — actually do to a company. I've been guilty of it myself. At Swiggy, we created titles and new levels because we had to, as tools to attract and retain talent. It's a slippery slope. Once you anchor people to levels and titles, they start to optimize for them.
I call this the "resume-driven development" phase: careers are built around what it takes to get promoted, not what the company actually needs. The machinery around promotions — peer feedback, promo templates, calibration cycles — only deepens it. Employees and managers spend weeks "aligning feedback providers" and "gathering data points." Before long, the promotion process becomes the single most important conversation between a manager and their report.
All of this to climb a ladder that was invented to give people a sense of personal growth.
After 20+ years of watching it up close, I can say it plainly: promotion culture is broken. It's the opposite of what great companies need to win.
Great companies hire missionary talent, trust them with the freedom and opportunity to do meaningful work, and share the rewards through wealth creation.
At Sahi, we're holding on to this. Every team conversation is about impact and outcomes, with zero time lost to promotion politics and the Day 2 culture rot it leaves behind.
In the age of the AI-native company, the old hierarchies are dead.
**Performance Culture >> Promotion Culture**
A very hardworking office boy I know is looking for a job. He is very sincere and the best person I know to get your office setup and maintain it. A true Kannadiga and a jack of all trades, he will even help with your admin tasks. Any location across Bangalore will work for him.