DEV Community: Sarthak Shrestha

Technology Turned Parents Into Real-Time Comparison Machines

Sarthak Shrestha — Tue, 16 Jun 2026 13:07:58 +0000

Everyone thinks technology made life easier.

Message people instantly. Read news anytime. Watch any series on demand.

It didn’t really make life easier. It just changed what people suffer from.

The beginning of two beautifully articulated words turned parents into comparison machines and children into idea factories: Artificial Intelligence.

First it was newspapers. Then social media. Now, every morning, someone discovers a teenager who built an AI startup.

"Look at this boy."

I look at the article.

"Dad, this is just an AI wrapper."

"It raised money."

"How?"

"I don't know."

"Neither do the investors."

Everything today is AI-powered, revolutionary, disruptive, or game-changing. Even if it's just a calculator wearing a hoodie.

The funniest part is that nobody knows what any of these words mean anymore—but everyone nods anyway. I watch people react to a new AI feature the same way Gollum reacted to the Ring: "My precious."

Three months later, they forget it exists.

The Hype Lifecycle

Discovery
Obsession
Conference Talks
LinkedIn Posts
Abandonment

The real question was never whether something uses AI. The real question is whether anyone will still care about it next year.

Chapter 1: Convenience That Didn’t Feel Convenient

Technology was supposed to remove effort.

That was the pitch. Message anyone instantly. Watch anything anytime.

Know everything in seconds.

On paper, life got easier. We don’t send pigeons anymore.

Nobody is running across towns to deliver a message.

In reality, nothing actually got easier.

We just lost the ability to disappear.

We didn't create convenience.

We created a system where the world could compare, judge, and evaluate you without waiting.

Chapter 2: The First Wave of Comparison (The Newspaper Era)

Before social media, before LinkedIn, before AI-generated teenagers founded startups between lunch breaks, there was the newspaper.

Parents had limited information back then, but they decided to be detectives that would put the FBI to shame.

A parent would open the morning paper and read:

"Local boy gets into Google" or "Local student wins international scholarship."

This meant your day started with a morning you wouldn't forget.

The good news was that newspapers had limits. There were only so many successful people printed each day. If nobody achieved anything extraordinary, you got a day off. Modern children never understood this luxury.

Back then: Parental disappointment operated on business hours.
Today: It runs on cloud infrastructure.

A newspaper article lasted a day. A comparison lasted a week. Then everyone forgot. Life moved on. The newspaper era was peaceful—not because parents compared less, but because technology hadn't figured out how to automate it yet.

Chapter 3: Social Media Made It Global

Before social media, you were usually compared to the neighbor's kid who was academically strong, or some mysterious student who supposedly studied under a candle and still topped the class.

Life was manageable.

Then social media arrived and said:

"What if everyone became your competition?"

Suddenly, you were no longer competing with people in your city.

You were competing with:

A teenager from Singapore who speaks six languages.
A startup founder from California.
A chess champion from India.
A 14-year-old on YouTube explaining economics better than your university professor.

And somehow, all of them appeared on your phone before breakfast.

Social media achieved something remarkable:

It turned billions of strangers into relatives.

Every scroll became an opportunity for someone else's success story to find you.

At some point, I stopped asking whether these stories were real.

I became more interested in how they kept finding me.

Social media didn't create comparison;

it just gave it fiber-optic internet, cloud infrastructure, and an unlimited marketing budget.

Chapter 4: LinkedIn Turned Success Into a Feed

Social media made comparison global.

LinkedIn made it professional.

That was the upgrade nobody asked for.

At least on normal social media, success was scattered—a vacation photo, a random achievement, a motivational quote written after emotional damage.

You could scroll past it.

But LinkedIn removed all randomness.

Now everything is structured, optimized, and professionally disappointing.

Every morning begins the same way.

Someone wakes up and decides to “humbly announce” they have changed the trajectory of human civilization.

“Grateful to share…” (Nobody is ever ungrateful to share).
“I am excited to announce…” (Nothing announced on LinkedIn has ever been boring).

Then comes the list:

Built a startup
Raised funding
Scaled globally
Disrupted something that was probably doing completely fine

And somehow, they are 19 years old. Meanwhile, I am 24 and still deciding whether I am a morning person or just unemployed in different time zones.

The worst part is not the success stories.

It’s the consistency.

LinkedIn didn’t create ambition; it industrialized it.

Now success is not an event. It is a feed.

Chapter 5: AI Turned Everything Into Achievement Inflation

Then came Artificial Intelligence, and suddenly every achievement became unstable.

Before AI, you could at least understand what people built.

Now, everything sounds like it was generated during a caffeine overdose.

