DEV Community: Preeti yadav

From NEET Aspirant to Writing Code: A Journey I Never Planned

Preeti yadav — Mon, 09 Mar 2026 04:12:46 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

If someone had told me a few years ago that I would be writing code and leading developers, I probably wouldn’t have believed them.
Because my journey into tech wasn’t planned at all.

I actually started in a completely different direction.

A Different Dream

I studied in the medical stream until 12th grade. Like many students in India, my goal was to clear National Eligibility cum Entrance Test and pursue medicine.

During the COVID period, I joined a coaching institute to prepare for the exam. That phase of my life was intense.

Our routine looked something like this:

Early morning classes
Self-study the entire day
Practice tests regularly
Studying late into the night
Sometimes we studied until 3 or 4 in the morning.
And Sundays weren’t holidays. Sundays were test days.
It was exhausting, but I was determined.
I gave it everything I had.

When Things Don’t Go As Planned

Despite all that effort, I didn’t clear the exam that year.
Around that time, my health also started affecting my preparation, and I eventually came back home earlier than expected.

It felt like a huge pause in my life.
For the first time in a long time, I didn’t know what the next step was supposed to be.

Discovering Coding (Completely by Accident)

One day while scrolling through YouTube, I came across videos about programming.

The idea that caught my attention was simple:

“Coding is becoming a fundamental skill. Everyone should at least know the basics.”

Out of curiosity, I decided to try it.

I had zero background in tech.

No computer science classes.
No programming knowledge.
No idea what developers even did daily.

But something about it clicked immediately.

Realizing I Learn Fast

Once I started learning, I realized something about myself: I learn technical things very quickly when I’m curious about them.

I spent hours learning from tutorials, building small things, and experimenting.

The same discipline I used while preparing for medical exams helped me here too.

Late nights of studying weren’t new to me.
Except this time, instead of biology diagrams, I was debugging code.
And slowly, things started moving faster than I expected.

Moving Faster Than I Thought

Within a relatively short time, I started gaining confidence in development.
I worked on projects, collaborated with others, and kept improving.

At one point, something surprising happened:
I started performing better than people who had started before me.
Eventually, I even became a team lead, guiding other developers.

It was a moment where I paused and thought:
“How did someone who didn’t even know coding existed a short time ago end up here?”

What This Journey Taught Me

Looking back, the path seems unexpected, but the lessons are clear.

First, your starting point doesn’t define your destination.
I came from a medical background, yet found my place in tech.

Second, discipline transfers across fields.
The study habits I built during my exam preparation helped me learn programming faster.

And finally, curiosity can completely change your life.

One random YouTube video was enough to open a door I didn’t even know existed.

A Thought for Anyone Starting Something New

If you’re someone switching fields or starting late, remember this:

You don’t need the perfect background to succeed in tech.
Sometimes all you need is curiosity, persistence, and the willingness to keep learning.

Your journey might not look like everyone else’s.

And that’s perfectly okay.

Unsaid: Turning Reactive Messages Into Intentional Conversations

Preeti yadav — Sun, 01 Mar 2026 12:24:50 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I built Unsaid for people who struggle with difficult conversations — especially those who think in drafts before they speak.

This includes:

Developers who overthink messages before sending them
People holding onto unresolved conversations
Anyone who has typed something in anger… and then deleted it
People who want to communicate better but don’t always know how

In many communities (tech teams, relationships, friendships), conflict isn’t the biggest issue — unclear communication is.

We measure productivity.
We track commits.
We optimize workflows.

But we rarely optimize how we speak to each other.
Unsaid was built for that gap.

What I Built

Unsaid is a minimal web app that transforms emotionally reactive messages into intentional, emotionally intelligent communication.

Users:

Write a message they never sent.
Select the emotional intent (Closure, Forgiveness, Gratitude, Assertiveness, Boundaries).
The app rewrites the message using healthy communication principles.
It explains what changed (e.g., removing blame, adding ownership language).
This is not a grammar corrector.
It’s a reflection tool.

It helps convert:
“You always ignore me.”
into
“I feel unheard when our conversations don’t feel reciprocal.”

The goal isn’t to generate perfect messages.
The goal is to help people move from reaction → reflection.

Demo

🔗 Live App:

unsaid-psi.vercel.app

Try inputting:
You never listen to me and you always make decisions without asking.

Switch between different intents and observe how tone shifts.

Code

GitHub Repository: https://github.com/preeti-3/unsaid.git

