Hanzla Baig

Posted on May 8

🤔 Questions Only Developers Will Lose Sleep Over (And Secretly Love Answering)

#webdev #programming #productivity #javascript

By a Developer, For Developers — Who Else Would Actually Read This?

Published · 12 min read · ☕ Grab your coffee. Or your third one. We don't judge.

Introduction: Welcome to the Developer Brain

There's a very specific kind of person who, at 2 AM, is staring at a blinking cursor, asking themselves existential questions — not about life, love, or the universe — but about whether an undefined and a null are truly different in spirit.

That person is a developer. And that person is you.

This blog post is not a tutorial. There's no npm package to install. No boilerplate to clone. No .env file to forget to add to .gitignore (we've all done it, we don't talk about it).

This is a collection of the most delightfully cursed questions that every developer has thought about at some point — questions that have no right answer, only stronger opinions. Read them, argue in the comments, and forward this to the developer friend who will get personally attacked by at least three of these.

Let's go. 🚀

🐛 Question 1: If a Bug Is Fixed But No One Writes a Test for It, Did the Bug Ever Really Exist?

Imagine this scenario:

A user reports a bug.
You reproduce it.
You fix it in 20 minutes.
You close the ticket.
You do NOT write a test.
Three weeks later, the bug is back.

Now here's the philosophical dilemma: Is this the same bug returning, or a brand new bug that happens to look exactly like the old one?

If there's no test to define the expected behavior, does the bug have a legal right to exist again?

This is basically the Schrödinger's Bug of software development. Until you observe it (via a failing test), the bug exists in a superposition of fixed and not-fixed.

The uncomfortable truth: The bug was never truly fixed. It was just scared away temporarily. Like a raccoon in a dumpster — you can shoo it, but it will come back when you're not looking.

Hot take: A fix without a test is just a wish. A very confident wish.

💻 Question 2: Is It Still "Clean Code" If It Works But You Can't Explain It the Next Morning?

You wrote it at 11 PM. It was elegant. It was clever. It used a reduce inside a map inside a filter and you felt like an absolute genius.

const result = data
  .filter(x => x?.meta?.active && !x?.flags?.includes('deprecated'))
  .map(({ id, payload: { nested: { value } = {} } = {} }) => ({ id, value }))
  .reduce((acc, { id, value }) => ({ ...acc, [id]: (acc[id] || 0) + value }), {});

Next morning. Fresh eyes. Coffee in hand.

...what

You added a comment:

// This works. Please don't touch it.
// I'm serious. Don't.
// — Past Me (who was clearly unwell)

Is it clean code? Robert C. Martin says clean code reads like well-written prose. This reads like a ransom note written in a hurry. And yet — it ships. It works. The tests pass (because you wrote the tests when you were also unwell).

The real question: Is "clean" about readability, or about results? And does the answer change depending on whether your team can read it?

Rule of thumb: If you can't explain the code to a rubber duck without whispering, it's not clean. It's haunted.

🔢 Question 3: Are `null`, `undefined`, `0`, `""`, and `false` the Same Thing — or 5 Different Ways to Ruin Your Day?

JavaScript decided that the concept of "nothing" needed five distinct representations. Let's honor that decision by understanding exactly how each one will destroy you:

Value	What It Technically Means	What It Feels Like
`null`	Intentional absence of value	"I deliberately put nothing here"
`undefined`	Variable declared but never assigned	"I forgot this existed"
`0`	The number zero	"Something happened. It was just zero."
`""`	An empty string	"I had a field. It had no content."
`false`	Boolean false	"No. Just no."

They are all falsy. They will all evaluate to false in an if statement. They are not the same. This matters when you're trying to tell the difference between "the user didn't answer" (undefined), "the user answered nothing" (null), and "the user answered zero" (0).

if (!userScore) {
  console.log("No score recorded");
  // This runs for 0, null, undefined, false, and ""
  // Congrats, you just told a user who scored 0 that they didn't play
}

The correct fix:

if (userScore === null || userScore === undefined) {
  console.log("No score recorded");
}
// Now 0 is treated as a valid (if humbling) score

Life lesson: Always use === null or === undefined. Never trust !value. JavaScript is not your friend here. It's chaotic neutral.

🤯 Question 4: If You Google the Same Stack Overflow Answer 5 Times, Is It Time to Just Memorize It?

