Picking the tech from which to develop an application is about picking your battles. That’s something I’ve come to realize more and more.

Tech stack: A term used for the collection of technologies that underlie any given application. Furthermore it’s often useful to picture an application as a stack of layers (technologies) that build upon each other.

Let’s start with a question. Imagine you have a certain problem at hand and you see that this could be solved by creating an application. You’ve solved similar problems before with technologies you’ve since become familiar with. This is a project where you’re free to choose between whatever technologies you want. Anything goes.

What will you do? Will you:

• A: Choose to build a solution using a programming language you know super well and a tech stack you’re very familiar with.
• B: Choose to use a new programming language on a new platform with technologies you’ve only heard of before.

We tend to want B. #

For me it depends on whether it’s a work project or a side project. For a work project you should definitely consider what technologies previous applications have been built upon and the skills of your colleagues so that you don’t create something that’ll be a pain to maintain for anyone but you.

Nevertheless, some companies thoroughly incorporate alternative B into their work. Under the banner of micro-service architecture many companies base their business on small applications built with many different languages that uniformly speak HTTP to each other. However, I would argue that if a team of ten use a mature tech stack for most of their applications they might well have an easier time helping each other out.

I always want to go for alternative B but for work it’s often wise to use something tried and true. But definitely not always. Specifically that would be when the problem is much better solved by a different tech stack regardless of whether or not the team know the stack well on beforehand. What it would then boil down to is whether or not the team can agree that they would like to spend the time learning this new technology.

Even in side projects it’s important to pick your battles. While building with new tech does wonders for inspiring you to work on that project it might also add friction to completing the project. Once the novelty wears off you might get distracted about some new tech that you just want to build something with.

I’m currently battling with this these days. I’m mid-way building a small side project and I’m now starting to wonder whether I should switch from using Angular 1.x to Angular 2.x or maybe an entirely different tech stack. I’m even considering switching out some of the individual layers in the stacks. Phew. The madness is real, haha.

Funnily enough all of this will be invisible to the end user. What users will see is just whether or not I was able to get the application usable and out into the world.

This reminds of the tech saying, “ship early and often.”