The project is structured using:

Next.js (App Router)
TypeScript
Tailwind CSS
API route for transformation logic

The transformation layer applies assertive communication principles:

Removes generalizations (“always”, “never”)
Replaces blame with ownership statements
Clarifies emotional needs
Maintains emotional honesty

How I Built It

Frontend

Built with Next.js App Router
Minimal UI using Tailwind CSS
Calm, neutral design to encourage reflection
Emotion selector component to guide tone
Backend
Server-side API route to process transformations
LLM-powered rewriting logic

Structured prompt design focused on:

Emotional maturity
Assertive communication
Constructive tone
Design Philosophy

The interface intentionally avoids:

Social features
Public sharing
Gamification
Unsaid is designed to feel like a quiet room — not a social platform.

We use AI to write code, essays, and marketing copy.
What if we used it to write better conversations?

Unsaid explores whether technology can help us communicate with more clarity — and less regret.

Can a Web App Carry Philosophy? Building a Devotional Platform with Next.js

Preeti yadav — Thu, 19 Feb 2026 05:07:39 +0000

Most side projects solve a problem.

This one tried to create a feeling.

I built Sarathi, a devotional self-growth platform inspired by the Bhagavad Gita. The goal wasn’t to create another content website with verses and explanations. I wanted it to feel immersive — heavy, intentional, almost cinematic — like standing in Kurukshetra before wisdom is spoken.

Here’s how I approached it technically.

The Core Challenge

The real problem wasn’t displaying 700+ verses.

It was:

How do you structure large static spiritual content without turning it into a cluttered blog?
How do you design for emotional immersion without sacrificing performance?
How do you balance sacred minimalism with modern UI expectations?

Designing for Immersion (Not Just UI)

The biggest design decision:
I didn’t want it to look like a SaaS dashboard.

Most content platforms are:

White background
Card layout
Clean but emotionally neutral

But this subject demands weight.

So I focused on:

Restrained color palette
Depth-based layering
Intentional spacing
Minimal but strong typography

The challenge was resisting over-design.

Too many images → it becomes decorative.
Too much minimalism → it becomes sterile.

The balance is still evolving.

Performance Considerations

Handling hundreds of static entries taught me:

Structure first, UI later.
Static generation is powerful when content is stable.
Data normalization prevents chaos when scaling.
Avoid over-fetching — precompute what you can.
Even content-heavy apps can feel instant if architected properly.

What I Learned

Designing for emotion is harder than designing for usability.

Content-heavy apps require discipline in data modeling.
Cultural / philosophical projects can be strong portfolio pieces — if built with engineering clarity.
A project with meaning pushes you further than a tutorial clone ever will.

What’s Next

Stronger atmospheric visuals (fog layers, textured backgrounds)
Emotion-based search
Daily verse system
Optional immersive mode vs minimal mode
Audio integration

The goal isn’t just to build a website.

It’s to build an experience where technology carries philosophy.

If you’re curious, here’s the live project:
👉 https://sarathi-eta.vercel.app/

Would love feedback — especially on architecture and immersion balance.

Explain-Error CLI – Making JavaScript Errors Beginner-Friendly

Preeti yadav — Mon, 16 Feb 2026 07:38:27 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built a small but practical CLI tool called Explain-Error.

It takes confusing JavaScript error messages and converts them into simple, beginner-friendly explanations.

If you've ever seen something like:

TypeError: Cannot read properties of undefined

And thought:

"Okay… but what does that actually mean?"

This tool translates that into:

You're trying to access something on a variable that is undefined.
Make sure the variable has a value before using it.

As someone who teaches and mentors students, I’ve seen how intimidating error messages can be for beginners. This project is something I genuinely wish existed when I first started coding.

It’s small.
It’s focused.
And it solves a real learning pain point.

Demo

My Experience with GitHub Copilot CLI

This is where the real magic happened.

Instead of switching between browser tabs, documentation, and StackOverflow, I stayed entirely inside my terminal.
Here’s how I used GitHub Copilot CLI:

Generating the Initial Structure

I asked Copilot to:
Create a Node.js CLI tool that explains common JavaScript errors in simple language.

It generated a solid pattern-based detection system using regular expressions — something that would’ve taken me significantly longer to structure cleanly from scratch.

Streaming & Suspense in Next.js: Why Your App Feels Slow (Even When It Isn’t)

Preeti yadav — Mon, 16 Feb 2026 07:00:01 +0000

Most developers think their app is slow because of the backend.