[ Your Idea ] -> [ API Wrapper ] -> [ Gradient UI ] -> [ "Revolutionary AI Workflow" ]

Nobody builds apps anymore.

They "leverage intelligent systems to revolutionize workflows," which usually means they wrapped an API and added a flashy UI.

And somehow, this is enough to raise funding, write 30-part Twitter threads, and become a “thought leader.”

Tech feeds have turned it into a daily sport:

Season 1: “AI will change everything”
Season 2: “This AI will replace everything”
Season 3: “This AI is everything”
Season 4: “Actually this AI is useless, but here’s a thread anyway”

You open your feed and see:

“This AI tool is INSANE.” (Translation: It auto-completes text slightly differently).
“This will 10x your productivity.” (Translation: You will now procrastinate 10x faster).
“This changes everything.” (It did not change anything. It just changed how confidently people can be wrong in public).

Chapter 6: The Daily AI Hype Championship

AI stopped being technology.

It became a daily competition for who can sound the most excited about nothing.

Tech influencers wake up like it’s a live broadcast event:

“BREAKING NEWS : New AI model just dropped.”

Dropped where? On a GitHub repo, and immediately onto 47 LinkedIn posts explaining why humanity is finished.

The Tool	The Hype Headline	The Reality
Simple Chatbot	"The End of SaaS"	A prompt template
Code Generator	"The End of Programming"	Needs 4 senior devs to fix the bugs
Text Summarizer	"The End of Thinking"	Missed the nuance entirely

Meanwhile, reality is much simpler: People still copy code from Stack Overflow. They just do it faster now.

The funniest part is the 14-day lifecycle:

Day 1: “This will replace engineers.”
Day 3: “This needs human oversight.”
Day 7: “Actually, it’s not that reliable.”
Day 10: “Here’s how to use it properly.”
Day 14: Abandoned. New model drops. The cycle restarts.

The Ultimate Question

AI didn’t replace jobs.

It replaced boredom.

Now even hype is automated, optimized, and scheduled.

And the influencers? They are just narrating updates like sports commentators who don’t understand the game but refuse to stop talking.

At some point, it stops being about technology, progress, or AI. It becomes a different question entirely:

Are they building for the hype... or for the field?
Are they creating because they see a real problem... or because they see an opportunity to sound impressive while solving nothing?
Are they solving something that actually breaks in the real world... or just wrapping normal ideas in AI jargon so it feels like innovation?

Everything looks the same on the surface:

AI-powered, revolutionary, game-changing.

But underneath the noise, the question has never changed:

Is this built to last, or just built to be posted?

The Kinetic Circuit Architecture: A Thought Experiment in Fault-Isolated Monoliths

Sarthak Shrestha — Sun, 07 Jun 2026 10:37:44 +0000

Disclaimer

This article is a thought experiment provided for educational and discussion purposes only. It is not a production recommendation, implementation guide, architectural standard, best practice, or professional advice.

Please do not deploy this in production without proper review, testing, validation, risk assessment, rollback plans, monitoring, and at least one engineer asking:

"Are we absolutely sure about this?"

These ideas come with no guarantees regarding correctness, security, reliability, performance, stability, scalability, maintainability, or your AWS bill's emotional wellbeing.

If you choose to deploy this anyway, you become the main character in the incident report. Any resulting outages, 3 A.M. alerts, surprise cloud invoices, executive escalations, emergency war rooms, or messages beginning with "quick question..." are entirely yours to handle.

Readers are responsible for evaluating and validating any implementation before deploying it into a production environment.

In short: this is an experiment, not a blueprint. Treat it accordingly.

Introduction

Yesterday I had a thought.

A single harmless engineering thought.

Most people have a thought, decide it's brilliant, think about it for a while, and then move on.

But it escalated.

All of this started because I asked:

"What if fault containment worked differently?"

Instead, it consumed an entire day and turned into what I now call:

“ Kinetic Circuit Architecture”

Phase 1: Everything looks smart at first

At the start, everything looked clean. Too clean. That’s usually how you know you’re in trouble.

The system had:

isolated circuits
supervisors
event routing
state stores
consensus logic

It looked organized. It felt like architecture.

But experience says something different:

if it looks too clean, you haven’t found the failure modes yet

Engineers love boxes. Boxes make complexity feel manageable. Arrows make uncertainty look intentional.

Full Image Architecture

Phase 2: The event bus gets reality-checked

Originally, everything lived in memory.
Which is a fancy way of saying:

“if the system restarts, it forgets everything like it just woke up from a bad dream”

Then reality showed up and asked the only question that matters:

“what happens if it crashes?”

And the answer was:

