Why TypeScript changed how I code

I used to think TypeScript was just JavaScript with extra steps. Verbose, annoying, something senior developers insisted on because they'd been burned before. I was wrong, and it took a specific kind of humiliation to understand why.

The bug that converted me

Six months into my first serious project, I had a function that was supposed to return a user object from an API response. Somewhere in the chain, the API occasionally returned null for the address field. My code assumed it always had a value. It worked perfectly in testing. In production, it silently crashed for about 8% of users — just a blank screen, no error message, nothing useful in the logs.

In TypeScript, that entire class of bug is caught before you ever run the code:

type User = {
  name: string;
  address: string | null; // forced to acknowledge this
};

function getCity(user: User): string {
  return user.address.split(",")[0]; // TS error: address might be null
}

The compiler would have screamed at me on line two. Instead, I spent three days debugging a runtime error that showed up only under specific network conditions.

How it changes the way you think

The deeper shift isn't about catching errors. It's about how you design before you write.

When you have to define types, you're forced to think through your data structures before you touch the implementation. What does a BlogPost look like? What fields are required vs optional? What are the possible values for status? In JavaScript, these questions are implicit and often answered wrong. In TypeScript, they're answered up front — and if you answer them wrong, the compiler tells you everywhere that matters.

TypeScript isn't a type-checker. It's a design tool that happens to also check types.

I started writing my interfaces first. Define the shape, then write the logic that operates on it. It's a small ritual that consistently produces cleaner code.

The DX improvements are real

Beyond correctness, the developer experience is genuinely better:

• Autocomplete that actually works — not guessing, actual knowledge of what properties exist
• Refactoring that doesn't break quietly — rename a field in one place, every other reference breaks visibly
• Self-documenting functions — the signature is the documentation for the common case

When I open a TypeScript codebase I've never seen before, I can follow the types to understand what's happening. When I open an untyped JavaScript codebase, I'm reading context clues and hoping the variable names are accurate.

The migration is worth it

If you're sitting on a JavaScript project and wondering whether to migrate, my answer is: yes, but incrementally. TypeScript supports // @ts-nocheck for files you haven't gotten to yet. You can migrate file by file, turning on strict mode as you go.

The upfront cost is real. The long-term payoff — in fewer bugs, faster refactors, and more confident deployments — is bigger.

Final thoughts

TypeScript didn't make me a better programmer by teaching me new algorithms. It made me a better programmer by forcing me to be more explicit about what I was actually building. That kind of friction, it turns out, is exactly the right kind.

If you're still on vanilla JavaScript for anything serious, I'd encourage you to try one file in TypeScript. Just one. See how many implicit assumptions the compiler surfaces in the first ten minutes.