Ask HN: Would you quit your job if your tech stack changed?

[throwaway_32u10]

Imagine you are employed by a company and work with tech stack X. You know X, and like X, and worked with X in your previous compan(y|ies).

But then there is a change in the company/team, and they decide to switch to a new tech stack. You don't know this tech stack, you don't like it, and it has little prospect for future employment (think: old/not popular stack).

Would you quit/start looking for a new job immediately? Would you give it a try first and see how it goes?

[JohnFen]

If it's a stack I already know I genuinely can't tolerate, I'd immediately start looking for work elsewhere.

Otherwise, I'd give it a chance. Learning new (to you, not necessarily new to the industry) things is a joy, it adds another skill to your skillset, and makes you a better and more employable dev. Even if the new-to-you thing is old and/or not popular. Actually, not being popular can make it even more valuable as there would be fewer devs familiar with the stack.

But let me admit my bias: my worst nightmare is a job where I'm just using the same skills over and over. I've quit jobs because of that. So, personally, having to learn new things is something that makes a job more desirable to me, not less.

[zoezoezoezoe]

Assuming I don't know or like this tech stack, on top of the fact that it doesn't open up any potential employment opportunities, I probably would start looking for a different job with a stack that I am familiar with and/or enjoy working with. If my company changed the stack, and if I didn't know if I like the new stack or not, I would probably stick around at least for a little bit, changing the technology you work with isn't always a bad idea, and can give you a wider range of experience.

[solardev]

I'd give it a shot just to try it out and see how I like it. If I didn't like it, I'd try to understand why – what are the pros and cons of that approach vs the ones I'm familiar with – before tossing it out altogether. Once I feel I have a solid enough understanding of why the stack is that why, then I can decide whether to embrace it for what it is, or otherwise to then leave that team/company.

A few times, I've been exposed to new stacks I didn't really like.

One was Drupal, coming from the Wordpress world. That was a real nightmare. I learned it enough to work with it, started an upgrade/rewrite to a new major version (not backward compatible), and then convinced my bosses it's not a good choice for us. I rewrote the whole thing in React/Next and cut away thousands of lines of code and config. Drupal is the only framework I swore to myself I would NEVER work with again. The rest of the LEMP stack isn't my favorite, but it's fine.

The other was Java. We had a web app written in React, with unit tests written in the usual Javascript frameworks and living alongside everything else. Then a new outsourced manager came in with a Java background and insisted we rewrite all the frontend tests in Java because that's what the backend was written in (still makes no sense to me). He hired other people from his country who also knew Java. It took more than a year to port over some tiny fraction of the tests, and we lost a bunch in the process. The Java testing framework they set up was kinda a hot mess, with machine-to-machine incompatibilities, issues with hardcoded paths, etc. And you could no longer run them with `npm test` in the repo, instead needing a whole container or VM just to start the Java env in which the tests would run. They took 100 times longer. The tests went from being our shared responsibility (that any web dev could maintain) to something only the one QA person he hired could write – but they weren't very familiar with HTML or CSS or Xpath. I had to learn just enough Java to help them debug their own tests and Java setups, in the process coming to dislike it (it's quite bloated and archaic compared to the modern JS DX). I didn't hate it, but it wouldn't be my first choice for a project. It did make me interested in Kotlin and (less related) Rust, though. I left that company soon after, due to that and other recurring incidents of poor management.

----------

Too bad there's not a tech skill-swap system. Got a project you don't like? Wish you were working in a different language? Find someone in the opposite situation to trade with! A few NDAs and some time tracking later, everyone walks away happy...?

[adamredwoods]

No. I am platform agnostic.

[gregjor]

The right answer. Tying your career to a small number of languages and tools seems short-sighted and self-limiting. I would interpret such a change as an opportunity to get my employer to train me (or give me time to train myself). Almost nothing goes away in the programming world, it just falls out of fashion.

How many laid off programmers looking for work today wish they had a broader range of skills, even if some of those skills seem old and not sexy? Always more maintenance work out there compared to new development.

[JohnFen]

> How many laid off programmers looking for work today wish they had a broader range of skills, even if some of those skills seem old and not sexy?

Exactly so.

I've been in this business for longer than many people here have been alive (and longer than some of the parents of the people here have been alive). Since the beginning, I've considered constantly expanding and deepening my skillset to be absolutely critical.

So now, I am competent or better in more languages and platforms than most. That includes many that that the younger crowd of devs would consider obsolete or worthless. However, those obsolete and worthless skills have, on numerous occasions, been what got me high-paying and fascinating work. Also, even in jobs where I'm not directly using those skills I am still indirectly using them -- when you learn a new (to you) skill, you're also learning a different way of framing and addressing problems. That makes you a better dev regardless of the stack you're directly using.