“it forgets everything and pretends nothing happened”

So that idea got removed faster than a bug in production on a Friday afternoon.

Now it remembers things properly, like an adult.

Phase 3: The single brain problem

The original design had a central Consensus Engine.

One component responsible for understanding system-wide health.

At first that felt elegant.

Then somebody asked:

What happens if the Consensus Engine fails?

And suddenly the architecture looked less like a resilient system and more like a science fiction villain.

Destroy the brain.

Destroy reality.

Not ideal.

So the design evolved toward distributed supervision and evidence aggregation.

Now there is no all-knowing controller.

Just multiple observers comparing notes and trying to determine whether the system is healthy or merely pretending to be healthy.

Phase 4: Circuit Quarantine Meets Recovery

The system had quarantine.

I was very proud of quarantine.

Failed circuits could be isolated.

Traffic could be redirected.

Damage could be contained.

Then somebody asked:

How does the circuit come back?

Silence.

Because I had successfully designed software prison.

A circuit could leave.

It just couldn't return.

So recovery became:

Replay events
Rebuild state
Verify integrity
Pass health checks
Gradually restore traffic

Basically:

circuit probation

Failure → Quarantine → Replay → Re-Admission

Phase 5: Isolation vs Roommates

The architecture proudly claimed:

Single Process + Isolated Circuits

Which sounds impressive until you remember:

same memory
same CPU
same runtime

So the isolation is not physical.

It's behavioral.

In reality it's more like:

everyone lives in the same apartment, we just politely asked them not to destroy each other's furniture.

It works.

Right up until somebody starts consuming all the CPU.

Phase 5.1: The Space Shuttle Model

This is where the idea finally clicked in my head.

I stopped thinking about software.

I started thinking about spacecraft.

A space shuttle doesn't assume nothing will fail.

It assumes failure is possible.

So when components complete their purpose or become problematic, they detach.

Boosters separate.

Sections isolate.

The mission continues with reduced capability rather than immediate destruction.

That became the mental model:

What if software could detach failure domains instead of letting them spread?

Not physically.

Not literally.

But logically.

A damaged component shouldn't immediately drag the rest of the system down with it.

Figure: Space Shuttle-inspired fault detachment model. Failed components are isolated while healthy components continue operating with reduced capability.

Phase 6: Negotiating With Failure

At some point the architecture started fighting back.

Every fix revealed a new weakness.

Every weakness exposed another assumption.

Every assumption uncovered another failure mode.

Eventually I stopped designing architecture.

I started negotiating with reality.

Which, in hindsight, is probably the most accurate description of software engineering I've ever heard.

The Final Boss: Idempotency

After all the revisions, one idea survived.

The system should not assume truth.

It should derive truth from evidence.

supervisors don't declare reality
circuits don't claim health
recovery isn't assumed

Everything has to prove itself.

And still, every version of the architecture eventually collapses into one terrifying question:

What happens if the same event is processed twice?

Not architecture.

Not diagrams.

Not consensus.

Reality.

Because correctness doesn't live in architecture diagrams.

It lives in boring details like:

idempotency
retries
ordering
state transitions

The exact things nobody puts on conference slides because they're too busy drawing arrows.

Final Thoughts

Kinetic Circuit Architecture is not a framework.

It is not a proposal.

It is not a replacement for existing systems.

It is simply the result of repeatedly asking:

What happens if this fails?

And then refusing to stop asking.

The more I explored failure containment, the more I realized something:

Most systems are not designed to be perfect.

They're designed to survive.

Long enough for somebody to debug them later.

Preferably not you.

Preferably not at 3:00 AM.

Nobody Cares About Your System Design. Think Like a Customer or Stop Coding.

Sarthak Shrestha — Fri, 05 Jun 2026 07:03:36 +0000

The Lie Developers Tell Themselves

Developers, Engineers, Architects — What are they developing for?

Sometimes it doesn't even feel like it's for the customer.

It becomes about ego. About proving intelligence. About showing you can design, scale, and optimize things that don’t even exist yet.

I’ve seen developers obsessed with becoming “the best”—memorizing articles, grinding LeetCode, collecting system design patterns like trophies.

But at the end of all that, what did it prove?

Nothing.

Just a lot of technical knowledge with no connection to real outcomes.

I’ve also seen teams proudly present “perfect architecture documents” while the actual product struggles in production.

And that gap keeps showing up again and again:

What engineers build vs what users actually need.

And that gap is where products quietly fail

Reality

Most engineers end up building systems with overly sophisticated architecture. It is filled with system design jargon which sounds impressive but does not achieve anything at all.

But many of these systems still fail where it matters most: production.

