Fast Food Software Engineering Progression

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.

This, of course, is not to say there aren’t valid reasons to leverage new languages, or frameworks in the workplace, but this needs to be done sustainably, and with true benefit to the company, such as performance, or access to some ecosystem (harder to do data science in say, Node.JS than it is in Python) Sometimes, the business reason may be motivated by recruitment itself, as frameworks and languages form part of the companies recruitment pitch. 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 30 second pitch? I don’t think so. Communicating progression externally when recruiting is hard, and companies may be better off communicating technologies and frameworks they use because it’s easily expressible in a job specification. It’s significantly less informative to say, ‘You’ll develop a deep foundational understanding of Distributed Systems’; the sentence spins up three times as many questions as it answers, for instance ‘what does my day to day actually look like’.

Given the constraints of a few bullet points, I don’t really take umbrage with SWE shops broadcasting the technologies they use over more foundational forms of progression. 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

In short, I guess I’ve grown wary of these suggestions of new frameworks or new languages as a form of progression because they ultimately seem more about solving hygiene factors than they are about providing a source of meaningful progression for an engineers career. At the same time, a company is limited in what it can easily express when recruiting, so as an engineer, you need to be able to read around a job spec. For sustainable progression, both engineers and departments should find what motivates each engineer on an individual level, or what challenges they want to solve in the next 1, 5, 10 years, and construct something around that through co-operative conversation.