Developers have made no secret of the fact that they love learning new technologies. Based on what we learned from the 2017 Developer Hiring Landscape, there’s no shortage of programming languages for them to tinker with. In addition to some of the more popular technologies, developers named technologies like Go (17%) and Typescript (16%) to the top of their wish list this year. As tempting as it might be to add new programming languages to your tech stack as a recruitment tactic, engineering managers are always thinking of which technologies make the most sense for their teams. We were curious to hear more about how they evaluate and add new languages to their tech stacks. Here’s what they had to say.
Ross Smith, Chief Architect at PITSS America, says that it’s a better idea to identify the developer who’s championing a particular interest and asking that person champion a specific project with that programming language. Not only does Smith say this is an effective way to evaluate a particular technology’s fit for your company, but it also lowers the risk perception for everyone else on the engineering team.
Smith also walked us through his approach for experimenting with a new technology. He says, “This internal champion should be responsible for preliminary research into tech alternatives in the market, and then team up with one or two engineers at the company. They should then run a short, well-defined, results-oriented research project to test the technological solution for its potential.”
Fortunately for development teams, there’s plenty of documentation for the programming languages they’re considering adding to their technology stacks. But unfortunately for development teams, there’s no shortcut to reading through all of it.
Will Shulman, CEO at mLab, tells us that it’s crucial to have at least one person who can efficiently read the documentation for new languages and evaluate which problems it could solve. If your company doesn’t have someone who’s comfortable doing this work, Shulman warns against adopting new technologies in their infancy. He adds, “When NoSQL databases were still new, we saw a lot of organizations aggressively starting to use these databases without really understanding the differences between each technology and when to use them. Many got burned by this, and it happens at all levels of the stack.”
We’re at a point in history where there are seemingly endless technology options for engineering managers to evaluate. But even programming languages that seem necessary on paper might not drive business initiatives forward—and that’s ultimately one of the most important factors for your leadership team to consider whenever you’re considering adding something to your technology stack.
Ewan Dennis, an Engineering Manager at SparkPost, admits that it’s difficult to resist the urge to experiment with or implement a new technology that’s compelling. However, he also advises that the company’s broader business objectives should guide the decision-making process. He adds, “Adding tech to your arsenal must be driven by a change in the host business: either an existing tech needs replaced to support changing requirements or a new need arises. We must also produce clear metrics to identify a successful outcome. Only with the need and outcome both objectively identified and measured can we build production-ready technology stacks to support our businesses.”