Meanwhile, simpler systems—designed carefully with focus on correctness and reliability—tend to hold up better under real-world conditions.

The difference is not intelligence. It is focus.

One is optimized for complexity on paper.

The other is optimized for systems that actually work.

What Customers Actually Want

Customers don't want to see how you did it.

Let me put it simply.

When a car comes out of the factory, the customer does not care about how the engineering was assembled or how the wiring was routed. They care whether the car it starts or drive.

In software, it’s the same thing. Users only care about what they experience:

Success or failure
Delays
Missing data
Broken workflows
Double charges Everything else is internal detail.

Your meetings might talk about microservices, caching layers, distributed databases, and all kinds of system design complexity—but the user doesn’t see any of that.

They only see whether the system works.

If your architecture is perfect but the user gets charged twice, then the system has failed.

Build for outcomes, not infrastructure.

Customers pay for problems to be solved, not for architecture discussions that sound impressive in a meeting room.

The Illusion Developers Fall For

System design becomes an imaginary shield when developers cannot clearly explain how they would solve a problem in simple terms.

In interviews, this shows up the most. Ask system design, and people start speaking like they are building global-scale systems for problems that don’t exist yet.

The main problem is architecture buzzwords, they don't start with:

What does the customer actually need?
What is the simplest way to make it work reliably?

Software development is not a closed-book exam. You don't need to memorize to remember the patterns to prove you are exceptionally smart.

Understand the core idea first.

If you get stuck, break it down into simple language. Use tools if needed. Read documentation. Think clearly.

Then build something that works.

Not something that sounds impressive.

Stop building monuments to your own ego.
Build software that actually works for the human using it.

The Day I Realized Nobody Cares

Today, I had a realization:

Developers love saying things like:

"Our abstractions weren't correct."
"The architecture wasn't scalable."
"The service boundaries were wrong."

Hold on, the customer didn’t ask for a TED talk on how to be great talker.

They asked:

Why is the database down?
Why didn’t the page load?
Why was I charged twice?
Where is my order?

Nobody is asking for dependency injection explanations.

Calm down, Einstein.

Your system is down.
Users are stuck on loading screens.
Support is drowning.

And what are you doing now, you’re discussing architecture. Users don't see architecture.

They see whether the thing works.

Business reality hits engineering ego when clients say:

“We need a page that shows invoices.”

The developer response would be:

“Kubernetes, microservices, event streaming, distributed systems.”

Hold on.
That’s not a NASA launch.
That’s a page.

Plumber with an aircraft carrier.
Flashlight turned into a nuclear reactor.

Wrong scale.

Stop. Ask yourself: What problem are we solving?

Customers don’t pay for architecture. They pay for outcomes. For example:

If the Page loads correctly or not.
If the Payment works.
If the Invoice shows without data loss.
If Report generates properly or not.

Everything else is noise.

I’m not against overengineering. It’s useful for learning.
But production is not a lab.
Every extra layer costs something.
Complexity is not free.
Most engineers can build complex systems.
Fewer know when not to.
Simple that works beats complex that “looks right.”

Customers Don't Buy Architecture

What do customers actually buy?

Not architecture
Not programming language.
Not databases.

They buy outcomes.

Clients want results.

They don’t care how you built it. They care whether it works.

Overengineering might feel smart, but in production it often turns into technical debt.

This mindset gets worse in interviews.

We stop solving problems and start designing “Netflix at scale.”

CDNs, microservices, distributed pipelines, multi-region replication…

For something that usually starts with one requirement:

“Press play and the video should start.”

We are not building Netflix.

We are building a feature that plays a video.

But we design it like we’re running a global streaming platform from day one.

The System Design Trap

Developers slowly become architecture collectors.

They start collecting patterns like trophies:
microservices, CQRS, event-driven systems, distributed caching, service meshes.

Not because the problem needs it—but because it looks “senior”.

Buzzwords replace business value.

Simple feels junior. Complex feels intelligent.

So complexity becomes a status signal, not a technical decision.

But complexity doesn’t prove intelligence.

It just increases failure points.

And when production breaks, nobody cares how sophisticated the architecture was.

They just want it fixed.

What customers actually Ask.

One thing: when will this be ready?

They don’t ask:

What programming language are you using?
What system design pattern are you following?
What architecture did you choose?

They ask things that affect them directly:

When will it be done?
Why was I charged twice?
Why is my data missing?
Why is this feature broken?

Customers don’t evaluate systems.

They experience outcomes.

The Difference Between a Developer and an Engineer

The main distinction is scope and intent.

A developer focuses on implementation.

An engineer focuses on outcomes.

A developer builds the application. An engineer thinks about how the system behaves under real conditions—performance, failures, scale, and reliability.

