DEV Community: Sarthak Shrestha

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.