Hadil Ben Abdallah

Posted on Jun 8

You’re a Real TypeScript Developer Only If...

#webdev #typescript #bash #devdiscuss

Relatable tales of migration and type errors

A few months ago, I published You're a Real JavaScript Developer Only If...

It was just a post for fun, and honestly, I didn't expect it to resonate with so many developers 😅

But judging by the comments, we’ve all been through the same chaos:

mysterious bugs
random npm disasters
console.log-powered debugging
code that somehow works and nobody knows why

Then recently, I came across the fun post You're a Real Software Developer Only If... by @sylwia-lask

And I loved it.

Not just because it was funny, but because it reminded me of one of my favorite things about the developer community:

We all have different tech stacks, different jobs, different levels of experience...

Yet somehow we keep collecting the exact same stories 😄

So after JavaScript...

and after Sylwia's Software Developer edition...

I thought it was only fair to continue the tradition.

This time, let's talk about the language that spends half its time protecting us from ourselves.

TypeScript.

So, you're a real TypeScript developer only if...

🔷 The First TypeScript Reality Check

You've converted a JavaScript project to TypeScript and thought:

"This should only take an hour"

Three days later, you're still fixing type errors.

You've added any just to make the error go away.

And immediately promised yourself you'd come back later.

You never came back.

You've fixed one TypeScript error...

and unlocked twelve new ones.

Like some kind of achievement system.

You've stared at a type error for 20 minutes and thought:

"I know what I mean. Why doesn't TypeScript know what I mean?"

You've written:

as any

and felt slightly ashamed.

🤝🏻 The Love-Hate Relationship

You've complained about TypeScript all day...

then felt completely lost when working in plain JavaScript.

You've removed a type annotation to "simplify things".

TypeScript strongly disagreed.

You've spent more time designing types than writing actual business logic.

You've looked at a generic type and thought:

"Who wrote this masterpiece?"

Then discovered it was you six months ago.

You've looked at another generic type and thought:

"Who wrote this nightmare?"

Also you.

You've typed something as string | number | null | undefined

because life is complicated.

🧠 The Advanced Developer Moments

You've opened a file and found:

type Result<T extends keyof U, U extends object>

Then immediately closed the file.

You've spent an hour fighting TypeScript.

Only to realize it was right the entire time.

You've celebrated when the IDE finally stopped showing red squiggly lines.

You've renamed a property in one place...

and watched TypeScript save you from breaking twenty files.

For one brief moment, you felt genuine gratitude.

You've added strict mode to a project.

And discovered things you wish you hadn't discovered.

You've used autocomplete so much that typing full property names now feels weird.

🚨 The Emergency Solutions

You've written:

// @ts-ignore

and hoped nobody would notice.

You've written a type so complicated that future you needed documentation to understand it.

You've copied a TypeScript error into Google.

The answer contained even more TypeScript than the original error.

You've said:

"The types are correct. The code is wrong."

and

"The code is correct. The types are wrong."

during the same debugging session.

You've finally fixed a bug...

before realizing TypeScript warned you about it two days ago.

🎯 So... Are You Officially a TypeScript Developer?

If you've read this list and caught yourself nodding every few lines...

Congratulations! 🥳

You're officially a TypeScript developer.

You've probably:

added any when nobody was looking
argued with a type that turned out to be right
spent more time fixing types than writing features
celebrated when the red squiggly lines finally disappeared

And despite all the complaining...

you secretly love TypeScript.

Because after enough projects, you realize that:

TypeScript isn't trying to ruin your day.

It's trying to stop future-you from ruining it 😄

💬 Your Turn

What's the most "TypeScript developer" thing you've ever done?

My vote goes to spending 30 minutes creating a beautiful type...

for an object that had exactly two properties 😅

Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah

Hadil Ben Abdallah

Software Engineer • Technical Writer (250K+ readers) • Trusted by 10+ companies I turn brands into websites people 💙 to use

Top comments (11)

Adam - The Developer • Jun 8

did a code review once, saw this guy wrote as unknown as any
lol

Hadil Ben Abdallah • Jun 8

Haha that’s one of those things that makes you pause for a solid 5 seconds 😄

as unknown as any feels like the TypeScript version of “I don’t want to think about this right now”, maximum type confusion, zero accountability 😂

Syed Ahmed Mohi Uddin Hasan • Jun 8

TypeScript isn't trying to ruin your day. It's trying to stop future-you from ruining it. — Louder for the people in the back! 😭

My most "TypeScript developer" moment has to be writing a generic type so abstract that I needed a map and a compass to read it six months later. Awesome write-up, Hadil!

Hadil Ben Abdallah • Jun 8

This is so real 😭

That “future-you protection system” is exactly what TypeScript is doing… even if present-you doesn’t always appreciate it in the moment 😄

And honestly, that generic type situation is a rite of passage at this point. You look at it later and think: “there’s no way I wrote this”… and then you slowly realize you absolutely did 😂

Dhruv Joshi • Jun 8

If you're relying on as any and // @ts-ignore to pass your builds, you're not actually writing TypeScript, you're just writing broken JavaScript with extra steps.

Hadil Ben Abdallah • Jun 8

Haha I get the vibe behind this 😄

But in real life projects… I think it’s a little more complicated.

Most of us don’t start with any or // @ts-ignore as a habit; they usually pop up as temporary survival tools when you’re dealing with messy legacy code, third-party libs with weak typings, or tight deadlines. It’s a bit like duct tape, not the perfect fix, but sometimes it keeps things going while you sort the real problem out properly later.

The big difference is if it stays temporary or if it becomes a habit 😅