4 reasons your devs should choose their programming languages


What if I told you there was a way to make your dev team focus more, solve problems faster, multitask better and work together more cohesively? You’re already on board, aren’t you? While I don’t have a magical remedy for a more productive, knowledgeable software development team, I do have a suggestion: Start speaking (AKA coding) each other’s languages. 

The positive attributes listed above are just a few of the proven benefits of being multilingual when it comes to spoken languages, but I’d argue they apply to programming languages as well. At Pluralsight, we’ve built a talented team of developers as we’ve grown and acquired other companies. And in the process we’ve become multilingual—our developers are fluent in close to a dozen languages including C#, Python, PHP, Ruby, SQL and upwards of ten other programming languages. We are true polyglots. 

All this language experience is a significant advantage for companies because it spawns new ideas and helps tech teams see challenges from a variety of perspectives. A polyglot dev team adds a good mixture of skills that strengthens not only the team, but the entire org. Additionally, your team members are less likely to become stagnant or bored and more able to continue (and want) to learn new technologies. All things you need on your dev team. So, how multilingual are your developers and why should you let them choose their own languages (within reason)?

1. Increase productivity. Be more strategic.

Some tasks or projects are better suited for one language over another. And who better to know which is best than the people who know the languages? Let me illustrate this with an example: If you have a C++ object graph, with one object pointing to a second object and both have two attached fields (one is a four-byte integer and the other is a four-byte pointer) and you want to send that over the wire as part of a distributed object file, the solution requires writing the data to disk. C++ doesn’t have any built-in reflection support, so it can’t tell the difference between the two four-byte fields. But, .NET and Java both have libraries to deal with this problem. In fact, in both of those languages, this issue is easily solved. But C++ doesn’t have the ability to do it. And guess what? Your programmers probably know this if they’re polyglots. 

If your team only has experience in one language, requirements like this can be problematic. But polyglot programmers have the ability to think about challenges from more than one perspective and are more likely to find simple, elegant solutions for those challenges. And this leads directly to the second reason your developers should know and work in more than one programming language…

2. Create ownership. Contribute to job satisfaction. 

Devs are a creative, exploratory bunch. Typically, they welcome challenges and love finding solutions to problems. So when technical employees are allowed to diagnose problems and recommend (or even choose) the solutions, they buy-in more readily and are more engaged in their work. They know they are trusted to make decisions with real business consequences. And in an environment where recruiting and retaining talent is so important, creating a workplace where people are excited to contribute is critical.

3. Drive innovation. Foster a culture of learning. 

When your dev team is staffed by people with expertise in several different programming languages, it’s only natural that they learn from and mentor one another. Add that to regular opportunities to train and develop professionally (which you should be providing), and you’ve managed to create an environment that encourages innovation, improves team unity AND benefits the business. At Pluralsight, we encourage teams to share ideas and learnings with each other. The result is developers with broader, more knowledge skillsets and a team that works closer together to achieve goals.

4. Hire new talent, easier.

When you’re not limited to potential employees with the narrow skillsets needed to support a single technology stack, you have more leeway to bring in new programmers with a wider range of skills and experience. It allows you to look beyond particular language requirements and hire for more important things like attitude, willingness to learn, ability to solve problem, etc. (Here are some examples of questions you can ask those potential hires.) Of course, you need qualified technical employees who can support existing technologies, but as you grow, you have the opportunity to introduce new languages and platforms (as well as differently experienced programmers) to your organization—and that’s a huge advantage. 

But wait, there can be drawbacks to a polyglot dev team

Before you embrace or start to build a polyglot software team, you need to understand the potential risks.

Polyglot teams can make it harder to manage production. 

As your team builds products in differing languages, the availability of the specialists with the right skills can impact schedules and release dates. Especially on small teams, you’re at risk of becoming dependent on the one or two employees with the expertise needed to support your products.

Mobility from one team to another can be difficult.

It can also be more difficult for employees to move between teams, as they need to learn new languages and skills to work effectively with a second (or third) tech stack. The wide availability of inexpensive training solutions can help ease this issue, but employees still need to put in the time and effort to acquire the skills to move from one team to another.

Deciding which new technologies are (actually) worth it can be tough. 

Last, developers have a natural desire to try new things—even on critical projects. Managers may need to pull them back and make sure there are sound business reasons for each programming decision. If you don’t, you may implement a technology that your programmers think is going to be great, but it turns out “meh.” The developers move on to the next thing and you’re stuck with a “meh” product that you need to depreciate. If you’ve got customers using that technology, it becomes problematic to depreciate it or migrate it to a better solution. You’ve got to be careful not to implement new technologies just for the sake of new technology.

So when I say, “Let your devs choose their language of choice,” I mean, “Let them choose their language of choice within reason.” There’s got to be solid strategic, financial and business reasons behind the technology of choice. And at Pluralsight, we use tools and processes to help ensure those reasons are valid. 

Overall, managing a team of developers with a wide variety of technology skills is a big plus for us. It helps us introduce the right technologies for our long-term success and creates a unique, healthy culture of innovation and autonomy. And it might be a good move for you too—as long as it supports your overall business goals. Ready for all the benefits of a multilingual dev team? 

Keep talent on your team: 5 proven ways to motivate and retain your technology team 



Jody Bailey

Jody Bailey is the CTO of Pluralsight and believes the best part of his job is creating a culture of continuous improvement. He leads the development, data science and system operations teams, as well as the IT/help desk. Jody loves contributing to Pluralsight’s mission of democratizing professional technology learning, while growing talented teams. When he’s not at Pluralsight, you’ll find him training for ultra-endurance mountain bike races, cooking, snowboarding and spending time with his family. 

You can follow him on Twitter at: @ajodybailey.