> Dictating to people how their workflow should look - _that_ is the antipattern. Developers should choose their OS, their editor, and virtually everything about their workflow.
I'm not convinced it is. Back in the day, each developer had their workstation (not laptop) configured just so, with their own pile of `doit.sh` scripts to tickle the system in just the right way, to get things to compile and render and send it off to production. But we're no longer there. Developer velocity is a thing companies take seriously, so developer workflow is actually important to them, and standardizing one true editor as the supported editor means that all the developers get improvements whenever the internal tooling team does a release. And I'm saying this as a vim person who's tried to move over to VSCode (and have failed so far).
Of course, smaller companies don't have an internal tooling or developer productivity team, and thus allowing people to choose their own tools is optimal. But I've also seen the big picture efficiency loss that results from every developer having a bespoke configuration thats intelligible only to themselves, and the inability to unilaterally improve people's tooling and integrations with various systems they interact with. Once the team gets debugging over SSH working or whatever, they can just deploy that, in a working state, to everyone.
There's a world where Slack is the one true communication method and everyone is on a Macs. Unfortunately for me I'm set in my ways would rather use Ubuntu on a Thinkpad with vim, but that doesn't mean I haven't see that other world.
Have you tried neovim? You can have pretty close to feature parity with VSCode due to it's LSP support; for most languages, you'll be using the exact same Intellisense engine (LSP server) as VSCode. (Python is the exception I'm aware of, but python-lsp-server is serviceable even if Pylance, the proprietary VSCode one, is better). And when the internal tooling team ships a new version of the LSP server, you'll be able to use it too!
When it comes to everyone building things the same way - that's what containers and CI/CD is for. If we didn't have those tools, then I may be more inclined to agree, but we do and they work. Do they work perfectly? No. But they ought to surpass this fairly low bar. If they didn't then I don't see how we'd have confidence in a centralized solution either.
I literally cannot use an editor other than neovim without hurting myself due to an RSI problem. Believe me, I have tried them all. If I was told that I must adopt VSCode, I would literally have to quit for my health. That being said, VSCode is an excellent tool, and some people I know with RSI issues swear by it. More power to them.
Developer velocity is definitely not going to be helped by handicapping your developers and forcing them to use tools that don't quite fit their workflow. I'm reminded of an anecdote about fighter pilots, it may be apocryphal, I don't know. But it goes like this; the air force was designing the seat for their fighter planes. So they took measurements of a statistically significant number of fighter pilots (all or most of whom were men), averaged them, and designed a seat to accommodate that figure. But pilots complained the seats were uncomfortable, and as the demographics changed and more women became fighter pilots, they were very poorly served by the chairs. Eventually they realized that they had designed the seat for a body that no one had. So when they redesigned it, they designed a seat which was customizable, and allowed each pilot to get a seat which was comfortable for them.
Anointing a "one true workflow" is a similar mistake. It will chaff at your developers and you'll lose velocity due to the chaffing. Over time requirements will change and the workflow will cease to meet anyone's needs, and if your developers remain productive it will be because they are going behind your back to use what actually works for them. Your developers will leave you because they're tired of being patronized, and you'll lose velocity and institutional knowledge onboarding new people.
The internal tooling team can't be all things to all developers, that's true. Let them ship what they ship, and let other people figure out how to adapt it into their workflows. If someone is performing well and getting stuff done, do you care if they're using the internal tools? Or if they've wrapped the internal tool in some macros or something to better suit them? If someone is using the anointed workflow but can't work for more than an hour at once because it's too mouse heavy and it hurts their wrist, is anyone in the situation happy?
I'm not convinced it is. Back in the day, each developer had their workstation (not laptop) configured just so, with their own pile of `doit.sh` scripts to tickle the system in just the right way, to get things to compile and render and send it off to production. But we're no longer there. Developer velocity is a thing companies take seriously, so developer workflow is actually important to them, and standardizing one true editor as the supported editor means that all the developers get improvements whenever the internal tooling team does a release. And I'm saying this as a vim person who's tried to move over to VSCode (and have failed so far).
Of course, smaller companies don't have an internal tooling or developer productivity team, and thus allowing people to choose their own tools is optimal. But I've also seen the big picture efficiency loss that results from every developer having a bespoke configuration thats intelligible only to themselves, and the inability to unilaterally improve people's tooling and integrations with various systems they interact with. Once the team gets debugging over SSH working or whatever, they can just deploy that, in a working state, to everyone.
There's a world where Slack is the one true communication method and everyone is on a Macs. Unfortunately for me I'm set in my ways would rather use Ubuntu on a Thinkpad with vim, but that doesn't mean I haven't see that other world.