I’ve been coding for nearly a decade, and I still enjoy writing code — across different languages, for different problems. But one thing that’s always bugged me is the community.
Don’t get me wrong: coding communities can be amazing, helpful, and generous. But they’re also filled with ego battles — endless fights over which language is “better,” which one makes you a “real” programmer, and why you’re somehow lesser if you’re using that language instead of this one.
Here’s the thing: at the end of the day, all programming languages are just tools we use to tell machines what to do. Everything eventually gets translated down to machine code. I’ve seen people argue about this in offices, online, and among friends — and yes, I’ve been sucked into it myself.
Early in my career, I worried that writing too much JavaScript would mean employers wouldn’t take me seriously. After all, JS has been called a “toy” language more times than I can count. So, I branched out. I learned Go (which was trendy at the time), touched C, and leaned into Python — the language that helped me land interviews but which I hadn’t taken seriously at first.
Today, my two go-to languages are TypeScript and Python. They fit my work perfectly. Sure, I fully acknowledge that languages like C++ and Go offer superior performance and raw speed. But in my line of work, the bottleneck isn’t the code’s speed — it’s the number of systems, APIs, and databases my code needs to coordinate with, plus the constant shifting of business requirements. I often have to tear down previous logic and quickly build new solutions. Here, developer velocity far outweighs app velocity.
Could I squeeze more performance out of other languages? Maybe. But my job isn’t to obsess over micro-optimizations. My job is to solve problems, ship working solutions, and keep businesses running smoothly — often under tight timelines.
So here’s my realization after all these years: I have a favorite language, and by some standards, it’s one of the “worst” languages. And I love it.