Hadil Ben Abdallah

Posted on Jun 8

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

#webdev #typescript #bash #programming

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 (38)

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 😂

Mary Olowu • Jun 9

Am ashamed to say I have done this once. But, I did circle back at least. I was having one of those frustrating typescript type loop issues

FrancisTRᴅᴇᴠ (っ◔◡◔)っ • Jun 8

annnd the Saga continues! Good stuff Hadil!

Hadil Ben Abdallah • Jun 8

Haha yeah 😄 The saga definitely continues!
Thanks, Francis! Glad you enjoyed it.

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 😂

Sylwia Laskowska • Jun 8

Haha sooo real! I love this series 😂

Hadil Ben Abdallah • Jun 8

Haha thank you, Sylwia! 😄
I'm really happy you're enjoying the series!

Scarab Systems • Jun 9

This is very real 😅

My most TypeScript-developer moment lately was digging into an auto-import issue where the code looked fine at the surface, but the package export boundary was not being respected the same way across paths.

That’s one of the things I appreciate about TypeScript even when it’s frustrating: the pain is usually pointing at a contract somewhere. Sometimes it’s a type contract, sometimes it’s a module boundary, sometimes it’s a package shape that the tooling has to interpret consistently.

And yes — any and // @ts-ignore are basically “I’ll deal with future-me later” buttons. Sometimes necessary, always dangerous if they become permanent furniture.

The red squiggles are annoying, but the worst bugs are the ones where the squiggles go away because we taught the repo to stop asking the question.

Hadil Ben Abdallah • Jun 9

This is so real 😄

Auto-import / export boundary issues are one of those “everything looks correct… so why is nothing correct?” moments 😂 You can stare at the code for ages and still feel like the problem is gaslighting you.

And yeah, TypeScript isn’t just complaining randomly; it’s usually pointing at some contract breaking somewhere, even if it takes a while to track down where that boundary actually is.

Scarab Systems • Jun 10

Exactly 😂 That “everything is valid in isolation, but invalid once the package boundary gets involved” feeling is brutal.

That’s what makes these bugs so sneaky to me — the code is not obviously wrong, the types may not be obviously wrong, but the tooling is making an assumption about where a symbol is allowed to come from.

It’s less “TypeScript is yelling at me” and more “the repo is quietly revealing that one of its contracts is leaky.”

Alois Sečkár • Jun 8 • Edited

// @ts-ignore gets rejected by my ESLint rules 🥹 It enforces // @ts-expect-error <WHY?>

Hadil Ben Abdallah • Jun 8 • Edited

Haha that’s actually a really solid setup 😄

Forcing a reason next to '// @ts-expect-error' is one of those "painful but good for you" rules, similar to making future-you think twice rather than simply silencing the error and moving on.

Aryan Choudhary • Jun 8

Been a while I coded something up, kind of nostalgic but fun read!! 😆

Hadil Ben Abdallah • Jun 8

Haha I know that feeling 😄

There’s something really nostalgic about TypeScript (and coding in general); once you step away for a bit, you forget the frustration… and somehow only remember the fun parts 😂

Glad it brought back those vibes for you!

Klaudia Grzondziel • Jun 8

Ahaha, funny article and cool collab with Sylwia! 😄

Hadil Ben Abdallah • Jun 8

Haha, thank you! 😄 I'm glad you enjoyed it!

And yes, Sylwia's post was a big part of the inspiration to continue this series. I loved the idea of taking those shared developer experiences and giving them a TypeScript twist 😅

Klaudia Grzondziel • Jun 8

Would you mind if I joined you with "You’re a Real Technical Writer Only If..."? 😁

Hadil Ben Abdallah • Jun 8

Absolutely! 😄 That sounds like a cool idea 😍

One of the things I enjoy most about these posts is seeing people add their own version from different corners of the tech world. Developers, designers, DevOps engineers, technical writers...

"You're a Real Technical Writer Only If..." edition sounds like it could be both hilarious and painfully relatable.

So excited to read your piece and see my struggles in the list 😂

Fredrik Wiking • Jun 9

When my strict typing resulted in a problem detection and I opened up a PR in hono/middleware

//Problem
export type OpenAPIHonoOptions<E extends Env> = {
  defaultHook?: Hook<any, E, any, any>
}

//Fix
export type OpenAPIHonoOptions<E extends Env> = {
  defaultHook?: Hook<unknown, E, string, Response | void | Promise<Response | void>>
}

Reasoning:

T: unknown — defaultHook is a catch-all that applies to all routes regardless of their specific input shape. unknown is the correct type when the data type cannot be known at this level (as opposed to any, which silently opts out of type checking).
P: string — a route path is always a string. Using any here causes c.req and related path-typed members to resolve to any.
R: Response | void | Promise — these are the only meaningful return types for a hook. any allows returning anything, including values that would be silently ignored.

Hadil Ben Abdallah • Jun 10

This is the best example of “strict types feel annoying until they save the whole design” 😄

And honestly, this fix is really clean; switching from any → unknown is exactly the right move. It keeps the flexibility but forces the consumer to actually prove what they’re doing instead of bypassing the system.

I also like how you broke down the reasoning (T / P / R). That’s the part a lot of people miss when they first tighten types. It’s not about making things harder; it’s about making the boundaries explicit so nothing leaks in silently.

And yeah… any in a shared middleware API is basically an open door for accidental chaos 😅

This is the kind of small type change and big long-term safety win that makes TypeScript worth it 🙌🏻

Self-Correcting Systems • Jun 9

The "this should only take an hour" curse is real. I once estimated a quick type
migration before a product demo and spent the next two hours explaining to TypeScript
what I thought I meant. It was right the whole time. The worst part is knowing that and
still saying it the next time.

Hadil Ben Abdallah • Jun 9

Haha... This might be the most accurate description of the curse I've seen so far 😂

The real tragedy isn't that it happens once. It's that we all know exactly how these stories end, and yet the next time we see a "small" migration or "quick" type fix, we're right back to saying: "This should only take an hour" 😄

When it comes to estimates, developers have the shortest memory, but when it comes to humbling us with TypeScript, they have the longest memory.