Comment by eikenberry
12 hours ago
Seems very odd to me that someplace would force the use of a particular development tool. I've seen it only one time while interviewing, where they wanted everyone to have identical setups so they could easily hop onto each others computers when needed... it was weird and I took it as a red flag and didn't follow through them them.
This is common in many companies, IT wants standard development environments.
Some software development workflows require specific tooling, with complex setups. While it may be possible to do with other tools, it's often very difficult, and not really worth the trouble when there is a known working setup. It's easier to onboard new people if they use the established toolchain with known working configs. I worked at a place once where it took several days to get the dev environment set up. It would have taken far longer if someone wanted to use whatever random tool they'd prefer to use.
That is a massive red flag to me too. They are basically saying "you are identical to everyone else, and easily replaced."
Wanting to be able to use anybody's machine is very strange, agreed.
From a support/IT perspective though, the closer everybody's machine is, the easier the job is.
The last software shop I worked at, we had a default set of tools and configs. It was a known happy path. You were allowed to adventure off of that path, but you were mostly on your own.
> Wanting to be able to use anybody's machine is very strange, agreed.
Very useful if people are struggling to create reliable repro steps that work for me - I can simply debug in situ on their machine. Also useful if a coworker is struggling to figure something out, and wants a second set of eyes on something that's driving them batty - I can simply do that without needing to ramp up on an unfamiliar toolset. Ever debugged a codegen issue that you couldn't repro, that turned out to be a compiler bug, that you didn't see because you (and the build servers) were on a different version? I have. There are ways to e.g. configure Visual Studio's updater to install the same version for the entire studio, which would've eliminated some of the "works on my machine" dance, but it's a headache. When a coworker shows me a cool non-default thing they've added a key binding for? I'll ask what key(s) they've bound it to if they didn't share it, so we share the same muscle memory.
Devcontainers[1] or some similar technology are a must. Use whatever specific IDE you want, but the development environment itself should be identical across everyone on the team.
No more "works on my computer" issues. The environment is always identical.
[1] https://containers.dev/
It's quite common if you work in a team of engineers, or in a large company with many engineers.
Having consistent machine and OS and app configurations enables better (lower cost, higher reliability) scripting and tooling solutions in things like repos and infrastructure.
Not unlike consistency in language and compiler choices.
Having a consistent setup makes it easier for your organization's IT team to support you, troubleshoot issues, etc. It also makes it easier for you to collaborate with other members of your team, or even other teams. If your coworker Fred comes to you asking for help on how to refactor something, for instance, it will go much more easily if you're running the same IDE with the same refactoring tools.
Organizations establish and enforce standards for a reason.
Or they bust don‘t want to look after a dozen different tools and their security issues.