I'm going to preface this with a big old disclaimer; I haven't worked in industry for that long, no more than a few years. However, as I'm sure the more senior engineers reading this may remember, you do start to build an idea for the things that keep you at a company in the longer term, as I have, and for many engineers, progression is at the top of that list. One form of progression I've seen in the wild, that I've come to grow wary of, is being being offered work with a certain framework or programming language. There's nothing innately wrong with it, but I'm starting to question whether it's really nourishing in the longer term.

A department may be working out how to provide opportunities for progression for their existing engineering staff (indeed all their staff, but I definitely can't speak to that). The challenge is to do this in some scalable, repeatable manner. There are some extremely low hanging fruit, that may even be presented _by _ the rank and file developers as something they'd like to do or learn and one of the suggestions I hear the most is around learning new languages or frameworks as a form of progression.

Moving to a new language departmentally or as a team can seem like a motivator in the longer term (engineering will be more into what they're doing if they're using a language they're enthusiastic about), but you have to ask whether that progression will last. Once the staff have gotten to some level of competency, they're still expecting to progress and develop, and you can hardly switch to another new framework or language to scratch that itch. Learning a new language buys time, but that's about it - it ultimately doesn't satiate the desire for progression in the long term, just as fast food doesn't really satiate the appetite in the long term.

Complaints about the current languages in use at a company, or suggestions for wholly new languages should be considered as potentially hygiene problems surfacing themselves. Even then, the tooling available in many languages means that, say for example, static typing can be introduced into JavaScript with TypeScript. Is it 100% the same? Absolutely not, but at the same time, you've mostly achieved the boost in quality of life with the static typing, without the inertia of say, switching to Golang.

There are of course, good reasons to introduce new languages and frameworks into the work setting. Access to a community is one such reason; the Node.JS data science community is significantly less developed than the Python data science community for example. Golang has become the lingua franca of modern operations tooling development, to some extent. Sometimes there are legitimately strong technical reasons to introduce new tooling/frameworks/languages, such as needing to solve a particular problem, but not wanting to construct some bespoke rube goldberg machine in the process; its the difference between a pet project scheduling monstrosity and using something more off the shelf, such as ECS or Kubernetes. It may even be prudent to move towards new technologies to make recruitment easier - languages and frameworks listed on job advertisements are as much requirements as they are the cornerstones of the thirty second pitch an employer can make to prospective candidates. For instance, it's probably a little tricky to hire people for frontend roles using jQuery predominantly now, whereas a React or Vue position is likely relatively more easy to fill.

Is it wrong that languages and frameworks form such as core part of a companies thiry second pitch? I don't think so. Communicating progression externally when recruiting is hard, and the listing of technologies and frameworks has some duality associated with it in that they are both bullet points that interest candidates, but also a communication of what is expected/required from a candidate in the job. It's significantly less informative to say, ‘distributed systems knowledge', or something, as it's ultimately pretty vague and creates as many questions as it answers. To engineers on the lookout, I would advise using the bullet point list of technologies as a suggestion to the types of problems they're solving, the size of the department, the resources available - read it like tea leaves.

Calling It

It's pretty simple in the end. If you're introducing a new framework or language, have a really good idea of the problem you're solving by introducing it, and if there are more evolutionary alternatives that fit within your existing stack.