Business impact matters because you are paid to solve a problem, not guess it.

Customers are not paying for telepathy. They are paying for results.

What they care about is simple:
Does it work?
Does it stay working?
Does it fail safely when it breaks?

Everything else is internal detail.

The Questions That Matter More Than Architecture

Real systems don’t fail cleanly. They fail in messy, partial, expensive states.

So the real questions are not about architecture diagrams. They are about failure:

What happens if a request is retried?
What if it succeeds but the response crashes?
What if only half the workflow completes?
Can money move twice?
Can data silently disappear?
How do we recover when the system is already wrong?
How does support even figure out what happened?

These aren’t edge cases.

These are everyday production problems.

If you don’t answer them, architecture doesn’t matter.

A Real Example: Payment Systems

A customer clicks “Pay”.

But engineers design around scale, queues, retries, and distributed systems.

At some point I realized, the problems are simpler and harsher:

payment succeeds but response fails
retry causes double charge
system thinks it failed when it didn’t
reconciliation is needed to fix reality

That’s why idempotency exists.

Not for interviews. Not for buzzwords.

Because systems fail in messy ways.

Customers don’t care about architecture.

They care about not being charged twice.

The Most Valuable Skill Nobody Talks About

Developers often wait for requirements and jump straight into coding without understanding the “why”.

Before writing code, you should ask:

Why are we building this?
Who is it for?
What does the customer actually understand or care about?
What business problem are we solving?
What does the user expect when they interact with it?

Because if you don’t understand the context, you’re not building a solution—you’re just writing code against instructions.

And instructions alone don’t guarantee the right outcome.

When System Design Actually Matters

System design is not useless. It is a tool, not a goal.

It matters when it helps solve real customer problems—reliability, scale, failure handling, and recovery.

Good architecture supports good outcomes.

But developers often overexplain and overengineer systems that don’t need that level of complexity.

The result is architecture for its own sake, not for the customer.

The Other Extreme Is Dangerous Too

Ignoring architecture completely creates a different problem.

If every feature is built only for today's requirement, systems eventually become difficult to maintain.

What starts as speed turns into friction.

New features take longer.
Bug fixes become harder.
Simple changes require touching half the codebase.

Eventually the customer feels that pain too.

Good architecture is not about showing off.

It is about keeping the system understandable, maintainable, and reliable as it grows.

The goal is not "no architecture."

The goal is the right amount of architecture for the problem you actually have.

Stop Building for LinkedIn

A lot of software today isn’t built for users.

It’s built for screenshots.

Architecture diagrams that look impressive.
Buzzwords that sound senior.
Design decisions optimized for resumes, not reliability.

Microservices added before the product has users.
Distributed systems designed before the problem is real.

It stops feeling like engineering and starts feeling like performance.

But users don’t see any of that.

They only see whether the system works or breaks.

Start Building for Reality

Real systems aren’t judged by how elegant they look in a diagram.

They’re judged by what survives when things go wrong.

Reliability means the system still works under pressure
Recoverability means failures don’t become permanent damage
Observability means you can understand what broke
Auditability means you can trace what happened
Simplicity means fewer ways to fail

These are not advanced concepts.

They are survival requirements.

Everything else is secondary.

The Customer Is the Final Architecture Review

The customer never sees your architecture. They only experience the result.

A complex system that delivers a bad experience is still a failure. A simple system that reliably solves the problem is a success.

One thing I've learned about good architecture:

The best systems are usually the easiest to explain.

If a new developer can understand how the system works in ten minutes, that's usually a good sign.

If it takes an hour of diagrams, buzzwords, and architectural archaeology to understand a simple feature, something probably went wrong.

Most great systems are built from hundreds of simple decisions made consistently over time.

Good architecture is not complexity.

Good architecture is clarity.

The Bottom Line

Customers don't buy architecture.

They don't buy technology.

They don't buy engineering.

They buy outcomes. Not systems.

Productive Avoidance - How Developers Stay Comfortable and Lazy Without Building Anything

Sarthak Shrestha — Tue, 02 Jun 2026 14:25:53 +0000

Introduction

Let’s paint a picture of an upcoming developer.
A developer who has watched 50 tutorials like they're binge-watching a Netflix series because the last tutorial "didn't explain it properly."

A developer who solved 800 LeetCode problems because their favorite tech influencer got into their dream company and somehow convinced them that dynamic programming is the missing piece of their personality.

A developer who talks about system design like they’ve personally built Google, AWS, and NASA in their spare time—every diagram, every theorem, every buzzword stored like a search engine running on caffeine.

