So this morning I was listening to one of the Linux related podcasts, Coder Radio and the hosts read feedback from a listener who claimed that he was “bored” with PHP and ready to try something else. Now to be fair, in this particular case, the writer outlined some circumstances that made me sympathize with him. Long story short is that parts of the PHP based stack he was relying on for some of his software had changed significantly. In order to update his software to a currently supported version of PHP, he basically now has to rewrite it from scratch. So yeah, that sucks.
I’ve been there before however and I freaking hated it. At my previous job I spent the previous four years painstakingly building out an awesome .NET and Vue 2.x based web application stack that I really liked. While the .NET parts of that stack are still very much relevant, the Vue 2.x code is deprecated and updating it basically requires a from scratch rewrite as Vue 3.x (unless you enable the compatibility layer kludge) drastically changes the way Vue works and how you interact with it.
At this moment, I haven’t bothered to go down that road. Mostly because I have no current use for an up to date version of that stack as it was mostly geared towards facilitating the completion of paid work. As my more consistent readers already know, at my current job, a large portion of my web facing work is done using a low coding tool called OutSystems (which I despise). The rest of my work is back end work and thus is written entirely in C#. This of course means that I current have no motivation to spend my time rewriting this stack.
So in this particular case, I identify with that viewer and his feedback. As developers, we all know that this is a shitty situation to find yourself in. But why do we find ourselves in this position so often? Also why are we getting bored with our tools? Also, why is being bored with your tool even a problem?
Well for starters, sometimes this happens because developers responsible for parts of our chosen tech stack decide themselves that they are bored and that everything they do needs to reworked from scratch. This is typically done to facilitate a massive change to the preferred operational abstraction that the developer or team of developers behind the tool are working with.
This happens a lot. Disturbingly so. It happened with AngularJS 1.x when Angular 2.x was released. It was essentially incompatible with work done in AngularJS 1.x. Now to be fair, while they did somewhat change the name, only developers themselves make a distinction between the two. To the rest of the world, they are treated as if they are one and the same, despite the fact that my experience with AngularJS 1.x in no way translates to any sort of proficiency with Angular 2.x and its successive releases. It has now happened to Vue as well. Vue 2.x and 3.x share a name and the while latter provides a compatibility layer to help people transition, it really doesn’t matter. My skills with Vue 2.x are in no way directly transferable to Vue 3.x.
Frankly, this situation pisses me off. Mostly because when these developers decide to change everything and rewrite their portion of my tech stack from scratch, it basically forces me to waste a ton of time, which could’ve been spent solving actual user problems, trying to adapt, rework or rewrite my code that depends upon their code. Nobody wins here.
So why did this happen? Well sometimes rewrites like this solve real problems. Sometimes these things can’t be avoided. Sometimes old and broken and insecure code just needs to be flushed down the proverbial toilet. I can’t speak for any portions of the PHP stack that the Coder Radio viewer referred to as I have no real PHP knowledge. However on the Vue side, I can absolutely say that without a doubt, Vue 3.x changes nothing that benefits me in any way possible. In fact when it comes to Vue 2.x, I personally feel that it was a top tier way to develop single page web applications. I really liked it because to me it was AngularJS 1.x with a lot of the annoyances resolved. Moving away from it is not my choice.
My theory on why this happened is that the Vue developers got bored. Vue 2.x was established, working well and maintaining it had become a mundane chore that was bereft of the excitement that comes with writing fresh new code around shiny new abstractions. So because of that Vue 3.x was inevitably birthed into existence and thousands upon thousands of functional and perfectly fine Vue 2.x applications became deprecated overnight. Let’s be clear, Vue 3.x is not all bad. However the reality here is that the advertised benefits are absolutely meaningless to me and my now ex-employer who relies upon that deprecated Vue 2.x component. Here are the big advertised wins of Vue 3.x:
- Vue 3 Performance
- Tree-shaking support
- The Composition API
- Teleport
- Fragments
- Improved TypeScript support
- Other breaking changes
In truth, none of that stuff in the list above matters to me beyond performance improvements. None of it matters to my ex-employer either as everything was running perfectly fine. If I was still working there, I would already be lobbying heavily for the time required to make the transition from Vue 2.x to Vue 3.x and it would be an exceptionally hard sell. That’s because as soon as you take the argument for the upgrade outside of the Developer Echo Chamber, it falls flat on its face. The best possible case one could make is that soon Vue 2.x will no longer be supported with security updates or be extended to take advantage of relevant new browser features. But even that’s a hard sell as it doesn’t create a path for you to argue for any tangible up front benefits.
Let me go even further here: I like it when my developer tools are boring. If they are boring, it means they are consistent and reliable. It means that they aren’t creating undue drama in my life or the lives of my end users. As an industry, we should all be striving towards building things that ultimately end up being boring. But of course that engineer like inclination flies in the face of all the scam-adjacent tech bro behavior that makes up the public face of our industry. You can’t spend all of your time hyping up investors and rich assholes so they’ll give you stacks of cash by telling them that you are going to be building boring and reliable tools based on boring and reliable technologies that already exist. Not unless you are building something that is actually innovative. Which most of us aren’t.
So of course that’s why everybody is talking themselves blue in the face about nonsense techs like Artificial Intelligence and Blockchains. Because new is what reels in big fish so that they’ll fund whatever dumbass idea the founder has hidden behind a shiny layer of en vogue tech buzzwords. Developers get sucked into this thinking because all of the tech personalities spend a huge chunk of their time talking up all of this stuff which creates all of the conditions required for FOMO (Fear Of Missing Out) to percolate through our professional ranks.
My sense of accomplishment is primarily derived from writing tools that I know will work and will to at least some reasonable degree stand the test of time. That’s a much harder and also much more boring measuring stick to judge myself against, but its the one I use. Much like a civil engineer, I’m not here to build the flashiest bridge that will draw the hordes of tourists in, instead I to strive to build one that is stable, reliable and will stand the test of time while allowing those who wish to cross to do so sans undue drama.
Frankly, our industry needs to grow up. We have to stop embracing change for the sake of change. We have to stop predicating our professional sense of accomplishment on how high our work scores on today’s Tech Buzzword Bingo card. The longer we go on pretending that buzzword bingo is the way to go, the less respect we will be afforded as an industry.