In reality, a lot of apps feel slow because of how we render them.

You’ve seen it:

Blank screen.
Then everything appears at once.
Or worse — layout shifts everywhere.

That’s not always a data problem.
That’s a rendering strategy problem.

With the App Router in Next.js, Streaming and Suspense fundamentally change how users experience loading. And once you understand it properly, you’ll never build dashboards the old way again.

Let’s break it down properly.

The Real Problem: Traditional Rendering Blocks Everything

In classic SSR:

Server fetches all data.
Waits for everything to resolve.
Generates full HTML.
Sends it to the client.

If one API call is slow, the whole page waits.
Even if 80% of the UI is ready.
That’s inefficient.

Users don’t need everything at once.
They need something fast.

That’s where streaming comes in.

What is Streaming in Next.js?

Streaming allows the server to send HTML to the browser in chunks instead of waiting for the entire page to be ready.

Instead of:

Wait → Render → Send

It becomes:

Render what’s ready → Send → Continue rendering → Stream more

This is supported natively in the App Router.

The browser starts rendering immediately, and slower parts of the UI are filled in later.
Perceived performance improves dramatically.

And perceived performance is what users care about.

Where Suspense Comes In

Streaming alone isn’t enough.
You need boundaries.

That’s where React Suspense comes in.
Suspense lets you define which parts of the UI can “wait” independently.

Example:

import { Suspense } from "react";
import SlowComponent from "./SlowComponent";
import FastComponent from "./FastComponent";

export default function Page() {
  return (
    <div>
      <FastComponent />

      <Suspense fallback={<p>Loading analytics...</p>}>
        <SlowComponent />
      </Suspense>
    </div>
  );
}

Here’s what happens:

FastComponent renders immediately.
SlowComponent fetches data.
While it loads, fallback UI is shown.
When ready, it streams into place.
The rest of the page does not wait.
That’s powerful.

Real-World Example: Dashboard Scenario

Imagine a dashboard page:

User profile → fast query
Notifications → medium query
Analytics chart → heavy aggregation

Without streaming:
👉 Everything waits for analytics.

With streaming + Suspense:

Profile renders instantly.
Notifications appear shortly after.
Chart loads last with a proper fallback.
User feels speed.

Even if total load time is identical.
That’s the difference between technical performance and perceived performance.

How Next.js Makes This Even Better

In the App Router:

Server Components are streamed by default.
Each route segment can have a loading.js.
Suspense boundaries control how chunks are streamed.
No extra configuration required.

Example:

app/dashboard/loading.js

This automatically acts as a Suspense fallback for that route segment.
You don’t have to manually wire everything.

Important: Streaming is a Server-Side Concept

This is where many developers get confused.
Streaming happens during server rendering.
It is not the same as client-side lazy loading.
Suspense inside Client Components behaves differently than in Server Components.

If you use "use client" everywhere, you reduce the benefits.
Let the server do the heavy lifting whenever possible.

Common Mistakes I See

❌ Wrapping the entire page in one Suspense
This defeats the purpose. Everything still waits together.

❌ Adding too many Suspense boundaries
Over-fragmenting UI creates janky loading experiences.

❌ Ignoring fallback UX
A spinner is not always the best fallback. Skeletons often feel better.

❌ Thinking Streaming replaces caching
It doesn’t. Caching and streaming solve different problems.

Why This Actually Matters

Most developers optimize for Lighthouse scores.
But users don’t see metrics.

They feel:

How fast something appears.
How stable the layout is.
How interactive the page feels.
Streaming + Suspense directly improves that perception.

And that’s what good frontend engineering is about.
Not just shipping components.

Designing experience.

Final Thoughts

When I first used Streaming in Next.js, I realized something:
We’ve been thinking about rendering too rigidly.
Pages don’t need to load like monoliths.
They can load like conversations — piece by piece.

The App Router isn’t just a routing update.
It’s a mental model shift.

If you’re still building pages that wait for everything before showing anything, you’re leaving performance (and UX) on the table.

Start thinking in boundaries.
Start thinking in chunks.
And let the server stream.

If you found this useful, I’d love to hear how you’re using Suspense in your projects.

The Consistency Era Begins — Why Showing Up Daily Changes Everything

Preeti yadav — Mon, 27 Oct 2025 05:16:48 +0000

There’s a moment in every developer’s journey where you stop chasing “perfect” and start chasing progress.

For me, that moment starts today.

