It was a rainy Wednesday afternoon here in Bangalore. Arjun, our key front-end engineer came and stood near my desk.
From the look of his eyes, I could tell that there was an air of anger seething in him. I could clearly sense that he wanted to offload some thoughts.
In situations like this, I normally follow a routine. I took him down for a tea & opened him up for a talk. The conversation went like this.
Arjun: Boss, why did you choose Vue as our Front-end tech stack? We will be stuck when we look out for jobs again.
Me: Why do you say that?
Arjun: My friends in other organizations say that you must know either Angular or React to survive. Big organizations normally choose to be an Angular shop.
Me: Yes, but so what? The fundamentals of front-end engineering remain the same! There is HTML templates, reactive data binding, routing and store. Angular and Vue differ only in their implementation details!
Arjun: Yeah, you are right. But you do know how the folks at HR sift through resumes…
That exact moment, it dawned on me that the decisions I took as a CTO affected my team in unforeseen ways… and when it comes to choosing technology stacks, the industry is FUBARed in more than one way.
Me: OK, let me explain why we chose Vue at our organization…
The fundamental reason why we chose Vue even when it was not uber-cool (back in Dec 2017) was that you could write blazing fast and stable components with Vue, while enjoying the benefits of all the standard batteries (router & store) integrated.
In short, Vue makes you go from concept to reality in the fastest way possible, because of You (this You is Evan You BTW 😆).
Secondly, we wanted to build our front-end web application on a well known design system — Material Design, so that we could move away from discussions on how a button should look like — to what the user will value. Based on this, we chose Vuetify, a material design component framework based on Vue.
With the above combination of Vue + Vuetify, we were able to build front-end for an end to end digital lending platform in record six weeks.
So, what is the point am I driving home with this?
When you choose a tech stack, have a handful of satisficing (i.e. must have) metrics which you cannot compromise on and drive your decisions around them. For us, it happened to be “Go from concept to reality in the fastest way possible & with ease”.
But what about the core issue raised by Arjun in the conversation above? How should he go about acquiring transferable skills?
To address this, you need to segregate two distinct things at play here, as illustrated below:
- The core concepts at play when it comes to any front-end framework are HTML templates, reactive data binding, form processing, routing and store. A few core principles such as Single Responsibility Principle and Dependency inversion are also relevant.
- The framework specifics like how you iterate through a list in a template, of course are different between frameworks.
As long as you are strong on the core concepts, you can always deal with framework specifics in a short period of time.
Now what about the backend world?
The debate & the fears are pretty much amplified in the backend world.
It is not quite uncommon in the Backend world to look down on Python in lieu of Java. You may hear things like Python is slow & you cannot produce anything SOLID with it (pun intended there. Look here for an explanation of SOLID, just in case).
Again, the way to wade through these waters is through a handful of carefully chosen satisficing metrics.
Our metrics for the backend stack were as follows:
- We were clear from day one that we wanted to build for cloud native, with microservices. So our laser-sharp focus was on domain decomposition.
- Being a B2B business, we knew that the services are not going to run 24/7 and we can save huge with serverless. Hence, we naturally wanted a language with the lowest cold start times. Even for services where cold starts could not be tolerated, we knew that we could go with containers on kubernetes.
- The team was young & small. The focus was on iterating fast & delivering incremental value to the stakeholders and ensure that we are building the right stuff in the first place.
Python satisfied all the above metrics with aplomb & we ended up creating a scalable cloud native backend platform
- that is robust
- with no technical debt
- the team is comfortable breathing with
- The team has the confidence that they can (proudly) explain what is built to someone else who joins later
OK, and… what about transferable skills on the backend?
We chose to focus on domain driven design, reliability, scalability & extensibility of the platform. (Side note: This post describes our best practices for building cloud native application from grounds up)
I was finally able to comfort Arjun with the following closing lines:
Choose a tech stack based on key satisficing (must-have) metrics.
Understand what the overarching fundamental concepts are & apply them effectively.
Ensure that the team can breathe with the stack & is NOT going to create technical debt out of what you are building.
Ensure that the team can can easily explain what you have built to someone else who joins the team.
and finally… Remember to iterate fast & deliver value incrementally!
With the above in place, you will also be able to confidently make your skills transferable in any organization.
Hope these pointers help you in choosing the right technology stack for your early stage startup!