The best tech stack for your project in 2020

Published August 05, 2020, 3 min read, tagged as: careerstrategyleadership

There's two philosophies when it comes to choosing the right tech stack.

1. First solve the problem. Then write the code.

What makes your product unique? In most cases it's not the technology used to solve the problem, it's the solution itself. When you have a problem we want to solve we can put it through 3 stages:

Outline the problem scope

• What is the underlying problem?
• Is the perceived problem actually just a symptom of a deeper underlying problem?

Dive deep in to the problem

• Do you know everything you need to?
• Do you have all the facts?

Create a solution

• What assumptions are being made?
• What are the barriers of entry?

I spent a brief period of my life consulting for large enterprises. Most of my experience is with startups so this was a great change of pace to understand systems at scale. One of the biggest differentiators is their willingness to research and choose the right tools for the job. One such consulting position took me to a company that would automate managing hotel room inventory on sites like Orbitz and Expedia. When someone booked a room on one site, the inventory change would propagate across all the other sites. The original system was built using PHP but it got to a point where the language became a bottleneck to scale. The team took a hard look at the problem and decided collectively to learn Java and reimplement the solution. It was a bold move but in the end it worked for them. Once they were done, I asked a few of the developers how they felt about the decision and what they learned.

The general consensus when they looked retrospectively is that it was the right move to make. The big advantage with this approach was that they didn't limit themselves to their abilities or knowledge of technology. This allowed them to actually innovate and create something new.

The biggest downside they experienced was that it created a learning curve that wasn't suited for everyone. The decision was made by the majority rather than having consensus, and some felt forced to either learn the technology or risk being replaced. If this doesn't appeal to you, then you may be better suited for the second option.

2. The right technology is the one you're already familiar with.

Your best work is done when you're doing things you're good at and things that you love. If you already have familiarity with certain technologies, that may be the best place to start. Your competency helps you find like minded individuals that can help you get going and thats a great place to start.

I learned this lesson the hard way. I've had to learn new languages at almost every job I've had. This gave me the mindset that if I can do it, anyone can. Not true! Everyone has different aspirations and motivations. Some want to be generalists and learn a bit of everything, others want to be specialists and be really develop their core competencies.

When I first started with my current company I inherited a big monolithic Ruby application, a language I was totally unfamiliar with. I had to make progress as I learned and that meant figuring out how to work smart. There was no admin panel as such at the time and most of the internal operations such as setting up new clients had to be done manually. I decided to create a simple admin panel using Angular and hand it off to the implementation team to allow them to work autonomously and buy myself some focus time to learn Ruby. It was a decision that I knew wouldn't scale but one that I thought I wouldn't have too much of an impact. When I hired more developers I focused on Ruby and not Angular because I didn't think it mattered. Wrong! What ended up happening was the Angular admin panel became a stress point for the team because nobody else knew or cared about Angular enough to maintain it. We would have had better luck if the technology choice better suited what I was planning to hire for, or if I'd explicitly focused on familiarity with Angular as I grew the team.

So what's the best stack for your project? It depends.

I tweet about this type of thing a lot. If you enjoyed this article, you may enjoy following me.