The Non-Opinionated Engineer

Many engineers I know love a good debate. They’ll passionately argue for their favorite programming language, the “right” architectural pattern, or the one true way to manage a project. Spend enough time in the software industry and you start to notice these debates can feel almost religious – teams split into camps, each convinced their way is superior, often without much objective evidence. Think of the classic holy wars: tabs vs spaces, Java vs .NET, static vs dynamic typing. We developers tend to band together around familiar tools and ideas, sometimes forgetting that at the end of the day, what matters is delivering something that works.

Why I Don’t Join the Holy Wars

I call myself a “non-opinionated engineer,” not because I lack opinions (trust me, I have plenty), but because I don’t obsess over proving my way is the only way. While others might spend hours in heated discussion about whether Framework X is better than Framework Y, I’m usually the one asking: “Which one will help us ship the product on time?” It’s not that I don’t care about technology choices – I do. It’s just that I’ve seen multiple approaches succeed, and I find it hard to understand the needless certainty some have on these subjective choices.

Early in my career, I was that eager developer on forums, watching veterans go back and forth on the merits of one database or editor over another. At first, I thought I was missing something – surely one of them had to be right. But the more projects I worked on, the more I realized there are usually several valid ways to solve a problem. Often, familiarity and bias shape our preferences more than any absolute, empirical “best.” As one blogger quipped, software developers often exhibit a kind of fanatical faith: we follow certain methodologies or tools with an almost unwavering belief in their superiority. Yet rarely can we prove that choice A is objectively better than choice B in all cases – real-world constraints are messy, and success depends on many factors.

So, I consciously avoid getting religious about tools. If my team is more comfortable in Python than Go, or if a project’s legacy code is in PHP, I’m fine working with that. I might have my personal favorites (I’ll pick VS Code over Vim any day for productivity), but I’m not about to wage a war over it. In fact, I’ve found that adapting to the context – the team’s knowledge, the project timeline, the business needs – is far more important than enforcing my personal ideal stack.

More Than One Way to Build Software

One of my core beliefs is that there’s more than one right way to build good software. Great products have been built with all kinds of tech stacks. For nearly every hyped “best practice,” you can find a successful project that chose a different route. This perspective keeps me pragmatic. If there’s no single silver bullet, why be dogmatic?

Yes, we all have preferences. Maybe you love strongly typed languages or you swear by microservices over a monolith. Those preferences are usually born from experience – we’re productive with what we know. But I remind myself that my comfort with a tool doesn’t automatically make it universally superior. It just makes it superior for me. Another team, with different expertise, might achieve the same results taking a different path. Context matters. As an example, I’ve seen a team deliver a fantastic product quickly with what some would call a “dated” tech stack, simply because that’s what they knew well. Meanwhile, another team struggled with the trendiest framework because none of them had used it before. The lesson: the best tool is often the one you and your team wield effectively, not necessarily the trendiest one.

And when a debate arises, I like to ask: what problem are we actually solving for the user or the business? If both approach A and B can meet the requirements, the differences might not be as critical as we think. In many cases, shipping a good solution now beats aiming for a hypothetically perfect solution later. As Steve Jobs famously said, “Real artists ship.” The point is that delivering results is ultimately what makes an impact.

Outcome Over Ideology

Focusing on outcomes means I prioritize delivery over debates. I remember a meeting not long ago where two colleagues were deep in an argument about whether to containerize our app or use serverless functions. Both options had merits, but we were burning time. Finally, I interjected with something like, “Either approach can work – which one can we execute faster with the team’s current knowledge?” We ended the stalemate by choosing the option our team could implement more readily. We delivered the feature on schedule, and it worked fine. The users never cared which technology we chose; they cared that the solution solved their problem and was reliable.

That kind of scenario plays out a lot. It’s easy to get caught up chasing an elegant architecture or the “cleanest” code, but I’ve found it’s usually better to start with what gets the job done and refine as needed. In one project, I deferred using a fancy design pattern that some engineers insisted on because it would have added complexity early on. We went with a simpler approach to meet a tight deadline. Funny enough, we never ended up needing that pattern at all – the simpler solution held up. This mirrors an experience shared on the Pluralsight tech blog: an engineer enthusiastically introduced an extra mapping layer (in the name of a pattern) when it wasn’t necessary, and his pragmatic colleagues steered him away from adding something that didn’t actually solve a problem at hand. I’ve learned to always ask, “Are we solving a real problem with this decision, or are we just adding complexity because it feels ‘proper’?”