But the moment that developer opens an IDE (Integrated Development Environment), the mind goes into freeze mode.

How?

Blank file.

Blank screen.

Own idea.

No instructor.

No guided project.

No problem statement handed to that developer.

Silence.

That developer does not spend minutes. That developer spends days pondering:

Should I do this?

Should I do that?

What should I have done in the past?

Maybe if I had eaten something different three years ago, this project would already be finished.

This is not a story about intelligence.

This is not a story about talent.

This is a story about a developer who spent years studying programming and never once actually did it.

And the worst part?
That developer felt productive the entire time.
This is productive avoidance.

And it is everywhere.

Productive Avoidance or Being Lazy

Productive avoidance — not going to start with some textbook definition because developers already have 17 bookmarked articles they will never read. It’s when people focus on low-priority and easy tasks that make them feel productive without actually doing meaningful work.

Suddenly, organizing folders, changing IDE themes, watching “How I Stay Productive as a Programmer” videos, and renaming files from project_final to project_final_final_v2 become very highly important and and sought-after tasks.

From the outside, it looks like they are building a satellite system solo for NASA with 14 tabs open and dramatic keyboard sounds. In reality, after eight hours of “hard work,” the biggest achievement is still:

print("Hello World")

The developer goes to Instagram and posts about what they did for the next 8 hours.

Deep down, that developer feels a post-battle relief, but honestly, they didn’t achieve anything at all.

That developer feels so amazing at completing nothing that they gloat like they just saved the whole world production system.

Tutorial Hell: Where “Just One More Video” Turns Into a Full-Time Lifestyle (and the Developer Becomes a Certified Advanced Procrastinator)

Tutorial Hell, which we once proudly called a “learner’s paradise,” is actually just productive avoidance in disguise. We’ve all been there—stacking tutorials like achievements, convincing ourselves we’re one video away from being “ready.” At some point, we stopped watching and started building. That’s when we got out.

The second they hear, “Let’s start with tutorials, guys—I’ll make you job-ready,” their ears perk up like puppies hearing the word “walk.”
Then the tech influencer cycle begins.

One influencer says:

“Rust is the future.”

Suddenly developers are installing Rust at 2 AM like their current tech stack personally insulted their bloodline.

Another influencer uploads:

“Why JavaScript is dead?”

Half of the frontend community is having a midlife crisis before their CSS even finishes loading, and the page is still just white with emotional damage.

One video later:

“Top 7 System Design and Backend Topics You MUST Know”

“I talked to a tech recruiter…”

Which is developer translation for:

abandon everything you’ve learned and begin again from zero.

It ends with “like and subscribe,” and you’re left thinking:

Congrats, you just attended a career reset disguised as a YouTube video.

You just spent 30 minutes doing absolutely nothing—except convincing yourself you’re now 3 frameworks behind.

At some point, you stop needing another tutorial, another roadmap, another “top 10 things to learn.”

You already have enough information to start.

What you don’t have is something built.

So open the IDE. Not to learn. Not to prepare.

But to build something badly enough that it becomes real.

Because no tutorial, no LeetCode problem, and no system design video will ever replace that moment.

Framework Jumping: Expert-Level Tutorial Researcher, Professional Project Abandoner

Framework jumpers — the absolute risk-takers of achieving something while somehow not achieving anything. Yeah, We see you. Come out. We need to talk and maybe provide professional help at this point to reinstall your reality. These are the developers who believe learning fundamentals is a horror movie they never want to watch, but somehow still believe everything is completely fine.

In Nepali, we call them:

“Bichitra prani.”

Literal translation:

“Strange creature.”

Developer translation:

“A lifeform that installs new frameworks to avoid finishing projects.”

Every month, a new framework appears.

And suddenly thousands of developers act like their current stack personally betrayed their family lineage.

So they migrate again.

Not because the old framework stopped working.
But because starting over feels better than finishing.

At this point, some developers have switched frameworks so many times their GitHub looks less like software engineering and more like emotional damage with syntax highlighting.

Starting over feels productive because unfinished projects cannot fail —they just disappear quietly.

The architecture is still “clean.”

The code is still “full of potential.”

Nothing is broken yet.

Finishing the project would require facing reality.
And reality doesn’t care how many frameworks you installed at 2 AM—it only cares whether anything actually works when it matters.

LeetCode Grinding: A step-by-step program designed to make developers unbelievably good at passing interviews, and unbelievably aggressively confused when asked to build something without a problem statement.

LeetCode grinders — nature’s finest problem solvers in environments where only problems exist.

Ask them about their favorite football team and they’ll freeze. Ask them about DP or arrays, and they respond like a machine that just woke up and chose violence.

