What considerations go into the right language for the job
When I was very young, I would spend school breaks with my grandparents in London. My granddad was quite the handyman. On one of these occasions, he asked me to help hand him tools as he was fixing some plumbing issue. Right off the bat I ran into problems as soon as he asked for a spanner. I looked at the big box of tools in front of me, looked back at my granddad, and gave him a hammer.
I was a Brooklyn kid going to American schools. That day I learned that a spanner in the UK is called a wrench in the US. My granddad made it a point to explain that the Americans had the language all wrong.
Now could my granddad have used a hammer. Probably, but it would have made a mess of the pipes. I still remember that look my granddad gave me when I insisted that he use the hammer. It was the look of “my dear poor daft grandson.”
There is a well known cognitive bias known as the Law of the Instrument*. The person most closely associated with this idea is Abraham Maslow, who wrote in 1966:
“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”
What is interesting is that while Abraham offers up the quote closest to what we attributed as the modern saying “Give a child a hammer and everything looks like a nail”, this saying actually appeared in the book titled “Computer Simulation of Personality: Frontier of Psychological Theory”:
“This was the tendency of jobs to be adapted to tools, rather than adapting tools to jobs. If one has a hammer one tends to look for nails, and if one has a computer with a storage capacity, but no feelings, one is more likely to concern oneself with remembering and with problem solving than with loving and hating.”
As developers, we know a thing or two about the proverbial hammer. In this case, choosing a particular technology or language that we feel is right for the job. Dig into what “right for the job” means however and we often uncover that it’s the language the developer knows best.
“Why do I really dislike Java? Because I am not very good at it. Very few languages are fundamentally good or bad.”
Every year there are most loved and most hated language posts that circulate. Generated from surveys by Stack Overflow, RedMonk, TIOBE, and others, we can get a pretty clear picture of what developers think are the best languages.
Likes and dislikes aside, there are some important considerations to which language makes the most sense for a product:
- Platform — How is the product going to be deployed and what infrastructure is required to support the performance needed based on the deployment options?
- Dependencies — Do other systems in the environment necessitate a specific language such as internally supported frameworks or architectures?
- Application — What are you using the language to accomplish? Is it for analytics, machine learning, backend integration, or something else?
- Familiarity — What languages are the developers on the team most skilled at and can be most productive with in a short amount of time?
- Resources — How robust is the market for additional resources? Where are the best places to find talent with the specific language skill?
- Ecosystem — What is the extent of community support around the language? How easy would it be to get help on questions or bugs?
- Longevity — Does the language have enough support and momentum to be around for the next decade and longer?
- Business — Are there factors from a time, money or skills perspective that are influencing or impacting the decision of a particular language?
One note regarding ecosystem around a language. If you have a fairly experienced team working on an independent codebase, ecosystem may not be as critical. They can often figure things out or find the people to help. On a more junior team or where the code is part of a bigger system, then it is better to rely on a more common language where resources and help are more readily available.
However once the above questions are discussed, it should be the team itself that decides on the language to use. While the context is slightly different, Chandler Carruth shared an interesting take on the use for programming languages:
While his angle was about the usability of languages, the key point is to listen and accept the views of developers. They are the ones that will be in the thick of creation mode. They will have reasons, whether entirely valid or not, for their preference on tools. Just as you wouldn’t give a plumber a hammer when they needed a wrench, it makes no sense to put obstacles in the way of developers that would prevent them from being their most productive.
When you give developers the freedom to choose their tools however, you get two key benefits. One, they are more productive sooner, which means code out in production faster. Two, you have a much more engaged and motivated team that feels valued for their work, saving the team from bad morale and attrition.
How do you decide on which programming tools to use in your organization? How much freedom do developers have in deciding the language they want to use?
* This saying has also been ascribed to Mark Twain but there is no factual evidence to date suggesting he ever said any form of this phrase.
Episode #4 — Measuring developer productivity with Reuben Athaide
Revisiting past episodes before starting on our next podcast episodes, this time we invited Reuben Athaide of Standard Chartered to discuss measuring developer productivity.