Mature IT departments tailor solutions to different classes of users with different needs. If they don’t do that for engineering, that tells you everything you need to know about engineering’s stature in the company.
To an extent, and as allowed by whatever particular constraints exist for that business. Letting you run whatever IDE you want, usually OK. Letting you install whatever operating system you want, well... there’s lots of reasons you may choose to not support that choice, that have nothing at all to do with maturity. If your jobs was improving developer experience, there’s only so many times you can come up with solutions that work great for everybody except that one guy on Arch, before you give up.
This is more related to how organizations work. That larger organizations tend to need to streamline more in order to scale up number of employees, and do more to maintain acceptable security simply because there's that many more people on board.
If policy is install whatever you want, and if you get hacked, you're fired! This just won't stand in court.
So policy is that IT department is responsible for installations, IT department gets the blame. Infrastructure is sort of "outsourced" within the company.
If you were accountable for those younger first-timers running I2P and Tor within security perimeter, what would you do?
Lower down the tread I mentioned vendor due diligence, specifically because I’ve done so many vendor security reviews. But there’s more to it than that. You might also need to be threat modelling it, legal will need to review the ToS and privacy policy. You probably need to figure out the impact on other services too. If you’re in a regulated organisation, there could be any number of other things you have to do, and on going compliance costs. If you work in a bank, and somebody wants to install Gentoo, you’d have to figure out how to run anti-virus on it, how to centralise patches for it, how to install endpoint DLP, make sure it has the correct web proxy configuration... the costs can easily stack up.
Yes, you need to do all those things, and it is expensive. The organization's choice not to pay those costs to provide an environment suitable for engineering work (not every single one someone could ask for, but one) reflects its views towards engineering.
It may be correct for them. But for you, as a candidate, it's a good indicator that you'd be happier in the kind of company where engineering has the power to get that done.
Between jamfcloud, osquery, munki, etc. there are plenty of companies and tools out there catering to IT departments that take this seriously.
This has no impact at all on an organisations ability to provide an environment suitable for engineering. If they have an engineering practice, then you could be sure they’ve invested resources into making sure they do have a suitable engineering environment. The issue at hand relates entirely to personal preferences. The problem is that an individual can not necessarily use whatever tools they prefer, not that they don’t have suitable tools available.
But if your 10,000 employees each need a hammer, getting them all the same one, from the same vendor, with the same support contract might just make sense.
Edit to your edit: whatever particular sets of tools the business needs. Whether it’s laptops, thin clients, operating systems, IDEs, ticketing systems...
> Even then, what if some app does not work on Windows 10?
If your business had standardized on Windows 10, then you’d hope checking whether things worked on Windows 10 would be part of their procurement process.
> Or what if you need a 32 bit app running on macOS?
You choose something else. Like any business running MacOS would have to do.
I’d probably just pick a better analogy. If the job can be done on the operating system provided, then it can be done equally well by anybody using that operating system. No need to grow bigger hands.
If you’re working from the premise that your brain is only suited to work with one operating system, then you’re really only harming yourself, by shutting down any opportunities you may otherwise have open to you.
Small organisations have the luxury of letting people choose their tools more freely. As they grow, they tend to have to restrict this more. Not just because they might have to support the tools you choose to use, but because they absolutely will have to support how your choices work with all the other tools they have in the organisation. At scale, this starts to get out of hand pretty quickly, and the only way you can provide a good working experience is by adding constraints to the tools used.
On top of that, some organisations have regulations and compliance requirements to meet that make it even harder. If your basic procurement pipeline includes $10,000 of vendor due diligence, then you don’t want to just give everybody free reign to use anything they feel like. If those choices introduce additional ongoing compliance costs, then you want to control that even more so.
You could ignore all of that, and focus only on how it affects you. But there’s good reasons that organisations do that sort of thing.