As a professional developer, you probably have experience in a few different languages. You will know from your experience that programming languages have strengths and weaknesses. No single language is the ideal solution for all types of problems. A time will come in your career where you see an opportunity to introduce a new programming language that isn’t already in use within your team.

Here are some of the issues you may come across:

  • The “trendiness” factor
  • Dealing with team leads and managers
  • Demonstrating business value and/or cost savings
  • Operations
  • Hiring new team members

In this series of articles, I will give you strategies and ideas to be able to overcome each one of these issues. This article is Part 1 of the series.

The “trendiness” factor

Things move fast in the technology sector, and new programming languages are continually being invented. An interesting dynamic seems to occur within the developer community when new technology surfaces. Some developers are excited because it nails something that is important to them. Some may not see an immediate benefit, and respond with caution. Then there are usually a percentage of the community that could be classed as “haters”, or are at least quite skeptical of the touted benefits.

You are probably in the excited camp, or you have moved up from the cautious camp because you can see a use for this technology within your team. Your job is to get the developers on your team to move closer to the excited camp. Developers are usually logical beings with a dose of healthy scepticism. This means that a successful approach will be logical with a focus on proving out the technology with examples.

How to solve for it

Probably the most effective way that I have seen is to code up a simple prototype that replicates one piece of functionality from your current codebase. You can then setup a meeting with your team where you give everyone a walkthrough of the code. Talk about the new language and its benefits in a real life situation. Encourage questions and discussion.

If your project involves microservices, then you may be able to code up a replacement to one of the services. If you’re team is working on an MVC web application, I would suggest coding up a full stack prototype with the new language, but only reproducing one simple feature from the existing codebase. When picking a feature from a large application, don’t replicate things like user authentication. Pick something that is core to the value that your application delivers to users.

Take note of each team member’s objections and questions. Book in a follow up meeting to address any queries you can’t answer on the spot. Ask other people in the team to answer some of the questions. If a developer asks “Does it scale?” and you have another team member who is strong on scalability, ask that team member what they think. This promotes discussion and helps all the team members feel a part of the process.

Think about how you can introduce the new programming language in a small way to start with. This lowers the risk of something going wrong and helps team members learn the technology in an environment that is less stressful. When developers are stressed, they don’t think clearly, and could resent new technology. In a low stress environment, their response would usually come with a problem solving approach, which is ideal in most situations.

Finally, come up with a plan. If everything goes well with the team, it doesn’t stop there. Involve your team in the planning process and outline the next steps. Ask your team the question: “what would we need to do to get this to production?”. Recruit your team to help tackle the next set of issues to overcome.

Part 2 of this series coming soon!