Two years ago I was skeptical of TypeScript. It felt like bureaucracy — extra syntax, extra files, extra config, all to tell the compiler things I already knew.
I was wrong, but not for the reasons TypeScript evangelists usually give.
It's not about catching bugs
Yes, TypeScript catches bugs. That's the pitch. Type errors at compile time instead of runtime. Fewer production incidents. I get it.
But the deeper value is that TypeScript forces you to define your data before you use it. You can't hand-wave over the shape of an API response. You can't assume a function argument is always a string. You have to make implicit assumptions explicit.
That discipline makes you a better programmer even when you're not writing TypeScript.
Where it actually helps
The moment TypeScript clicked for me was refactoring. I changed the shape of a shared type and the compiler immediately showed me every file that needed to be updated. Not as a test failure. Not as a runtime error. As a list.
That's the superpower. Fearless refactoring at scale.
Where people go wrong
Typing everything as any and calling it TypeScript. Using it as documentation-only and not actually leveraging inference. Fighting the type system instead of working with it.
TypeScript rewards patience. When the compiler resists you, it's usually telling you something important about your design.
Two years later
I don't think about the types anymore. They're just how I think about data. The annotations are almost automatic.
What changed is that I ask better questions earlier: what is this thing? What shape does it have? What can it become?
That's not TypeScript. That's just thinking more clearly.