How to pick a new programming language for a startup of 5–10 engineers
An interesting conversation was brought up amongst our engineering team on picking a new programming language for a project that will be used to build a highly scalable and transparent payments network. This naturally leads to an interesting debate over lunch on some of the considerations that we will face, which I’ll attempt to share over here.
Before that, what are some of the constraints that a startup faces?
- Hiring; The company’s brand isn’t well known enough to draw enough talents. There’s also inadequate funding and time.
- Existing manpower are often inadequate to deliver enough products on time.
- Communication starts to break down as the team scales to more than 5 engineers. (Engineering policies, code review, bug fixes and triaging)
- The need to rapidly prototype and to identify new business opportunities.
- Cater to new business opportunities and scale rapidly without being impeded.
Based on the above, any new technologies that we pick needs to consider the above constraints.
On Hiring
Based on my experience trying to hire in Singapore, Indonesia, Vietnam, Philipines, and Taiwan, I realize that it is not easy to hire candidates based on programming language as a constraint. I would use to have calls with recruiters and telling them that I want candidates with Ruby on Rails, MySQL and ReactJS experience and the end results will often lead to them calling me back and asking if I can drop some of the requirements. If that’s not the case, it will probably yield them an approximately 1–2 candidates found per month of searching at best.
Needless to say, I’ve dropped those requirements now. We now look for people who are able to pass our basic coding tests, hardworking and with a passion for learning new technologies quickly.
We work instead to have more training and sharing session on ruby on rails monthly to bring people up to speed.
Thankfully the ruby on rails community is large enough, and everything that you need to know can be found in 1 single place. This helps with onboarding as candidates are able to learn the language fairly quickly.
Side note: We don’t really test candidates for hardcore algorithms implementation these days. Mostly due to the above constraints and due to the kind of business challenges in SEA doesn’t require a startup to look into building deep technologies*
Existing manpower are maxed out
By bringing in a new programming language, engineers will now have to spend additional time dealing with the nuances of 2 different languages and spending time mentoring one another on the nuances
Communication
Code reviews probably take up 5-10% of our engineering effort. By bringing in a new language, it will reduce the effectiveness of code reviews, or it might create a split between the engineering teams into 2 camps, which will affect the flexibility of team planning and organization.
The need to rapidly prototype and to scale
The number 1 rule for prototyping is speed. Speed of implementation and the ability to fail fast. A new programming language should allow for that as much as possible. E.g. Objected oriented languages are easier to pick up and to use effectively over a procedural/functional one (my opinion!) I mean how many people will study lisps as their first language over Java for example?
In addition, most programming languages are able to scale pretty well. Even Php! Besides, most scaling bottlenecks are often due to other factors unrelated to programming languages such as tasks that can be handled with a backend batch job, a database level optimization or doing a scaling on the infrastructure level. It’s also much easier to hire 1 person to handle the scaling of our backend over hiring a team of people to learn a new language.
The above are the non-technical aspects that we need to consider. What about the technical aspects?
Programming languages are built to cater to different technical domains that they are meant to solve for. Most of the time the language itself isn’t the bottleneck to a business problem that a startup is trying to solve for.
For instance, a common concern that a startup founder will face: Is this programming language X going to help me to scale?
Naturally, this isn’t very helpful in our decision-making process. A better way would be to dig deeper and challenge every subconscious assumption that one may have.
Perhaps it will be a better question to ask, what are the bottlenecks that I may face? Too many requests per second? Too many long streaming requests per second? Perhaps there’s a large amount of CPU logic processing per request that is required? Or perhaps there’s too much database calls and the database cannot handle all the read/writes, or the application logic locks certain tables or some kind of race condition which probably suggest that we should look at the application architecture instead.
P.S. We are still looking for people to join us in building a highly scalable and transparent payments network.
*Look at Grab, it won Uber in this region with an app that doesn’t allow the user to order food while you are on a ride with Grab. Does technology really matter? Worth a discourse in another article :)