Let's be honest about something: there are answers you have Googled so many times that Stack Overflow should just start auto-completing your name in the "viewed by" section.

The top questions developers Google on repeat:

"How to center a div CSS"
"How to reverse a string in [language]"
"Git undo last commit"
"Python read file line by line"
"SQL left join vs inner join"
"How to exit vim" (this one is eternal)

The question is: at what point does repeatedly Googling the same thing cross from "healthy reference behavior" into "I should probably just know this"?

The answer, backed by zero research but strong feelings:

1–3 times: Completely normal. You're still learning the context.
4–7 times: The knowledge is there, you just don't trust yourself.
8–15 times: At this point you could write the Stack Overflow answer yourself.
16+ times: You ARE the answer. You are a living documentation page. You have ascended.

Fun fact: The most-viewed Stack Overflow question of all time is "How do I exit Vim?" with over 4 million views. We are, as a species, collectively unable to exit a text editor.

🚀 Question 5: Is "Deploying to Production" the Same as "Sending a Prayer to the Cloud"?

There is no ritual more sacred, more terrifying, more heart-rate-elevating in software development than the Friday afternoon production deploy.

The pre-deploy internal monologue:

"Tests pass. Staging looks fine. Code review was... mostly positive. Jenkins is green. But what if — WHAT IF — there's something I missed? What if this breaks payments? What if this breaks auth? What if the migration takes 10 minutes and the app times out? Should I just wait until Monday? It's 4:58 PM on a Friday. I should wait. But the ticket says HIGH PRIORITY. I'll deploy. No — I won't. I will. Here goes."

The deploy checklist every developer actually runs:

