Pushpendra | AWS & Agile Engineer

Senior SWE · AWS ☁️ · React · Agile & Sprint Expert · Building cloud-native systems · Watching AI reshape the tech world 🌏

[Arpit Bhayani @arpit_bhayani]

Every migration you will ever do is a Ship of Theseus problem. The ancient Greeks had a paradox: if you replace every plank of a ship one by one, is it still the same ship?

We face this every day, except the ship is in production :)

The naive version of a migration is a full cutover: stop the old system, start the new one. It almost never works at scale. What actually happens is a slow, plank-by-plank replacement.

Let me give you some examples...

Database migrations are the clearest example. Moving from MySQL to PostgreSQL takes time. You run both databases in parallel, write to both (dual-write), and slowly shift small portions of reads to Postgres while monitoring for inconsistencies. Then, you gradually port the entire codebase.

Language migrations follow the same pattern. You never rewrite everything from one language to another and flip the switch. It is also done on a piece-by-piece basis. A similar strategy is followed during monolith-to-microservices migrations.

So, if you are planning something big, consider breaking it into planks and changing one at a time until your entire ship is new.

Pro tip: use this analogy to sound smart in meetings and discussions :) It always works.

[Arpit Bhayani @arpit_bhayani]

Claude just fixed a flaky test by literally mocking the buggy function after spending 15 minutes trying to fix it. Peak AI behavior.

To be honest, I would have done the same thing as an intern, out of frustration.

Fascinating that AI can be both an intern and a staff engineer at the same time.

[Pushpendra | AWS & Agile Engineer @atom217]

no multiple round trips → Massively cheaper at scale It breaks every relational instinct you have. That's the point. #DynamoDB #AWS #Serverless #SystemDesign

[Pushpendra | AWS & Agile Engineer @atom217]

The most misunderstood DynamoDB pattern:

[Pushpendra | AWS & Agile Engineer @atom217]

Single Table Design — storing ALL your entities in ONE table. Users, orders, products, sessions → one table. Sounds insane. Here's why it works: → Partition key + sort key handle all relationships → One query = multiple entity types returned → No joins,

[Arpit Bhayani @arpit_bhayani]

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.

[Kent C. Dodds 🏹 @kentcdodds]

https://t.co/Xr1FY2PDDy

[Pushpendra | AWS & Agile Engineer @atom217]

The engineers who will thrive in the next 5 years aren't the best coders.They're the ones who understand: → System design at scale → Business context behind the feature → How to ship, not just buildCode is the easy part now. Judgment is the moat. #Career #AI #Leadership

[Arpit Bhayani @arpit_bhayani]

The industry has gone completely nuts.

Use tokens to generate AI code and documentation slop. Then use even more tokens to understand and review that slop.

Then judge engineers by token usage instead of how empathetic and clear their docs and code actually are, and completely neglect human comprehension.

Utter nonsense.

[Pushpendra | AWS & Agile Engineer @atom217]

Jira mistakes killing your sprint velocity
Treating the sprint backlog as a wish list
No WIP limits on the Kanban board
Skip retrospectives when things are "going fine"
Mix bug tickets and feature work without swimlanes
Velocity as a performance metric, not a planning tool

[Pushpendra | AWS & Agile Engineer @atom217]

As Indian IT giants lose ground, Anthropic & NVIDIA surge ahead — an inverse equation reshaping global tech power. #IndianIT #Anthropic #NVIDIA #AI #TechShift #MarketDynamics

[Pushpendra | AWS & Agile Engineer @atom217]

India's economy faces a perfect storm: AI disruption eroding exports while rupee depreciation fails to boost competitiveness. Surging oil and gold import costs worsen the pressure. We're looking at a structural crisis that demands urgent policy action now. #AI #Markets #Sensex

[Neha Sharma @hellonehha]

Resharing

[Pushpendra | AWS & Agile Engineer @atom217]

Modernizing a legacy system isn't about the new tech.
It's about leadership choosing respect over recklessness, longevity over speed, and evolution over extinction.
React-localize had a good run. But systems need to grow or they die. Ours was revived.

[Pushpendra | AWS & Agile Engineer @atom217]

Three lessons from reviving a legacy system:
Respect the Foundation: React-localize didn't fail. It aged. The best modernizations honor what came before while building toward what's needed next.

[Pushpendra | AWS & Agile Engineer @atom217]

Customer-First Always: Every decision came back to one principle: would this break someone's booking experience?
If maybe, we slowed down. That's not risk-aversion. That's respect for what depends on you.

[Pushpendra | AWS & Agile Engineer @atom217]

Phase 4: Retirement and RebirthOnce we confirmed 100% stability, we retired react-localize. The legacy system that served us faithfully was laid to rest.
In its place: a modern, scalable foundation ready for the next chapter.

[Pushpendra | AWS & Agile Engineer @atom217]

For years, react-localize powered the our org's Dashboard. It served us well. But systems age. What once worked was now holding us back—maintenance was painful, features were harder to build, scaling felt impossible.
The system needed revival.

[Pushpendra | AWS & Agile Engineer @atom217]

Phase 3: Gradual TransformationComponent by component, we shifted the load. This pace was deliberate.
Legacy systems don't fail because of one bad decision—they fail because change moves too fast. We learned that lesson and moved at the speed of trust.