This Dussehra, Burn These 10 Bad Developer Habits

Happy Dussehra.

Ravan had 10 heads. Each one represented an evil — ego, lust, anger, greed, attachment, selfishness, injustice, cruelty, pride, fear.

You know what else has 10 heads?

Your codebase.

Every developer carries their own Ravan — bad habits that they know are wrong, they've been told are wrong, they've even told others are wrong — but they keep doing them anyway.

So this Dussehra, let's do what Ram did.

Burn them.

One head at a time.

---

🔥 Head 1: Not Writing Tests

"I'll add tests later."

You won't.

You never do.

"Later" in developer language means "never, unless production breaks at 3 AM and my manager asks why there are no tests."

You shipped that feature without a single test. It works on your machine. It works in staging. It's in production now and you're praying.

That's not engineering. That's gambling.

Write the test. Before you write the code, after you write the code, I don't care. Just write it. Stop telling yourself you'll come back to it.

You've been saying "later" for 3 years.

Burn it.

---

🔥 Head 2: Copy-Pasting From Stack Overflow Without Understanding

You found the answer. 14 upvotes. Green checkmark. You copy it, paste it, it works, you move on.

Do you know what it does?

"It fixes the issue."

Yeah but HOW?

That regex you copied — do you know what it matches? That config change you made — do you know what it disabled? That npm package you installed because someone on Stack Overflow said so — do you know what it does to your bundle size?

Copy-pasting isn't the sin. Not understanding what you pasted is.

The code you don't understand is the code that will break in production and you won't know how to fix it.

Burn it.

---

🔥 Head 3: "It Works, Don't Touch It"

The sacred code.

Nobody knows who wrote it. Nobody knows how it works. But it works. So nobody touches it.

There's a function in your codebase right now — 400 lines, no comments, variable names like temp2 and xx — and the entire team treats it like a landmine. "Don't refactor that. Last person who tried was here till midnight."

That's not stability. That's fear.

And fear-driven development is how you end up with a codebase that nobody can maintain, nobody can extend, and nobody wants to work on.

If you can't explain what it does, you can't fix it when it breaks. And it will break. Code always breaks. The question is whether you'll understand it when it does.

Burn it.

---

🔥 Head 4: Hardcoding Everything

if user.role == "admin":
    timeout = 30
elif user.role == "manager":
    timeout = 20
else:
    timeout = 10

String dbUrl = "jdbc:mysql://192.168.1.45:3306/prod_db";

const API_KEY = "sk-proj-abc123definitelyreal";

Stop.

Hardcoded values are time bombs. They work today. Then someone changes the IP. Or rotates the key. Or adds a new role. And now you're doing a find-and-replace across 47 files and praying you didn't miss one.

Config files exist. Environment variables exist. Constants exist.

Use them.

Burn it.

---

🔥 Head 5: Not Reading Error Messages

The error message says: TypeError: Cannot read properties of undefined (reading 'map')

Developer's reaction: "It's broken. Let me Google the error."

Bhai. Read it. It literally tells you what happened.

Something is undefined. You're calling .map() on it. Which means the thing you thought was an array... isn't. Go find out why.

90% of debugging is just reading. Reading the error. Reading the stack trace. Reading the actual line of code it's pointing to.

But no. We see red text and panic. Copy the error, paste it in Google, scroll through 4 Stack Overflow answers, try random solutions, and somehow spend 2 hours on something the error message explained in one line.

Burn it.

---

🔥 Head 6: Premature Optimization

"But what if we get 10 million users?"

Bhai you have 12 users. And 3 of them are your team members testing in production.

You spent 2 weeks building a distributed caching layer with Redis clusters for an app that gets 50 requests a day. You added Kafka for a messaging system that sends 3 emails a week. You implemented database sharding for a table with 200 rows.

This isn't engineering. This is resume-driven development.

Build for what you need NOW. Optimize when you have actual data showing you need to. Not when you imagine you might need to someday.

