As a software engineer, it’s easy to get caught up in the details of programming languages and practices. Maybe you believe that one language is superior to all others, or that microservices are better than monoliths.

But here’s the question you need to ask yourself: how much do these things really matter in the grand scheme of things?

I Was a True Believer

I used to think that picking the right programming language mattered more than anything else.

When I was a junior developer, I was convinced that picking the right programming language was the key to innovation. I read Paul Graham’s Beating the Averages with zeal. I learned everything I could about Smalltalk, Lisp, and Haskell.

I still think that many ‘modern’ programming and DevOps tools feel like trying to build a skyscraper with sticks and stones compared to the magic available 40+ years ago on Lisp machines and in Smalltalk-80.

Technology Matters Less Than You Hope

But the truth is, in a world with amazing open-source tools like Django, FastAPI, Ruby on Rails, Qt, and countless others, it’s tough to beat the averages because the averages are now pretty darn good. And beating them doesn’t buy you as much as it used to.

Regardless, the average user doesn’t care what programming language you built your app with.

As engineers, we’re tempted to think everyone cares about technical details as much as we do, but most people just want things to work. And when the chips are down, engineers usually don’t care either.

For example, read this tweet by @levelsio discussing how RemoteOK generates over $100,000 per month in revenue with a single PHP file as its backend.

Of all the engineers and techies who found remote jobs via RemoteOK, how many of them do you think got upset about its backend? I’d bet it’s a rounding error.

Make Pragmatic Engineering Choices, But Don’t Be Reckless

None of this means good engineering doesn’t matter at all. A maintainable, readable, and clean codebase is certainly better than a messy, hard-to-understand codebase. Testing is crucial, and following best practices for security and performance is vital.

Beware fake productivity

But it’s also important to recognize that debating languages and tools and conceptual purity can feel like productivity, when in reality it’s a waste of time.

A team that chooses ‘boring’ tools like PHP and Laravel and gets down to work will likely progress more quickly than a team that spends its first month arguing about whether to use Rust, Go, or Elixir.

Pick tools that get the job done

The same is true when it comes to the trade-offs between different libraries and tools. For example, choosing between a relational database or a document database can be a contentious topic.

But will using Postgres instead of MongoDB make or break your company? Probably not.

Will choosing Express over fastify ruin you? Unlikely.

Ultimately, the best choice depends on what you’re creating. In many cases, the specific tech you choose matters less than you wish it did.

Yes, you might make the wrong choice. It happens. Make the best choice you can with everything you know right now, and change your mind down the road if necessary.

The smaller you are, the more pragmatism matters

The idea that technology choices don’t matter as much as we think applies doubly to solopreneurs and early-stage startups. Getting a product to market and learning about customer needs is paramount.

Use, PHP, Ruby on Rails, Qt, React Native, or whatever lets you start delivering value to users ASAP.

Sometimes, Technology Gives You An Advantage

With all that in mind, you should still use your brain. Remember that sometimes technology does matter, especially when it gives you a competitive advantage.

For example, if you’re building app aimed at a niche that values real-time UI and dashboards, using Elixir, Phoenix, and LiveView might help run you circles around competitors struggling to build similar solutions using Node.js, Socket.io, React, Recoil, duct tape, and hope.

In short, remain aware of how can help you compete. If you like the idea of disrupting a market with technology, work hard to stay up to speed on markets you care about and technology that might help you disrupt them.

The Game Changes When You Need To Scale…

Making simple technology choices early means you’ll need to revisit them as you scale. For example, a startup that has found product-market fit and is consequently growing rapidly should spend serious time, thought, and salary on architecture and engineering.

But even when you’re scaling, remain cautious and try not get caught up in technical bike shedding. Twitter got a long way using Ruby on Rails, not exactly known for its speed. Yes, the fail whale showed up too often. But people kept using the platform.

And Shopify, a $60 billion company, is at its core still a monolithic Rails app (albeit with plenty of help from Go, React, and others.)

…Or When You’re Already At Scale

Similarly, when working on an app already operating at scale, aim for engineering excellence. Think about performance and maintainability.

And don’t forget that scale is relative. Ten thousand simultaneous users might seem like a lot right now. But if you’ve reached that level, there’s a good chance you’ll need to handle ten times as many in a year, so plan accordingly.

Remain vigilant, however, and remember to balance engineering goals with practicality and the need to deliver value to your users.

Finally, if you work for a behemoth like Google, Amazon, Microsoft, or Netflix, you might need to create an app that handles thousands or millions of users on day one. In that case, it’s crucial to engineer for scalability from the beginning.

Even then, you’re not focusing on technology for its own sake. You’re doing it because you must do it to meet user expectations.

Takeaway

Whether you’re a solopreneur or a cog in a big corporate machine, always consider the trade-offs imposed by your technical choices. The most important thing is delivering value to the users and meeting the requirements of the business.

Maybe you’re wondering what the heck I’m talking about because you’ve always worked on teams that made pragmatic tech choices.

If so, I envy you. I’ve worked on some great teams alongside amazing software engineers and even then, we wasted too much time on technical yak shaving that ultimately didn’t matter.

So next time you find yourself getting caught up in debates about the superiority of one language or engineering practice over another, remember: what really matters is building things that people want to use.

Without users and the business they support, there won’t be any money to pay for technology! As long as you prioritize practicality and results over conceptual purity, you’ll be on the right track.