The problem is not that the Leetcode exists. The problem is people using it to feel productive without building anything real, like a hamster on a wheel convincing itself it’s going somewhere.

The core issue is that they grind LeetCode, watch tutorials, and jump frameworks just to convince themselves they’re becoming a developer—without ever actually building anything that exists outside their head.

Watching tutorials feels safe.

Solving problems feels controlled.

Switching frameworks feels like progress.

But none of it is building.

Programming is not what you watch.

It is not what you solve.

It is what survives when no one is guiding you.

Open the IDE.

Pick something.

Build it badly.

Finish it anyway.

The Purist Trap — ego protection disguised as “standards” and fear of frameworks.

Purist developer— the one who believes frameworks are not required because everything is already in the language.
The developer uses pen and paper for coding, so he can experience every bug personally, like it’s a premium feature instead of a mistake.
Then posts an Instagram story proudly announcing “shipping,” while nothing ever leaves the notebook except hand-drawn regret.
Version control? The developer says, “I didn’t hear that word.” Real engineers can read their own past changes like telepathy. If this developer tries it, the client would leave the contract and he’d start a telepathy startup.

Frameworks? “Personally offended.”
Databases? “What base? I don’t even trust land anymore.”
Debuggers? Never heard of it—sounds like something the system installs when it has lost all respect for you.

This developer doesn’t dislike where things are going… he just refuses to accept that there is any “going” in the first place.

Then it’s always the same ending:

“It works on paper.”

Or the upgraded version:

“It works on my paper.”

Which translates to:

“It runs perfectly in the only universe I have access to.”

And then reality does what it always does.
It ignores the paper completely.
Because production does not care about philosophy—it only runs code.

The Interview Olympics of Nothing That Ships

Many developers go through interviews thinking they should have prepared better to get the job. But when they get obsessed with solving problems under artificial constraints, they end up proudly boasting about what they did in interviews.

On YouTube, a tech influencer says: “Hey guys, I solved 900 problems,” which basically means:

I am extremely good at solving problems that don’t exist in production, and my brain will freeze the moment real system errors appear.

Most influencers say in interviews you should study this or that to get into companies.
This feels like training for the Olympics—you get a gold medal in preparation, but after 5 rounds of interviews you get pure unfiltered disappointment and self-doubt instead.
Sometimes interviewers ask the weirdest questions, like they are preparing you for an entry-level dev role or secretly testing you for a “next CEO of the company” position just to justify salary budgets.
They ask fundamentals like you are supposed to remember every line of code you have ever written, as if your brain is a free memory bank.
For example, if a database call fails, they expect answers like “partial write scenario,” which sounds intellectual but just means something broke and needs fixing.

Let’s talk about company work—the pure aesthetic chaos of management that can ruin your mood in under a second. They expect you to read minds. Developers should be able to say: “I am not a mind reader. I know how to write code. If you want code, write proper documentation. Don’t say ‘the internet was down for today’ and expect me to understand the system.” And also don’t give the classic excuse: “just ask AI.” Who does that? Did you go to a dentist and refuse to explain what hurts?
Interviews test how well you perform under artificial pressure. Production tests whether your system survives reality—retries, chaos, silent failures, and everything breaking at the worst possible time.
And yet we pretend these are the same skill. They are not. One is solving puzzles. The other is surviving a broken system that still expects SLA compliance.

The Connective Tissue

Tutorial Hell → Collecting tutorials like a hoarder stacking empty food containers; "meal prep for the future" while never cooking a single meal.
Framework Jumping → The ritual of abandoning projects right before they demand responsibility; swapping identities to stay "relevant."
LeetCode Grinding → Perfecting the art of solving puzzles that don't exist in production, while your actual building muscles atrophy from lack of use.
The Purist Trap → Reinventing a broken wheel and calling it "architecture" instead of admitting you just built suffering with extra steps.

The ending or start of becoming true developer

The beginning of becoming a real developer is simple—you open the IDE and just sit there staring at a blank file like it’s judging you for everything you don’t know yet. No tutorial, no guide, no one telling you what to do next, just silence and a blinking cursor. After everything you’ve learned, you still don’t really know how to start, so you type something simple, break it, fix it, and run it again until it stops feeling like theory and starts feeling like something real.

Over to you...

We’ve all been the “Bichitra prani” at some point—installing a new framework at 2 AM to avoid fixing a bug in a project we started in June.

What is one project you’ve abandoned that you’re going to open again today? Or, what’s the "ugliest" thing you’ve ever built that actually worked?

Let’s celebrate our "badly built" projects in the comments below.

What LeetCode Optimizes For vs What Actual Production Systems Demand

