I think you're talking about a few different concerns and not all should be ignored. Resume driven development is something that should be avoided, but there ar

I think you're talking about a few different concerns and not all should be ignored. Resume driven development is something that should be avoided, but there are good reasons to update your tech stack even if the old one is working fine. To your point, I've been to tech workshops for new tech where everyone was laughing about their current jobs' quagmire from previous new tech. All I could think about is not wanting to use either in production for what they were doing. However, I was also at a job pulling teeth trying to convert from SVN to git. A lot of people argued changing was fashionable, but branching and merging were frustrating (therefore not heavily used), tools we wanted to integrate with less often supported SVN, and a lot of the automated processes in place would have been much more lightweight after transitioning. While I don't think appealing to new hires should drive your tech stack, telling them we still used SVN was something you kind of said under your breath with a bit of shame. As for "nobody wanted to work on someone else's codebase" is true, but I think needs some give and take. If you're making someone responsible for something you need to give them some latitude for running it their own way. I'm going to grumble less about dealing with my own mistakes over someone else's, but rewriting everything every time someone quits isn't an option either.