[x] Code reviewed ✅
[x] Tests pass locally ✅
[x] Staging environment validated ✅
[x] Database migration tested ✅
[x] Rollback plan exists (kind of) ✅
[ ] Told the team (they'll find out) 🤐
[ ] Made peace with whatever happens next 🙏

The three outcomes of every production deploy:

It works perfectly. You feel like a god. You close your laptop and go home like a champion.
Something breaks immediately. You revert. You learn. You survive. (Usually.)
Nothing breaks... yet. This is the worst one. The bug is waiting. It's learning. It knows.

Golden rule: Never deploy on a Friday unless you enjoy working weekends. This is not a joke. This is sacred scripture.

⌨️ Question 6: When You Rename a Variable from `data` to `theData` — Is That Refactoring?

Let's define our terms.

Refactoring (noun): The process of restructuring existing code without changing its external behavior, in order to improve its internal structure, readability, or maintainability.

Now. You have a variable called data. It's confusing. You rename it to theData. Your IDE updates it across 12 files. You commit:

git commit -m "refactor: improved variable naming for clarity"

Is this refactoring?

Technically: Yes. You changed internal structure. Behavior is unchanged. It meets the definition.

Practically: Your senior dev will raise one eyebrow during code review and say nothing. That eyebrow contains multitudes.

The real refactoring spectrum:

Action	Level	Respect Gained
Rename `data` to `userData`	Naming improvement	+1
Extract a 200-line function into 5 focused functions	Actual refactoring	+10
Replace nested callbacks with async/await	Pattern improvement	+15
Rewrite the entire module with proper SOLID principles	Architecture work	+50
Rewrite it in Rust "for performance"	You've seen too much	+0 (everyone is scared)

The uncomfortable truth: Most "refactoring" is really just "I couldn't read this at 9 AM so I made it slightly more readable and called it refactoring." That's fine. That's valid. Keep doing it.

🧪 Question 7: Are Unit Tests Just Very Angry Comments That Run Automatically?

Consider:

A comment says:

# This function should return the sum of two numbers
def add(a, b):
    return a + b

A unit test says:

def test_add_returns_sum_of_two_numbers():
    assert add(2, 3) == 5
    assert add(-1, 1) == 0
    assert add(0, 0) == 0

The comment describes the intent. The unit test enforces it — and yells at you when you violate it.

FAILED tests/test_math.py::test_add_returns_sum_of_two_numbers
AssertionError: assert 6 == 5

That's a comment that fought back.

Types of test emotions:

AssertionError — Betrayal. Disappointment. How could you.
TypeError — Confusion. "You passed WHAT type?"
TimeoutError — Exhaustion. "I waited. You never came."
All tests passing — Pure, unconditional love. Cherish it.

The stages of a developer's relationship with testing:

Denial: "I don't need tests, I know what my code does."
Anger: "Writing tests takes longer than writing the code!"
Bargaining: "I'll just write tests for the important parts."
Depression: [stares at 23 failing tests at 11 PM]
Acceptance: "Tests are love. Tests are life. Tests are the only thing standing between me and 3 AM production incidents."

Wisdom: Write the test first. Hear me out. Write the test first. You'll thank yourself at 3 AM when you're not debugging a production incident.

🕰️ Question 8: Does "It'll Take 2 Hours" Ever Actually Mean 2 Hours?

Short answer: No.

Long answer: No, and here is why, presented with scientific rigor (loosely defined):

The Developer Time Dilation Table:

What the Developer Says	What It Actually Means
"5 minutes"	45 minutes to 2 hours
"Quick fix"	Entire afternoon
"It's almost done"	40% done, actually
"Just one more thing"	3 more things minimum
"Should be simple"	It's not simple
"2 hours"	2 days
"2 days"	End of sprint
"End of sprint"	Next sprint
"Next sprint"	Q3
"Q3"	"We're reconsidering the feature"

Why does this happen?

It's not laziness. It's not incompetence. It's called Hofstadter's Law:

"It always takes longer than you expect, even when you take into account Hofstadter's Law."

Translation: Even when you know you're underestimating, you still underestimate. The universe is conspiring against your timeline.

What actually takes 2 hours:

Setting up a new dev environment (if you're lucky)
Reading the codebase of a project you've never seen before
Debugging one off-by-one error in a nested loop
A meeting that was supposed to be 30 minutes

Pro tip for non-developers reading this: When a developer gives you an estimate, multiply by π. It's not a guarantee, but it's closer to the truth than whatever they said.

🌐 Question 9: If the Frontend Works AND the Backend Works, But Together They Don't — Whose Fault Is It?

This is perhaps the most ancient and sacred debate in all of software development. Let us examine it with the nuance it deserves.

The scene:

Frontend dev: "I'm sending the correct data. Look."
[shows network tab, request payload is perfect]

Backend dev: "I'm receiving and processing correctly. Look."
[shows logs, response is perfect]

The integration: 💥 500 Internal Server Error

The usual suspects:

CORS — It's almost always CORS. The browser is not your friend. It has opinions about who talks to whom.
Content-Type mismatch — One sends application/json, the other expects application/x-www-form-urlencoded. Classic.
Auth token format — "Bearer " vs "bearer " vs no space vs the wrong header entirely.
Date format — Frontend sends "2024-01-15", backend expects "15/01/2024". Timezones cry.
Null vs missing field — One sends { "name": null }, other expects {} with no name key. These are different. They will be treated differently.
Someone updated the API contract and didn't tell anyone — This is a people problem disguised as a tech problem.

Who is actually at fault?

Both. Neither. The real fault lies in the absence of a shared contract (like an OpenAPI spec) that both sides agreed to beforehand.

But in practice, the conversation goes:

Frontend: "This is a backend problem."
Backend: "This is a frontend problem."
DevOps: opens ticket, assigns it to both, goes back to managing Kubernetes

Solution: Write the API contract first. Both teams agree. Both teams implement. Both teams are friends. It's beautiful when it works.

🤖 Question 10: When You Use AI to Write Code You Don't Understand — Are You a Developer or a QA Engineer?

We need to talk about this. Productively. Without judgment. (A little judgment.)

The new developer workflow (2024 edition):

Have a problem.
Describe the problem to an AI.
Receive code that looks correct.
Copy the code.
Run the code.
It doesn't work.
Ask AI why it doesn't work.
Receive a fix.
The fix breaks something else.
Ask AI to fix the thing the fix broke.
Repeat from step 6.
Ship it because it seems fine now.

Is this bad? Not inherently. Using tools is what developers do. Every IDE, linter, framework, and library is a tool that abstracts complexity away.

Is there a risk? Yes. The risk is shipping code you fundamentally don't understand — which means you can't debug it when it breaks at 3 AM, you can't optimize it when it becomes slow, and you can't explain it in a code review without saying "the AI wrote it."

The healthy balance:

Use AI to speed up what you already understand.
Use AI as a learning tool, not a replacement for learning.
Read the code before you ship the code.
If you can't explain it, you don't own it yet.

The uncomfortable truth: AI is an incredible accelerator. But acceleration in the wrong direction just gets you to the wrong place faster. Understand first. Accelerate second.

🔄 Question 11: Is `git commit -m "fix"` an Acceptable Commit Message?

No.

But let's talk about why we do it anyway.

You've been debugging for 4 hours. You finally found it — a missing semicolon, a wrong variable name, a race condition that only manifests under specific load. You're exhausted. You're relieved. The last thing in the world you want to do is write a thoughtful commit message.

git commit -m "fix"

Done. Shipped. Moving on.

The git log of every developer's personal project:

abc1234 - fix
def5678 - fix2
ghi9012 - actually fix
jkl3456 - fix for real this time
mno7890 - ok this is the real fix
pqr1234 - FINAL fix
stu5678 - final FINAL fix
vwx9012 - why
yza3456 - it works don't ask
bcd7890 - please work
efg1234 - it works (don't touch)
hij5678 - hotfix
klm9012 - hotfix2

What a good commit message looks like:

fix(auth): prevent token refresh loop on expired session

When the access token expired and the refresh token was also
invalid, the refresh logic entered an infinite loop. Added a
max retry count of 3 before clearing credentials and
redirecting to login.

Fixes #4821

Why it matters: Future you — or your teammate — at 2 AM, bisecting the git history to find when this broke, will either bless you or curse you based on your commit messages. Choose who you want to be.

Commit message template to live by:
type(scope): short description
[blank line]
Longer explanation of what and why (not how)

💡 Question 12: Is Dark Mode a Preference or a Personality Trait?

This is not a technical question. This is a deeply personal one.

Evidence that dark mode is a personality trait:

Dark mode developers have opinions about which dark mode is "too dark."
They will audit your VS Code theme on the first day of pair programming.
They have a physical reaction — a genuine, visceral flinch — when a webpage opens in full white background.
They have adjusted the brightness of every screen in their home.
Their phone, IDE, browser, OS, email client, and notes app are all in dark mode. Consistency is a value, not a preference.

The dark mode developer when exposed to light mode:

System: "Light mode enabled."
Developer: looks directly at screen
Developer: "I need a moment."

The light mode developer (they exist):

"I find it easier to read."
universal confusion from the rest of the team

The scientific question: Is dark mode actually better for your eyes? The research is mixed. Dark mode reduces blue light emission (good for nighttime). But light mode may have better readability in bright environments. Contrast ratios matter more than the background color itself.

The real answer: Use whatever works for you. But know that the dark mode community has prepared arguments, and they are ready to deploy them at any standup.

Ranking of developer dark mode opinions:

One True Dark (pure black #000000) — Purist. Respect.

Soft Dark (like #1e1e1e) — Sensible. Popular.

Solarized Dark — Vintage. Respected.

"I use light mode at work" — uncomfortable silence

☕ Question 13: How Many Cups of Coffee Does It Take to Write One Function?

This is a highly scientific question with a highly variable answer.

The Coffee-to-Complexity Scale:

Task	Coffee Required
Write a utility function	½ cup
Debug someone else's code	2 cups minimum
Understand legacy code with no comments	1 full pot
Implement a feature with unclear requirements	2 pots + tea
Fix a production bug on a Friday afternoon	Mainline it directly
Read through the entire codebase of a new job	Consider switching careers

The four stages of developer caffeine:

Pre-coffee: "I can't even look at the IDE."
One coffee: "Okay. I understand the problem."
Two coffees: "I am the problem AND the solution."
Three coffees: "I rewrote the entire module and I have opinions about architecture now."

Health note: Please hydrate. Drink water. Your editor will still be there after you drink some water. The bugs will wait. Probably.

🔥 The Ultimate Developer Debates: Pick Your Side

These are not questions with right answers. These are questions with your answers. Choose wisely. Your reputation in the team Slack channel depends on it.

Debate 1: Tabs vs. Spaces

Team Tabs:

Tabs have semantic meaning (this is an indent).
Tab width is configurable. My 4-space indent is your 2-space indent, and that's beautiful.
More accessible — visually impaired developers can configure tab size.

Team Spaces:

Spaces look the same everywhere. In every editor, every terminal, every code snippet on the internet.
"But what about alignment?" Spaces. Always spaces.
Python agrees with us. (This argument ends conversations.)

The actual resolution: Use .editorconfig and let the file decide for the whole team. Then argue about something more interesting.

Debate 2: `===` vs. `==` in JavaScript

Team === (Strict Equality):

Checks both value AND type.
0 === false is false. As God intended.
No type coercion. No surprises.
This is the only acceptable choice.

Team == (Loose Equality):

null == undefined being true is actually useful sometimes.
JavaScript's type coercion is a feature, not a bug.
[no serious engineers are on this team]

Verdict: Use ===. This is not a debate. This is a teaching moment.

Debate 3: Semicolons vs. No Semicolons in JavaScript

Team Semicolons:

Explicit is better than implicit.
ASI (Automatic Semicolon Insertion) has edge cases that will ruin you.
The famous return followed by an object on the next line? ASI eats it. Semicolons prevent that.

Team No Semicolons:

Cleaner to read.
Prettier enforces it anyway.
If you know the ASI rules, you're fine.
"But what about the edge cases?" — Linters. We have linters.

Verdict: Pick one per project. Enforce it with a linter. Don't let this become a 30-minute PR comment thread. (It will become a 30-minute PR comment thread.)

Debate 4: camelCase vs. snake_case

The rule that almost everyone follows:

JavaScript/TypeScript: camelCase for variables and functions, PascalCase for classes.
Python: snake_case for everything (PEP 8 says so).
SQL: snake_case for columns and tables (the database doesn't care, but consistency matters).
CSS: kebab-case for class names.
Constants: SCREAMING_SNAKE_CASE everywhere.

The one who breaks the rule: The developer who writes Python in camelCase because "that's how I think." They know who they are. They are at peace with it.

Debate 5: MongoDB vs. PostgreSQL

Team MongoDB:

Flexible schema. Ship fast, evolve later.
JSON-native. Perfect when your data IS documents.
Great for certain use cases: catalogs, logs, content stores.

Team PostgreSQL:

ACID compliance. Transactions that actually work.
Joins. Real, beautiful, efficient joins.
JSON support INSIDE a relational database (best of both worlds, checkmate).
30+ years of battle-tested reliability.

Honest verdict: Use the right tool for the job. If your data is genuinely document-shaped and schema-less by nature — MongoDB has merit. If you have relational data, business logic, and need data integrity — PostgreSQL. The "MongoDB vs PostgreSQL" debate is usually a "I chose the wrong tool for the job" debate in hindsight.

🧠 Bonus Round: Questions With No Good Answers

Just to end on pure chaos:

"Should I use a framework or vanilla JS?" — Depends. [everyone groans]
"Is microservices or monolith better?" — Start with a monolith. You can always split it. You can't easily merge microservices back together. Fight me.
"How many files is too many files in one folder?" — The answer is one more than you currently have.
"Should I rewrite this or refactor it?" — Refactor. Almost always refactor. Rewrites are how projects die.
"Is it worth automating something that takes 3 minutes to do manually?" — [long pause] Yes. The automation will take 4 hours and save you 3 minutes per month, and you will find it entirely worth it.

🏁 The Final Question: After Everything — Why Do We Keep Coding?

After the bugs. After the 3 AM production incidents. After the merge conflicts, the unclear requirements, the legacy codebases that look like they were written by someone who hated future developers personally.

After all of that — why do we keep showing up?

Because of this:

✅ Build successful
✅ All 247 tests passed
✅ Deployed to production
✅ No errors in logs

Because of the moment when a user sends a message saying "this feature is exactly what I needed." Because of the satisfaction of a function that does exactly one thing and does it perfectly. Because of the weird, specific joy of finally understanding why the bug happened and watching the fix work in real time.

Because we build things that didn't exist before. Because code is one of the few crafts where you can go from "I have an idea" to "the idea exists and other humans can use it" in a matter of hours or days. Because there is no feeling quite like it.

We keep coding because, underneath all the frustration and the complexity and the coffee and the CORS errors, we actually love it.

Even when we won't admit it. Especially when we won't admit it.

Now: which question got you? Which one are you forwarding to your team right now? Drop a comment, argue in the replies, and tag the developer in your life who definitely Googles "how to center a div" every single week.

They know who they are.

About This Post
Written for every developer who has ever whispered "please work" to their terminal at midnight. You are not alone. The terminal cannot hear you. But we can.

DEV Community

🤔 Questions Only Developers Will Lose Sleep Over (And Secretly Love Answering)

Introduction: Welcome to the Developer Brain

🐛 Question 1: If a Bug Is Fixed But No One Writes a Test for It, Did the Bug Ever Really Exist?

💻 Question 2: Is It Still "Clean Code" If It Works But You Can't Explain It the Next Morning?

🔢 Question 3: Are `null`, `undefined`, `0`, `""`, and `false` the Same Thing — or 5 Different Ways to Ruin Your Day?

🤯 Question 4: If You Google the Same Stack Overflow Answer 5 Times, Is It Time to Just Memorize It?

🚀 Question 5: Is "Deploying to Production" the Same as "Sending a Prayer to the Cloud"?

⌨️ Question 6: When You Rename a Variable from `data` to `theData` — Is That Refactoring?

🧪 Question 7: Are Unit Tests Just Very Angry Comments That Run Automatically?

🕰️ Question 8: Does "It'll Take 2 Hours" Ever Actually Mean 2 Hours?

🌐 Question 9: If the Frontend Works AND the Backend Works, But Together They Don't — Whose Fault Is It?

🤖 Question 10: When You Use AI to Write Code You Don't Understand — Are You a Developer or a QA Engineer?

🔄 Question 11: Is `git commit -m "fix"` an Acceptable Commit Message?

💡 Question 12: Is Dark Mode a Preference or a Personality Trait?

☕ Question 13: How Many Cups of Coffee Does It Take to Write One Function?

🔥 The Ultimate Developer Debates: Pick Your Side

Debate 1: Tabs vs. Spaces

Debate 2: `===` vs. `==` in JavaScript

Debate 3: Semicolons vs. No Semicolons in JavaScript

Debate 4: camelCase vs. snake_case

Debate 5: MongoDB vs. PostgreSQL

🧠 Bonus Round: Questions With No Good Answers

🏁 The Final Question: After Everything — Why Do We Keep Coding?

Top comments (0)

Introduction: Welcome to the Developer Brain

🐛 Question 1: If a Bug Is Fixed But No One Writes a Test for It, Did the Bug Ever Really Exist?

💻 Question 2: Is It Still "Clean Code" If It Works But You Can't Explain It the Next Morning?

🔢 Question 3: Are null, undefined, 0, "", and false the Same Thing — or 5 Different Ways to Ruin Your Day?

🤯 Question 4: If You Google the Same Stack Overflow Answer 5 Times, Is It Time to Just Memorize It?

🚀 Question 5: Is "Deploying to Production" the Same as "Sending a Prayer to the Cloud"?

⌨️ Question 6: When You Rename a Variable from data to theData — Is That Refactoring?

🧪 Question 7: Are Unit Tests Just Very Angry Comments That Run Automatically?

🕰️ Question 8: Does "It'll Take 2 Hours" Ever Actually Mean 2 Hours?

🌐 Question 9: If the Frontend Works AND the Backend Works, But Together They Don't — Whose Fault Is It?

🤖 Question 10: When You Use AI to Write Code You Don't Understand — Are You a Developer or a QA Engineer?

🔄 Question 11: Is git commit -m "fix" an Acceptable Commit Message?

💡 Question 12: Is Dark Mode a Preference or a Personality Trait?

☕ Question 13: How Many Cups of Coffee Does It Take to Write One Function?

🔥 The Ultimate Developer Debates: Pick Your Side

Debate 1: Tabs vs. Spaces

Debate 2: === vs. == in JavaScript

Debate 3: Semicolons vs. No Semicolons in JavaScript

Debate 4: camelCase vs. snake_case

Debate 5: MongoDB vs. PostgreSQL

🧠 Bonus Round: Questions With No Good Answers

🏁 The Final Question: After Everything — Why Do We Keep Coding?

🔢 Question 3: Are `null`, `undefined`, `0`, `""`, and `false` the Same Thing — or 5 Different Ways to Ruin Your Day?

⌨️ Question 6: When You Rename a Variable from `data` to `theData` — Is That Refactoring?

🔄 Question 11: Is `git commit -m "fix"` an Acceptable Commit Message?

Debate 2: `===` vs. `==` in JavaScript