Over the past few years, I’ve worked with React, Next.js, NestJS, Prisma — built systems, taught students, led teams, and learned that no line of code matters if you stop showing up.

Perfection used to hold me back.
“I’ll post when my project is perfect.”
“I’ll share when I learn everything.”

But the truth is — perfection never comes. Consistency does.

Every day you share, code, write, or teach, you’re not just improving your skills; you’re building yourself.

So this is my commitment:
To post regularly about my learnings.
To share my real process — not the highlight reel.
To remind every learner out there that growth happens quietly, through action.

If you’re reading this — maybe this is your reminder too.
Start now.
Post that thought.
Build that project.
Show up — and watch how your world changes. 🌱

Debugging, Deleted Code, and Google Chaos: A Developer’s Reality 💻💥

Preeti yadav — Fri, 03 Oct 2025 04:09:02 +0000

Raise your hand if you’ve ever:

Googled “Why is my React app not rendering?” 20 times in a row
Accidentally deleted hours of code and felt like the universe hates you
Stared at your code, feeling like a wizard one second and an imposter the next

Yeah… welcome to developer life.

1. Google Search History = Chaotic Energy

If someone sees my history, it’s a masterpiece of desperation:

Javascript undefined is not a function
CSS center div vertically
How to fix code when you feel like crying
Recover deleted code in VS Code
Undo Git commit like a pro

Every developer has been there. Google is basically our therapist at this point.

2. Deleted Code Panic 😱

Nothing compares to the horror of accidentally deleting your code. But fear not! There’s hope:

In VS Code:
Press Ctrl + Z (or Cmd + Z on Mac) immediately — VS Code often keeps the undo history even after closing the file.

Check Local History extensions — they can save snapshots automatically.

On GitHub:
If you committed your code before deleting, run:

git checkout <commit_hash> <file_path>

Or recover a deleted branch with:

git reflog
git checkout -b <branch_name> <commit_hash>

Pro tip: Commit frequently. Your future self will thank you.

3. StackOverflow: Our Saviour

Sometimes the answer is literally 2 clicks away. Copy-paste, pray, debug a little… and it works!

4. Coffee = Developer Fuel ☕

No coffee = no code.
Yes coffee = maybe I can fix this bug… probably…

5. Imposter Syndrome: Level 100

You’ll feel like a fraud one second… until you fix the bug that’s been haunting you for hours. Then suddenly, you’re Gandalf the Great of Code.

Coding is panic, googling, caffeine, accidental deletes, and small victories.
Celebrate the wins, learn from the fails, and never forget: every dev has been there.

Extra Tip: Install a good VS Code extension for local history, commit frequently, and always keep GitHub backups. It’ll save your sanity more than once.

From Googling Errors to Solving Them Like a Pro

Preeti yadav — Sat, 27 Sep 2025 04:45:05 +0000

Ever Googled an error 20 times before it finally made sense? 😅

Every developer has been there — staring at an error message that feels like it was written in a different universe.
At first, I thought becoming a developer meant memorizing syntax, knowing 10+ frameworks, and building flawless apps. Reality? It meant Googling the same error 20 times until it finally made sense.

But here’s the twist: Googling errors isn’t a weakness. It’s actually a superpower. Here’s why 👇

🔍 The “Error → Search → Solution → Repeat” Loop

When I started coding, I felt embarrassed that I couldn’t just “know” the answer. But then I realized:

Even senior devs Google error codes.
Debugging is 50% of the job.
StackOverflow, GitHub issues, and documentation are part of a developer’s toolkit.

Instead of memorizing everything, I learned how to ask better questions. For example:
❌ “React not working”
✅ “React useEffect infinite loop when fetching API”

The second one leads to real answers.

💡 Patterns Over Solutions

One day, it clicked: The goal isn’t just fixing the current bug, but recognizing patterns in problems.

Infinite loops in React? → Usually state dependencies.
API not connecting? → Maybe CORS or missing headers.
SQL query failing? → Check data types and constraints.

Once you see the patterns, you start solving errors faster, without needing to search every single time.

Final Thoughts

If you’re a beginner dev, remember:
👉 Googling errors doesn’t make you less of a developer.
👉 It means you’re building the most important skill: problem-solving.
👉 Every error you fix makes you faster, sharper, and more independent.

So next time you hit an error, don’t stress — smile. You’re literally leveling up. 💪

Adaptability: The Superpower Developers Need in 2025

Preeti yadav — Mon, 25 Aug 2025 04:29:21 +0000

