I wouldn't call it a minor annoyance when it's a way of working you're practicing for 6-8 hours a day.

I am best placed to determine what tools I work with best to get work done. You wouldn't get an electrician in to do some work and then decide you can suddenly prescribe the tools they use.

I just don't have the patience for this sort of nonsense, there are a dozen clients who won't micromanage the operating system, editor and way of working that I'll be using to get the job done. With that said, obviously it's a two-way street and some willingness to be flexible needs to be shown on both sides. If $client wants me to sync my work with their $uniqueVersionControlSystem then fine, I'm willing to put in the extra effort to try and meet their specific needs within reason. But that doesn't extend to working inside a client-provided VM, using a client-prescribed OS image, using a client-specified IDE or making other such major changes to my established ways of doing business.

And in fact any client trying to micromanage this sort of stuff is a massive IR35 working practices red flag over here in the UK. You're better off terminating the agreement and signing something else as a SoftEng contractor.

It works both ways. There are plenty of companies that will happily take productive engineers, without forcing them to use a slow, poor-quality IDE as their main tool, full-time. It's not a minor annoyance if it's the tool you use throughout the day, to do a job for which you are then evaluated.

"Tools are just means to an end" is just one of the many rhetorical devices that cushy managers use to eschew responsibility. Of course they're means to an end, but some means are better than others, and usually those with better means end up doing a better job.

There are plenty of engineers but few good ones.

Hiring is brutal, especially now, so good developers can afford to be picky and find another semi identical job in almost no time.

I hear you, but I'm suggesting that this trait is part of what differentiates a good engineer. If I'm hiring someone and they have a bunch of recent moves that are stemmed from reasons like "they wanted to use some process that I refused to try" or "they made us go through some training that I thought was a waste of time", then I consider that to be a very risky candidate.

There should honestly be some good faith on both sides. It doesn't make sense for a job, in most cases, to be strict about an editor. But it's also not a good move for eng to be walking around talking about all the fragile things they'll quit abruptly for.

> stemmed from reasons like "they wanted to use some process that I refused to try" or "they made us go through some training that I thought was a waste of time", then I consider that to be a very risky candidate.

I feel like you're gradually making this hypothetical engineer seem more ridiculous. If someone quit over training or their unwillingness to try scrum, that would be bananas of course. There's an extremely large gap between that and mandating the main tool to use to do your job everyday.

Totally, I think if something is making you quit it must be pretty annoying - or you wouldn't risk trading the known with the unknown (which can very well end up being worse). I also wouldn't mention the real reason in a future job interview, if it sounds ridiculous.

That said, small things can look trivial from the outside and make your life a living hell at the same time.

I'm also not sure I agree that there are few good engineers. I think that's some rhetoric that we all say because we all think we're some of the few good ones.

In my experience (FAANG, startups in the valley and startups out of state/country), strong engineering talent is not particularly difficult to find, but finding a good fit is the tricky part. And I would wager that eagerness-to-rage-quit is a pretty good indicator of someone who will have trouble finding teams that they fit on.

That depends on what kind of companies you want to work for.

If you look outside of FAANG (companies in the rest of the world with unattractive stock), finding good engineers is a problem and most codebases are filled with horror.

The plus side is that, once you're a good engineer, you get little stress/pressure and a lot of leverage on flexibility (eg. remote in cheap places, in pre covid times), even if you won't make as much as FANG engineers. Also, interviews don't require 2 months of preparation every time you want to jump ship.

I'm sure if you're paying FAANG money you can find plenty of good engineers happy to do backflips.

Not a rage quit, but I absolutely would look elsewhere. Folks are allowed to have dealbreakers for where they work.

A lot of people "rage-quit" basecamp over their no politics thing. I probably wouldn't have, but to each their own.

FWIW, I have also spent lots of time at FAANG, startups, etc and haven't had any trouble finding a great fit. I have also never looked more than a week or two for a job when I wanted to leave, so that does factor into my willingness to leave if I'm not enjoying my job.