Strict Typing is Better? What 20 Years of Coding Taught Me.
If you’ve spent more than five minutes in a developer community, you’ve seen it. The debate. The one that never ends. “Strict typing is better!” “No, weak typing is better!” “You’re wrong!” “No, YOU’RE wrong!” It’s the programming equivalent of pineapple on pizza, except people somehow get even more heated about it. Maybe I should write an article about pineapple on pizza. Hmm.
I’ve been coding for about 20 years now. I started with C, but I quickly got tired of the compiler insulting me and my entire family just because I forgot an asterisk. So, I moved to C++ and instantly fell in love with it. I kept learning and making apps with it for a year or so, then dove headfirst into PHP and JavaScript. I’ve written code with types so strict they’d make a compiler blush, and code so loosely typed it made ME blush. And after all that, I have a definitive, absolute, unshakeable answer to the great debate.
Strict Typing is Amazing
When I first learned C and C++, I noticed something: the compiler wouldn’t let me get away with anything. Forgot to handle a type? Error. Passed the wrong argument? Error. It was annoying at first, but it was also catching bugs before I could even run my code. It’s like having a mini automated test suite built right into the language.
And those strict rules? They made me think before I typed. I had to consider my data shapes upfront, decide what a function takes and returns before writing the logic. It enforces intentionality, and that intentionality tends to produce cleaner code.
Modern IDEs are incredible no matter what language you use, but with strict typing, they shine even brighter. Autocomplete, inline errors, go-to-definition… they all become more reliable when the language itself knows exactly what type everything is. It catches more problems, more easily, and more automatically.
Personally, strict typing made me a better developer faster. When I was starting out, the type system was like a guide. It told me what I could and couldn’t do, and that structure helped me find my footing. Even now as a senior dev, I find that onboarding on a strictly typed codebase is smoother for me. The types tell a story about how the code is meant to be used.
And let’s not forget the classic: “5” + 3 = “53”. If you’ve never been woken up at 2am by a bug that turned out to be an implicit type coercion… well, maybe you’ve only ever worked with strict typing! JavaScript in particular has some very… creative ways of coercing types.
Yep, strict typing really is amazing.
Weak Typing is Amazing
I love TypeScript. Like, genuinely love it. But every time I need to write a quick script, I reach for plain Node.js. I used to feel guilty about it, like I was cheating on my lover. I’ve matured since then.
And that’s kind of the whole point. Sometimes, you just need to write something and have it work. No type definitions, no generics, no interfaces. Just code that does the thing. For prototyping, quick scripts, MVPs, hackathons… weak typing lets you hit the ground coding.
It’s also a much friendlier entry point for beginners. Learning to code is hard enough without having to understand type systems on day one. Weak typing lets you focus on logic first, structure later.
And the flexibility is real. A function can accept whatever you throw at it, no overloads or union types required. Less boilerplate, less verbosity, the code is more concise and the thing just works.
There are also problems where strict typing would actively get in the way. When the data is by nature always changing, very dynamic, typing it strictly would be very hard at best, impossible at worst. Ever spent a whole day just trying to figure out how to write your types correctly? Asking for a friend.
And some developers simply think more fluidly without type constraints. Their code is just as clean as anyone else’s.
Typing is the Friends We Made Along the Way
So… strict typing is amazing. Weak typing is amazing. Both have real, undeniable strengths. But when you pick one over the other, it really comes down to one of two reasons: either the project needs it, or you prefer it. That’s it.
And preferences are cool! They’re part of what makes us who we are as developers. I love hearing about why someone prefers a language, what clicked for them, what makes them productive. That should be something we bond over. “Oh you love Rust? Tell me about it! What got you into it?”
But instead, what I see most of the time is flame wars. Developers treating their preference as objective truth. “I write better code with strict typing” quietly becomes “strict typing produces better code” which somehow becomes “if you don’t use a strictly typed language you’re a shitty dev.” And the other side does the exact same thing.
A friend of mine, a developer I deeply respect, once told me he doesn’t like strict typing. I was baffled. Not because of his opinion, but because he just… stated it. Calmly. No argument, no justification, no “and here’s why you should agree with me.” Just a preference. And it hit me how rare that had become.
The Cold Take
Developers, and any expert of any field for that matter, should stop treating their personal preference and experience as universal truth, and start learning from what others do differently. Enjoy it. Celebrate it!
I really dislike Ruby. I’ve had personal bad experiences with it. But if you made something exciting with Ruby, I would love to dive into your code and learn from your experience.
Technical expertise is only half of what makes a master. The other half is the ability to share it with the world with an open mind, and an open heart.
