When Code Becomes a Tool, Not an Identity

As software engineers, it’s easy to get attached to the languages we use. Sometimes we debate their merits passionately—with teammates, in forums, or even with ourselves—trying to explain why one language feels better than another.

That attachment often stems from familiarity. Maybe the language we love was our first serious exposure to programming, and it just made sense. Or perhaps it has a robust ecosystem that solves problems elegantly, or its syntax aligns with how we think. Whatever the reason, there’s often a personal story behind our preferences.

I remember feeling that way about Java. It was the first language that really clicked for me. I’d dabbled in JavaScript, ASP.NET, and C++ before, but they didn’t feel intuitive. Java did. Naturally, I leaned toward it—and looked skeptically at anything that didn’t fit that mold.

But as I progressed in my career and had the opportunity to work with other languages—C#, C, Python, TypeScript—I began to see things differently. Each language brought something valuable to the table. They offered different perspectives on how problems could be solved, how ideas could be expressed, and how systems could be structured.

It became clear:

Programming languages are tools, not a religion.

Good engineering starts with detachment. When we tie our identity to the tools we use, it clouds our judgment. We risk prioritising familiarity over suitability, or preference over practicality.

Being a professional means putting the problem first. It means asking: What does this situation require? Sometimes the answer is a modern, expressive language with great developer ergonomics. Other times, it’s a mature platform with decades of ecosystem support. And occasionally, it’s whatever the team already knows best and can move fastest with.

Ultimately, our goal isn’t to champion a language. It’s to solve problems—clearly, reliably, and with care.