The tech industry is advancing at an unprecedented pace, moving forward with remarkable speed and innovation. What seemed innovative yesterday is already outdated today, as the rapid evolution continues. As developers, we’re not just writing code, we’re actively shaping how people live, work, and interact with technology on a daily basis. However, the focus has shifted significantly: it's no longer about "Can we build this?"—it's about "How can we build this better, faster, and smarter?" This new mindset is driving the industry forward.

🌐 Industry Shifts Developers Can’t Ignore

AI Everywhere
From code generation to smarter debugging, AI isn’t replacing developers—it’s amplifying us and enhancing our capabilities. Those who know how to collaborate with AI will stay ahead of the curve and lead the way in innovation.
Cloud-Native Mindset
Scalability is no longer optional. Cloud-native architectures, such as microservices and serverless, are becoming the foundation for modern applications, ensuring they can grow and adapt as needed.
User-Centric Development
Performance and experience matter more than ever. Accessibility, responsiveness, and real-time features aren’t “nice-to-haves”—they’re expected, and they define the success of applications.
Continuous Learning as a Differentiator
Frameworks come and go, but adaptability is the real skill that sets developers apart. The best developers are lifelong learners, always ready to acquire new knowledge.

How to Stay Ahead

Experiment often → Don’t just read about trends; try building mini-projects with them to gain hands-on experience.
Collaborate smartly → Share knowledge, contribute to open-source, and learn from peers to expand your understanding.
Balance fundamentals with trends → Don’t skip core concepts like algorithms, design patterns, and scalability. They endure beyond the trend cycle and remain crucial.

Final Thought

The industry will keep evolving—and that’s the fun part. Instead of fearing change, embrace it wholeheartedly. The developers who thrive aren’t the ones who know everything but the ones who know how to adapt to anything. This adaptability is key to success.

👉 What’s one trend you’re most excited (or worried) about in 2025? Drop your thoughts in the comments—I’d love to hear!

Just Launched My Portfolio & I'd Love Your Feedback! 🙌

Preeti yadav — Thu, 17 Jul 2025 04:18:08 +0000

Hey everyone! 👋

I recently launched my portfolio and wanted to share it here because I’ve seen similar ones on Dev.to before, and they really inspired me!

I always loved the idea of turning a portfolio into something fun and interactive — like a desktop operating system. It just felt more me, and I thought... why not give it a try?

🔗 Live Link: https://preetiyadav.dev/

🎯 My Goal

I didn’t want to overcomplicate things with too many libraries or complex logic. My main goal was to:

Keep the experience smooth and clean

Make the layout fun to explore (like opening windows, minimizing, etc.)

Still keep it developer-friendly and simple under the hood

🛠️ Tech Stack

Here’s what I used:

Next.js – for routing and performance
Tailwind CSS – for fast styling and responsiveness
EmailJS – just for handling the contact form (no backend needed)

That’s it. No heavy animations, no state managers. Just clean and lightweight.

🧩 Key Features

Desktop-like layout — open/close different windows (like About, Projects, Resume, etc.)

Simple contact form with EmailJS
Clean UI with dark/light mode support
Fully responsive

🤝 Would Love Your Feedback!

If you get a chance to explore it, I’d love to hear what you think! Any suggestions, ideas, or even bugs you spot — I’m all ears.
Feel free to connect or drop a message 😊

Thanks for reading!

Understanding Prisma ORM with NestJS — A Practical Guide

Preeti yadav — Mon, 07 Jul 2025 04:36:47 +0000

Prisma is a modern TypeScript ORM that makes database interactions type-safe and intuitive. NestJS is a powerful Node.js framework built for scalability and modularity. Together, they form a clean, type-safe backend stack.

🧠 Why Prisma + NestJS?

NestJS is a powerful, modular backend framework built with TypeScript. Prisma is a next-gen ORM that makes database access easy, type-safe, and scalable.

Together, they offer:

✅ Full TypeScript support
✅ Auto-generated types for DB models
✅ Fast and readable queries
✅ Modular, maintainable code structure
✅ Support for PostgreSQL, MySQL, SQLite & more

⚙️Installing and Setting Up Prisma in a NestJS Project

npm install prisma --save-dev
npm install @prisma/client
npx prisma init

Creates prisma/schema.prisma
Configure your database URL in .env

DATABASE_URL="mysql://user:password@localhost:3306/mydb"

Basic Folder Structure

