"Use Python!"
"No, use .NET!"
"Just use Loveable and call it a day."
It’s all-too-common to see these kinds of arguments online. From language wars to framework fanboys to “best tech stack” hot takes. But do they actually hold any weight, or are they just uninformed keyboard warriors begging for attention?
Tech tribalism isn’t new, but the internet has made it louder than ever.
The Rise of the Keyboard Warrior
In the golden age of developer discourse (read: toxic Reddit threads and Hacker News comments), you’ll find no shortage of people passionately defending their favorite tools. They’ll swear Python is the “only sane choice,” call JavaScript “a necessary evil,” or insist .NET is the holy grail of backend development.
But here’s the catch: these debates rarely happen in the context of real-world constraints, like deadlines, budgets, legacy systems, or client expectations. In other words, the “best” language doesn’t exist in isolation. It exists in context.
The Myth of the Perfect Stack
Every programming language or framework was created with a problem it was designed to solve. Python wasn’t built to replace C++, .NET wasn’t designed to dethrone Node, and JavaScript, bless its heart, wasn’t meant to run your toaster (yet, although I'm sure someone has taken a shot at it...).
When developers argue in absolutes, they forget that engineering isn’t religion. It’s tradeoffs.
Real craftsmen know that picking a stack is less about ideology and more about intent.
Tool Familiarity Over Tool Fandom
A seasoned developer can ship a great product in nearly any mainstream stack. Why? Because they understand principles: design patterns, architecture, testing, and deployment. Today, the biggest development learning curve is syntax.
You could hand a carpenter a cheap hammer, and they’d still build something sturdy. Give an amateur the most expensive tools on the market, and you’ll still end up with a wobbly table.
The AI Factor
Generative AI tools like ChatGPT and Claude Code can write code, refactor functions, and even generate entire applications.
But they can’t (yet) replace judgment. They don’t know why something should be done a certain way. Worse, they can write confident, elegant code that’s subtly dangerous (or just plain wrong).
A real craftsman knows when to say, “That looks good… but it’s not right.”
The Bottom Line
Choosing the right tool for the job really boils down to four key points:
1. Does the implementer know the tool like the back of their hand?
This matters even more in the age of AI pair-programming. A good developer should know when to step in, debug, and correct code instead of just trusting it blindly.
2. Can the implementer use the tool efficiently and effectively to deliver craftsman-quality, production-ready solutions?
Code that runs isn’t enough. It needs to scale, be maintainable, and actually solve the problem.
3. Is the tool widely known enough to be maintained by another developer or team?
Building in obscure tech might make you feel clever... until your successor spends two weeks trying to understand your custom stack.
4. Does it fit the problem?
Choose the tool that solves the problem best, even if it’s not your personal favorite. A good developer can separate preference from practicality.
Final Thought
At the end of the day, real engineers don’t argue about tools, they deliver results.
So the next time someone says, “Just use X,” remember: it’s not about what you use. It’s about why you use it.
Want a team of expert craftsmen to audit your tech stack or build custom solutions using the right tools? Contact us for a free audit and discovery call.