We’ve all been there. You see everyone hyping up a new tool or “best practice” and think, “They’re missing it.” It’s tempting to feel like you’re the only one who sees the flaws. But here’s the thing: even if everyone else is wrong, that doesn’t make you right.
Being a developer isn’t about standing apart just to be different. It’s about staying curious, asking questions, and testing what works. Instead of assuming others are off track, consider asking yourself:
<ul>
<li>What real problem does this solve?</li>
<li>Is there a part of it that could actually work for me?</li>
<li>Am I rejecting it because it’s popular?</li>
</ul>
What do you think? Have you dismissed a tool, only to find it useful later? Or stuck to your view and been right? Let’s discuss.

The hottest most controversial dev discussions. Found something you'd like to share? Add it in the thread 👇


controversy.dev

In the realm of software development, it's easy to dismiss popular tools or best practices, thinking they miss the mark. However, just because the majority might be wrong doesn't inherently make an opposing view right. Developers should maintain curiosity, ask probing questions, and test what actually works for their specific needs instead of rejecting ideas merely due to their popularity.

Everyone might be wrong, but that doesn’t mean you’re right

I’ve often felt exactly the same—sometimes things just seem unnecessarily complicated. But then there are moments when I immediately recognize the value of something, and it just clicks. Either way, my perspective tends to shift as I gain more experience.
That said, even after 10–15 years working with some technologies, I still can’t wrap my head around why certain things have to be so difficult. My focus has always been on practical value—what makes sense for me as a developer and, more importantly, for my clients.
Here’s where I’ll throw in a wild confession: I still don’t really get the point of writing tests. I’ve been doing it almost daily for over a decade, but aside from justifying more billable hours, I haven’t seen how it truly improves quality. If anything, it feels like it adds complexity and creates more opportunities for things to break that wouldn’t have been an issue otherwise. Maybe I’m just doing it wrong.
On the flip side, TypeScript? Total game changer. Once I got used to it, I couldn’t imagine coding without it. It’s one of those tools that just works and adds genuine value.
For context, I’m the kind of person who focuses on the big wins—the first 90%—rather than obsessing over the final 10%. It’s about prioritizing what delivers the most impact upfront. This mindset helps me avoid overengineering and keeps me centered on delivering practical, effective solutions for both myself and my clients.

I think, very early on, I was highly skeptical and thought ChatGPT was a load of garbage. However, since other tooling has come out, I’m totally onboard. Perplexity offered a better way to “chat gpt” and then Unblocked built a plugin that can actually help engineers on my team, including myself, get “unblocked” when we’re working.
I still don’t see “AI” taking my job anytime soon… That skepticism will remain for the foreseeable future.

“Absolute rules are the last refuge of the incompetent”
everything has it’s usecase, everything has pros and cons and everyone values these differently

I dismissed Kotlin when it came out, forced myself to use it and I’ve never looked back. I hated PHP till i tried it. What I am saying is, as a developer, do not get emotionally attached to any tool. Yes, your current tool makes you faster, but be always open to use something different if required. Cheers

In my case, I think I fall on the opposite end of the spectrum. I tend to get overly enthusiastic about new technologies, likely because I’m still building my experience. Meanwhile, my colleagues take a more cautious approach when it comes to adopting new tools.
At the end, there’s certainly no harm in experimenting and enjoying new tech, but a balanced dose of caution is wise, especially when planning for long-term use.