If you were to ask what "the best programming language" is, you'll invariably get responses along the lines of "using the right tool for the job".
However, the notion of "the right tool for the job" is not so straightforward an idea, can we unpack this a bit?
Latest comments (23)
It mean learn how use the wheel for right move
I don't think "right tool for the team" should be intertwined with "right tool for the job". I would have an ordered list of tools for a given job, and then do a second pass to match the team's existing skills against that ordered list, rather than trying to juggle too many concerns at one time.
depending on the context, use the thing you know well enough to be productive at getting a given job or task done.
There could be better tools or languages, but if you don't know it, you need to decide if it's better to learn the better tool or make due with what you know. Constraints could dictate it either way depending on what they are.
That's just on an individual level though, but you scale it up to where the team has to make those considerations and determine what's best by the same factors.
As a software developer you're an expense to your employer. Implying the more productive you are the more valuable you are to your employer. The more valuable you are the more safe you are, and the more likely it is that you'll be promoted. Find the tool that makes you the most productive, without compromising code quality or security in any ways ...
The right tool for the job is the tool right in front of you that you know how to use! It may not be fancy! It may not be new! But it's there...for you to use it!
The best tool is the one you know that may complete the job. It doesn't matter if tech X or tech Y will make the app go faster, or make it look cleaner if you hate it or don't know it. Take a list of the things you know or things that you can easy learn and pick the best one from them that can finish the job. It's like photography - yes, a 5k dollars camera might be the best one to catch a sunset, but if the sunset is now and the camera is at home, I am 99% sure the phone will do ok.
This is an abstraction developers like to use to communicate complex ideas to people that require simpler terms - like management.
Ok joke aside, job often refers to a usecase, scenario or project and depending on that the tool might mean a library, Framework or whole tech stack.
If we break this down we come to the foundation of the domain with specific processes and users with functional and non functional requirements and a technological choice to realize these requirements in the context of the domain.
Phew.... I sound weird, let's stick to the tool and job definition
It means time spent/wasted on research. There will always be a set of most common usage scenarios for a particular feature of a language/framework/API and a collection of accompanying tools for that set. And then there's niche. And then you'll catch yourself wanting to use a particular tool that is not in the MVP set of tools, you'll assume from its docs that it will produce certain results you desire only to find out through practice it's not producing the outcome you expected.
I think its quite hard to get a general consensus about "right tool for the right job" as there's a lot of factors to chime in. Ofcourse the first one is the programming language fit? for example "can we have a high IO in PHP that is fast and efficient?".
We also need to consider our talent pool at our arsenal.
For example we need to write a chatbot, we have a majority of JS/TS savvy developers at our team. Can we justify using Elixir(Phoenix) to them? Elixir is much more performant than NodeJS no doubt but most likely we will choose NodeJS to do the job.
Another thing to consider is, future proofing too. inherting the example above, do our userbase will grew really large? Will we hit the point where Elixir will let us save lots of server money?
Things like that are hard to forsee. My stance is to find balance between the best out there versus the best we can do right now.
Languages
The right tool has more to do with ecosystem tools (ex: solid data science libs), runtime constraints (ex: low resources, device driver, embedded), etc. When your constraints are lighter, its more a matter of the what your team already knows and preference.
System components
This is probably the most obvious place for "right tool for the job". After helping team mates write multiple queries, I realized that a graph database is a good option for: "does this user have access to this resource". When there is a dynamic path between the user and resource.
And there are plenty of components with multiple options to choose from. Ex: stateless vs stateful auth. Data shipping vs function shipping. Sharding or replication (or which for what pieces).