A Follow-On to “Aging in the Tech Industry”
https://medium.com/s/story/aging-in-the-tech-industry-6a0e116bdf09
I agree with many of the sentiments expressed in the referenced article, particularly the sense of helplessness as you watch younger colleagues go down the same wood-paths that lead to the same dead-ends you’ve been down far too many times in the past. I’d like to add a little from my own experience.
Those of us who are in our fifties and older in the tech industry are often seen as blockers to younger disruptors — and who won’t admit software is disruptive by nature? Yet too much disruption, particularly in the core toolset, only leads to development velocities approaching zero.
Twenty years ago I was involved in the Java and Smalltalk portions of a large DoD project, and we completed that project early with no devops (I’d never even heard the term at the time). With the advent of the cloud, however, the myth that one just creates a VM with a click in a webapp and deploys your code, is just that — a myth. The reality is that the public nature of the space in which the VM is created requires a fairly large set of arcane tools to gain any reasonable access to the code running on it, and developers debugging using nothing more than application logs is as much the norm in cloud development as it is time-wasting and annoying.
While developers can do devops work, they’re largely slow and inefficient at it, and devoted devops engineers are a necessity, not a luxury. Smalltalk remains one of the few environments where code can be deployed locally, tested, and then “thrown over the fence” to operations without arcane tools such as Kubernetes being involved. But Smalltalk is seen as out of date, despite current versions being far more advanced in the sense of being productive development environments than any of their younger cousins.
This is the case even though the majority of cloud deployments I have seen are quite simply mainframe-style batch processing systems that work in a parallel fashion, something about as new as MVS on the mainframe. (For those too young to have worked with mainframes, MVS was released in 1974).
Earlier in my career I often heard the phrase “you know so much”, and while I still hear it, it’s rarely a compliment these days. More often it has an exasperated tone, implying that the next (unsaid) sentence “so why can’t you fix all our problems today?”.
A particular difficulty for me is that while I am in my fifties and am often expected to have moved into software maintenance if not management, my strengths have always been in areas where nobody, myself included, knows how to accomplish something. Gaining the trust to do something completely novel when I’m not young is problematic, though. Gaining the trust to do it using a mix of old and new technologies (the choice being based on whether they fundamentally work or not) is even more problematic.
Banks are another option if Government isn’t around locally, but even there younger managers are so keen to be seen as up on the latest trends that any warnings about the difficulty of implementing a complex system with, for example, JavaScript based microservices, is seen as being somehow against newer technology, even when the alternative proffered remains a microservices architecture in Java that offers 10x the performance of JavaScript microservices, better monitorability for deployed services, and a more streamlined development and devops experience.
While frustrating, the attitude can occasionally turn around when you’re proven by results to have been correct in the first place. The difficulty is getting there when initially the idea is a hard sell and even once agreed on is treated with suspicion by younger colleagues until it begins to prove itself. Even then, however, there’s always a danger that younger colleagues, angered at being proven wrong, will do their utmost to sabotage the project.