The fastest code is the code that solves the actual problem. Not the code that solves an imaginary problem at imaginary scale.

Burn it.

---

🔥 Head 7: Never Reading Documentation

"I'll just watch a YouTube tutorial."

YouTube tutorial: 45 minutes of "hey guys welcome back" and 3 minutes of actual content that's already outdated.

The official docs: exact, current, searchable, with examples.

I know docs aren't fun. I know they're dry. I know you'd rather watch a 20-minute video than read for 5 minutes. But the docs are the source of truth. The tutorial is someone's interpretation of the docs, possibly wrong, possibly from 2019.

The best developers I've worked with read docs first. Not Stack Overflow. Not Medium articles. Not "10 things you didn't know about React" listicles.

Docs.

Burn it.

---

🔥 Head 8: Terrible Variable Names

def calc(a, b, c, d):
    x = a * b
    y = x - c
    z = y / d if d != 0 else 0
    return z

What does this function do?

Nobody knows. Not even the person who wrote it. Especially not the person who wrote it, because they wrote it 3 months ago and they've already forgotten.

def calculate_discount_percentage(price, quantity, tax, total_items):
    subtotal = price * quantity
    after_tax = subtotal - tax
    discount_per_item = after_tax / total_items if total_items != 0 else 0
    return discount_per_item

Same logic. Now a human can read it.

"But it takes longer to type!"

You have autocomplete. You have tab completion. You have an IDE that literally finishes your sentences. The extra 2 seconds of typing saves 20 minutes of "what the hell is x here" 6 months from now.

Burn it.

---

🔥 Head 9: Ignoring Code Reviews

Two types of developers in code reviews:

Type 1: "LGTM 👍" on every PR without reading a single line.

Type 2: Leaves 47 comments about whitespace and bracket placement while ignoring the actual logic bug on line 83.

Both are useless.

Code reviews aren't a checkbox. They're the last line of defense before bad code hits production. If you're approving without reading, you're not reviewing — you're rubber-stamping.

And if you're the one getting reviewed — stop taking feedback personally. That comment isn't attacking you. It's trying to make the code better. Your ego is not more important than the codebase.

The best teams I've seen treat code reviews as conversations, not judgments. "Why did you do it this way?" isn't criticism. It's curiosity. And sometimes the answer is "because I didn't know a better way" — and that's fine. That's how you learn.

Burn it.

---

🔥 Head 10: Comparing Yourself to Others

This is the biggest Ravan of all.

"That guy on Twitter shipped a SaaS in 2 weeks. I can barely finish a todo app."

"She's 22 and already a Staff Engineer. I'm 28 and still figuring out Docker."

"Everyone on LinkedIn is building AI agents and I don't even understand what a transformer is."

Stop.

Twitter is a highlight reel. LinkedIn is fiction. Nobody posts about the 47 failed attempts before the one that worked. Nobody tweets "spent 4 hours debugging a missing semicolon" (well, some people do, but you get the point).

Your journey is yours.

The guy who shipped in 2 weeks had 5 years of failed projects before that. The 22-year-old Staff Engineer started coding at 12. The AI agent builder copied a tutorial and added a wrapper.

You're not behind. You're on your own timeline. The only comparison that matters is: do you know more than you did last month?

If yes, you're winning.

Burn it.

---

The Dussehra Message

Ravan wasn't stupid.

He was a scholar. A devotee of Shiva. A master of the Vedas. One of the most learned beings in Hindu mythology.

But his knowledge didn't save him from his flaws.

Same with developers.

You can know 15 programming languages. You can have 10 years of experience. You can crack any LeetCode hard in 20 minutes.

But if you're not writing tests, not reading docs, not naming your variables properly, not listening to feedback, and spending your energy comparing yourself to strangers on the internet — your knowledge doesn't matter.

Kill the habits that hold you back.

Not tomorrow. Not "in the next sprint." Not "when I have time."

Today.

Happy Dussehra. 🏹

Now go refactor that function nobody wants to touch.