Tiny struggles

Always something.

I prefer boring technologies

When I start new projects I try to build them with boring technologies that I used before and I try to limit picking up new libraries, tools and technologies to a minimum.

This is because I want to build actual products and not to do projects for the sake of learning exciting technology.

I chose boring technologies because:

  • they are proven & dependable
  • I can focus on building a product
  • challenges specific to a product keep it interesting and I don’t need shiny tech novelty

If you want to build cool things, you should consider doing the same.

Boring == proven & dependable

Often the reason why something is boring is that it’s been around for a while and it’s popular.

Those are good things! This means that many bugs have already been found and fixed. This means that many people hit various issues with this technology and lived to tell their tale.

On the other hand many new shiny things have lots of unknown issues. You might be the first person hitting a particular problem and that can happen to you every month.

Another issue with shiny tech is that it might not be here anymore after a couple years if they don’t get wide adoption. Boring technologies on the other hand have communities of maintainers and many companies behind them.

Boring == familiar → can focus on building a product

What is boring is often familiar which means that I am more fluent using it.

Instead of focusing on how I can implement an API, I can focus on what I want within the API. The implementation is straightforward.

I really believe that you have a limited number of “innovation tokens” while working on something new. You can spend them innovating on the product or on learning a novel technology.

However unless the technology itself is a distinguishing factor for your business or product, you should minimize using your tokens on the novel tech. Your users won’t care if you are using Vue or Svelte or React as long as your app is fast and easy to use and solves their problem.

Technology stack vs technology alternatives

Is the framework the fastest and the coolest? Probably not, it’s possible that there are alternatives that are slightly better.

I want to focus on learning and mastering a set of complementary and not alternative technologies, because this makes me more effective developing things full stack myself. Alternative technologies would be like React and Angular or Python and Ruby. Instead, I develop an expertise in a stack of complementary technologies, like JavaScript and SQL or python and dev ops.

Having many alternative solutions deployed increases your complexity significantly. The technology combinations in your stack grow very fast. So keep your tech life simple and focus on the product instead.

Boring technology - but an interesting project?

Won’t you get bored if you are only using proven technologies or keep using the same libraries over and over?

This is a risk to some extent, especially if you have lots of boilerplate. Many products require the same things: users, authentication, payments, email. But after you get the basics out of the way, then what is left is specific to the problem you are going to solve and that is different with each product.

And there are so many unique challenges to each product, the data modeling, API design, UX, design and so on!

Building end to end products is exciting!

Summary

To sum up:

  • boring technologies are more dependable
  • focusing on couple of solutions creating a consistent stack helps me master them and makes my life simpler
  • developing products is often more interesting than dabbling in technology for technology’s sake

If you want to read more about boring technologies, I found these slides pretty helpful.

If like stuff that I write, please follow me on twitter where I post about technology and my Indie Hacker journey.