Sarthak Shrestha — Fri, 08 May 2026 01:58:40 +0000

LeetCode vs actual systems: what are we really optimizing for—and what are we compromising on? Are we shaping how we think as engineers, or just adapting to artificial pressure and artificial problems? More importantly, are we shaping how this generation learns programming—where building projects starts to feel like memorizing patterns instead of solving real problems?. If that’s true, why does every project start to feel like a test? Why does looking things up feel like cheating? Are we afraid of overdependence on tools—or have we been conditioned to believe that real skill has to come from memory?. The honest answer is: we're getting better at solving these problems, but that doesn't always translate into building real systems.

The Controlled Environment: What LeetCode Teaches

LeetCode is designed to evaluate problem-solving in a controlled environment, where the input is known, the constraints are fixed, and the solution is expected within a limited time window. Instead of exploring problems, we start searching for patterns. Instead of understanding systems, we try to match them to something we've already seen. Over time, programming starts to feel less like problem-solving and more like pattern recall. This creates a system where success depends on how quickly and accurately you can solve a well-defined problem under constraints. But production systems operate in a completely different environment—where problems are not defined upfront, and correctness must hold even as inputs, state, and system behavior change over time.

The Reality of Production: Systems Under Stress

Case Study: When State Cascades

Production systems require solving problems where behavior isn't predefined—you discover it by observing the system. In the Knight Capital trading glitch, the company lost $440 million in 45 minutes because an untested state path cascaded through a live system.

For example, Imagine walking through a shop. You see there are many workers, yet the service is still slow. At first glance, the problem seems simple. But what is the real issue? Is it inefficient workers? A slow billing system? Poor organization of inventory? Too many customers arriving at once?
The problem is not clearly defined—you have to figure it out. This is the difference. LeetCode trains you to solve well-defined problems. Real engineering requires you to identify, define, and then solve problems in systems that are already running.

Production systems do not present clean, well-defined problems. They operate in environments where behavior is partially unknown, failures are expected, and correctness must hold over time rather than at a single moment of execution. Unlike LeetCode, you are not given a complete specification. You start with symptoms, not solutions. In real-world engineering, this often begins with understanding what users are experiencing—what is slow, inconsistent, failing, or missing in the system. From there, the actual technical problem must be identified, narrowed down, and clearly defined before any solution can be built.

But figuring out the problem is just the beginning. The hard part is keeping the system correct as it evolves over time.

The Idempotency Factor

In the production systems, correctness is not guaranteed by single successful executions. Operations often retry due to network timeouts, client failure or service unavailability. This means that the same request can be processed more than once. If the system does not handle system deduplication, a single user action can result in duplicate state changes which would break system correctness. This is why the production system relies heavily on idempotency so that correction holds across repeated execution. A simple example: user clicks Pay → request times out → client retries → same request hits the server twice → duplicate charge unless an idempotency key exists.

When a request is processed, completion is not guaranteed throughout the entire system. A single operation may involve multiple services, each executed independently. One service can succeed while another could fail which can lead to partial execution and inconsistent state.

As systems scale, failures also stop being isolated. A delay in a dependency can consume shared resources like thread pools or database connections, affecting unrelated requests that affect the user base. Retry mechanisms can amplify this load instead of fixing it, leading to continuous failures across services. Small issues start to become system-wide problems throughout these dependency chains. Retries can turn into retry storms, overwhelming shared resources instead of recovering from failure.

The Psychological Shift: Pattern Matching vs Discovery

This is not just a system problem — it shapes how the engineers are learning to think. When preparation is dominated by pattern based solving this shows a subtle shift in mindset. Problems begin to feel like recognition tasks rather than discovery tasks. The ability to search on the internet starts to feel like a weakness. Building without a predefined solution starts to feel like failing an imaginary volunteered internal test that an engineer does not want to take but has to take it due to impostor syndrome.

Since the introduction of AI (Artificial Intelligence) or LLM(Large Language Models), it helps remove the need of memorizing patterns. However, this introduces something uncomfortable. If your skill is only dependent on recalling solutions every time, AI replaces you. If your skill depends on understanding systems, AI becomes just another tool for your hands.

However, LeetCode is not actually useless, it helps engineers build algorithmic thinking, structured problem under constraints and interview readiness. It represents a useful subset of engineering skill that only represents one type of environment: controlled, deterministic and fully specified.

Conclusion: Algorithmic Thinking is a Tool, Not the Goal

The difference isn't LeetCode vs production. It's understanding what each one trains you for. One trains you to solve problems quickly under constraints. The other trains you to define problems and maintain correctness under uncertainty. Real engineering starts when the problem isn't given to you—and doesn't stay solved.