I worked on the system which is now the customer admin for Square’s ecommerce platform they bought in Weebly.
We were all learning Vuex, while also trying to ship code. Across a half dozen pages we had a half dozen slightly different ways of addressing Vuex data. It wasn’t so much complexity that a professional coder couldn’t keep it straight in their head. But it was a trivial amount of complexity to fix. Two days work, maybe a week. Mostly variable naming.
But we chose to ship that feature because we wanted to prove to the company we could deliver. Now those coders will live with that choice for a log* time. New pages will use another slightly ad hoc scheme.
Eventually some architect will decide something like “Vuex is too conventional, we’ve got too much glue code, should we try switching to Redux or Vuedux?”
And the correct answer for the devs is: yes, it’s good for your resumes.
And (speculation) the engineering management will probably never swallow “we have to do three weeks of variable renaming and function moving to fix this now”. If they couldn’t swallow two days of cleanup in exchange for meeting an arbitrary internal target, they won’t swallow three weeks which probably pushes back a user-visible release.
* I meant to type long, but log time, pun intended
That sounds like no one actually designed or architect-ed the system, and everyone just went off and built things without an overarching plan. This is sadly somewhat common in software projects. This could be due to a variety of factors but to chalk every software project up to "resume padding" seems like a simplistic take.
Using your example but applied to other companies, I've seen the below, or some combination of all:
* Unskilled devs that have never used any of the new technologies and spent little time prepping beforehand.
* Management who demanded unrealistic deadlines or demanded devs skip design phase in favor of shipping faster.
* Lack of technical leadership, senior engineers are hard to come by at many large orgs and are often overworked or too busy to be everywhere at once.
* Cut throat career minded individuals that always jump ship to the next new thing.
In your case, it seems insane that you would be writing software with multiple teams or even multiple developers without some overarching plan. It shows a clear lack of technical leadership on the part of management and senior engineers.
I don't even think "jumping on the next new thing" is a particularly valid "career strategy". Many companies do use relatively "old" technologies and don't care as long as the job gets done. Slack even uses PHP. Not to mention the big companies which might pay more attention to algorithm problems instead of the particular language you solve those problems in. Do the recruiters really think you are the one if your resume has all the newest hottest things written all over it?
Personally I learn new technologies if they are fun to learn and make my life as a dev easier. That's it. I'm not sure if anybody jumps on wagons just for the sake of it. For example I tried out Rust, Julia and Elixir, hated the first but liked the later two. I also tried Vue a bit but with Phoenix framework a lot of things can just be done with server-side rendering so I just dropped Vue in the project and felt totally fine with it.
I worked on the system which is now the customer admin for Square’s ecommerce platform they bought in Weebly.
We were all learning Vuex, while also trying to ship code. Across a half dozen pages we had a half dozen slightly different ways of addressing Vuex data. It wasn’t so much complexity that a professional coder couldn’t keep it straight in their head. But it was a trivial amount of complexity to fix. Two days work, maybe a week. Mostly variable naming.
But we chose to ship that feature because we wanted to prove to the company we could deliver. Now those coders will live with that choice for a log* time. New pages will use another slightly ad hoc scheme.
Eventually some architect will decide something like “Vuex is too conventional, we’ve got too much glue code, should we try switching to Redux or Vuedux?”
And the correct answer for the devs is: yes, it’s good for your resumes.
And (speculation) the engineering management will probably never swallow “we have to do three weeks of variable renaming and function moving to fix this now”. If they couldn’t swallow two days of cleanup in exchange for meeting an arbitrary internal target, they won’t swallow three weeks which probably pushes back a user-visible release.
* I meant to type long, but log time, pun intended