src/
├── app.module.ts
├── user/
│   ├── user.module.ts
│   ├── user.service.ts
│   ├── user.controller.ts
│   └── user.entity.ts
└── prisma/
    ├── prisma.module.ts
    └── prisma.service.ts

Creating Your First Model

Inside prisma/schema.prisma:

model User {
  id       Int      @id @default(autoincrement())
  name     String
  email    String   @unique
  createdAt DateTime @default(now())
}

npx prisma migrate dev --name init

Generating Prisma Client & Using It

Create a PrismaService to inject Prisma client throughout the app.

// prisma.service.ts
import { Injectable } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';

@Injectable()
export class PrismaService extends PrismaClient {
  constructor() {
    super();
  }
}

Creating a User Service with CRUD

// user.service.ts
@Injectable()
export class UserService {
  constructor(private prisma: PrismaService) {}

  create(data: CreateUserDto) {
    return this.prisma.user.create({ data });
  }

  findAll() {
    return this.prisma.user.findMany();
  }

  findOne(id: number) {
    return this.prisma.user.findUnique({ where: { id } });
  }

  update(id: number, data: UpdateUserDto) {
    return this.prisma.user.update({ where: { id }, data });
  }

  delete(id: number) {
    return this.prisma.user.delete({ where: { id } });
  }
}

Using DTOs for Type Safety

// create-user.dto.ts
export class CreateUserDto {
  name: string;
  email: string;
}

Bonus Tips from Real Projects

✅ Always validate inputs with class-validator
✅ Use guards for role-based access (RBAC)
✅ Write custom Prisma middleware (e.g., for soft deletes)
✅ Use select & include for fine-grained queries
✅ Combine with Swagger for clean API documentation

Wrap-Up

Prisma and NestJS together make backend development clean, fast, and scalable. Once you get the structure right, it’s a smooth ride 🚀

Zero: The Most Dangerous Number in Your Code

Preeti yadav — Mon, 09 Jun 2025 15:40:06 +0000

🧨 Introduction: The Hero You Never Noticed

It hides in plain sight.

It means nothing… and yet, without it, everything breaks.

We’re talking about zero (0) — the ninja of numbers, the invisible warrior of math, and quite possibly the most dangerous number in your codebase.

Sounds dramatic?

Good. Because zero is dramatic. Let’s unravel why.

💥 Zero Didn’t Always Exist

Thousands of years ago, civilizations thrived without the number zero.

The Romans had no symbol for zero.
Try writing 2025 in Roman numerals: MMXXV — not a zero in sight.
Ancient Egyptians also skipped it. Imagine doing math without nothing.

It wasn’t until around 7th century India that Brahmagupta gave us a formal concept of zero — as both a number and a placeholder. That changed everything:

From calculating stars to building Google’s search algorithm — zero laid the foundation.

🧠 Zero: The Paradox

Feature	Why It's Crazy
`0` means nothing	But it’s still something
`0` adds no value	But it’s crucial in `10`, `100`, `1000`
`0 / x = 0`	But `x / 0 = Infinity` or crash!
`0 / 0 = NaN`	Wait... what? 😵
`0` is falsy in code	But sometimes it’s a valid value

🧮 The Division Disaster

Let’s test your instincts:

console.log(2 / 2);   // 1 ✅
console.log(0 / 2);   // 0 ✅
console.log(2 / 0);   // Infinity 😵
console.log(0 / 0);   // NaN 😱

Wait… 0 / 0 = NaN?

That’s right. Because there’s no single correct answer.
0 divided by 0 could be 1, 42, or a slice of pizza 🍕 — it’s indeterminate.

And your program doesn’t like ambiguity.

💻 Why Zero Haunts Developers

Let’s list some real-world zero problems:
Divide-by-zero exceptions → 💥 App crash
Falsy values in conditionals → Missed logic paths
Off-by-one errors → Classic loop bugs
Unintended array behavior → array[0] is fine, but array[-1]? 🪦

Zero is sneaky. One minute it's a valid value, the next it's triggering bugs you’ll chase for hours.

🔍 0 in Binary: The Building Block of Everything

Every image, website, or TikTok dance you see on your phone is just a giant sea of 0s and 1s.

Zero isn’t just "nothing."
It’s half of the binary universe.

✨ Conclusion: Respect the Nothing

Zero may look harmless.
But in math, history, and your next JavaScript loop — it’s a powerful force that demands respect.

Next time your code misbehaves, don’t overlook the quietest suspect.
The real bug might be... 0.