Being outcome-focused doesn’t mean I don’t value quality or good engineering practices. I absolutely do. It just means I weigh those practices against the context. Pragmatism is not laziness or a license to cut corners – it’s about being wise with our effort. One author put it well: pragmatism is a philosophy that values outcomes over adherence to arbitrary standards and encourages adaptability as circumstances change. In other words, I’ll happily write clean, well-structured code and follow best practices when they serve the end goal, but I try not to enforce rules for their own sake. If a quick-and-dirty script solves a one-time data migration faster than a fully polished tool, I’m inclined to use the script and move on. If skipping a certain test or refactor (just this once) means unblocking a user-critical release, I might make that trade-off – deliberately and carefully – and then address any debt later. It’s a conscious pragmatism, not sloppiness.

Pragmatism in Perspective

Over time, I’ve come to pride myself more on flexibility and results than on being right in theoretical debates. Interestingly, this outlook is shared by many seasoned engineers and tech leaders:

• Solving Business Problems vs. Dogma: Software architect Steve Smith observed that developers who stubbornly stick to their favorite methodologies even when they’re not called for can actually drag a project down. Their unwillingness to bend can add extra time and complexity, getting in the way of solving real business problems. In contrast, he argues that a true craftsman should take pride in delivering what the customer needs. If that means using a tool or approach that isn’t your personal favorite, so be it – you should still be pleased if it gets the job done and makes the customer happy. This really resonates with me: success isn’t defined by ticking off every item on an idealist’s checklist, but by creating value for those who use our software.

• Dogma vs. Pragmatism in Practice: In a Pluralsight blog post, an engineer recounted how he reflexively applied a familiar code pattern everywhere, due to a kind of dogma that “every mapping needs a mapper.” It took his more pragmatic teammates to question whether that extra layer was needed at all. They realized it wasn’t, and by dropping it, they avoided unnecessary complexity. It’s a great reminder that just because something is a best practice in one context doesn’t mean it’s required in all cases – sometimes “YAGNI” (You Aren’t Gonna Need It) truly applies.

• The Religion of Technology Choices: Jeff Atwood once wrote that software development has always been a bit like a religion – developers often group themselves by belief in certain tools or practices without solid proof. He poked fun at how we’re quick to declare one approach the one true way. I chuckle reading that because it’s true: I’ve seen developers almost proselytize for their preferred tech stack. Atwood’s point underscores that we should remain skeptical of absolutism in our field. If we recognize that our fiercest tech debates often come down to personal belief, we can approach discussions more open-mindedly.

• Pragmatism ≠ Lack of Principles: A thoughtful essay on DEV Community drew an insightful line between being pragmatic and being dogmatic. It noted that when the two conflict, pragmatism is usually the more desirable path for developers. Pragmatism isn’t about dropping standards or being apathetic – it’s about focusing on results and staying flexible, especially in a fast-moving tech landscape. I try to embody this by keeping an eye on the end goal (solving the problem, satisfying the user) and being willing to adjust my approach to serve that goal.

Closing Thoughts

Being "non-opinionated" doesn’t mean I have zero opinions or that I don’t care about how things get done. It simply means I’m not overly attached to any one idea, tool, or methodology. I care more that we deliver value than whether we used the trendiest framework or wrote the most elegant code on the first pass. In my experience, a pragmatic mindset leads to more productive teams and happier stakeholders, because we spend more time building and less time arguing.

In an industry where new technologies emerge seemingly every week and the “hot” best practice of last year can become passé by next year, clinging to dogma just isn’t practical. I’ve found a lot of peace (and success) in being comfortable with multiple ways of doing things. It lets me learn from others instead of instinctively fighting them, and it helps our team adapt when circumstances change.

So the next time you’re drawn into a heated debate over tech choices, take a step back. Ask yourself: is there really one ultimate answer here, or are there just different trade-offs? And which option lets us achieve our goal more effectively right now? You might find that calming the opinion wars in your head leads to clearer thinking. In the end, the software we build will be remembered for what it accomplishes, not whether we used Spaces v. Tabs 2.0 or the Ultra Hyped JS Framework du Jour. As a non-opinionated engineer, I’m okay with that – in fact, I prefer it. After all, getting the work done and delivering something useful is the whole point. Everything else is just tooling.