I saw a comment yesterday about how IT admins have to restrict the privileges of other developers on their machines and was surprised by knowing this. I simply thought that employees in the software industry were essentially at equal parity in terms of their departments, and that the admin department was there just to centralise all the work done by other departments and keep track of the status of their systems. I did not think there would be a need to apply childlocks on other employees’ systems as I assumed that a person working at an industry like this would have basic computer literacy to know what is safe and permissible by company policy to execute and what is not.
This may come off as being too naive of me, but I genuinely want to understand how the hierarchy in such a company is actually like. I always thought of workspaces in the software industry to divide labour laterally and there would be no need for administrative powers apart from the management to exist, at least in regard to regulating other workers’ actions beyond normal workspace policies. It would be extremely kind of anyone to shed light on this matter.
Oh boy that would be a nightmare.
Don’t get me wrong, I can easily imagine a working environment where everyone is a professional and everyone is making well reasoned responsible decisions with their hardware. Such workplaces exist.
But in reality there are any number of reasons why individual workers shouldn’t have unlimited access to their machines or others in the pipeline. I’ve worked mostly in corporate (financial) software environments, but many of these things apply to all workplaces though many places will be far more relaxed (or disorganised)
A few off the top of my head:
Data loss - irrespective of who anyone is, they shouldn’t be able to plug removable media into a machine and download the production database without being noticed. Likewise, for everyone’s safety, no-one should be able to plug a usb stick they found into a machine connected to the network. Exceptions can be sought, and granted, as part of an audited process. Anecdote: I worked one place where we were due to continue working over the weekend and a business analyst took client data home with them on an unencrypted usb stick.
Verified software - people shouldn’t be able to download and execute whatever they feel like as this offers a huge attack surface. Many companies maintain a list of verified software and install this centrally rather than allowing people (even developers) to download it and install it themselves. Again exceptions can be granted. Anecdote: one place I worked, an member of the infrastructure team had installed bitcoin miners on company servers.
Stability - developers generally do not have access to the production environment, running deployments is the responsibility of a dedicated team, this is because the temptation to meddle when in a pressured situation is too great. Anecdote - at one bank I worked at I made a mistake in a package of changes I’d prepared. The person running deployment came and told me and - because of a particularly time sensitive issue - we went and figured out the issue at the point of production deployment and fixed it manually. This worked but was exceptionally irresponsible. At a different place I worked, early in my career, I made a similar hacky fix and took down the public website of a major UK utility provider for several days
Quality - the software development process has many checks and balances between areas of expertise designed to bring out the best even if it’s more frustrating getting there. Want to change the indexes on the DB? Got to convince the DB admin that it’s the right thing to do, can’t just do it myself. Want to close that ticket that’s way overdue? Can’t unless QA / testing approved else I’m just marking my own work. Want to make changes in the integrated dev environment because that’s far easier that developing against the out of date mocks in my own sandbox? Nope. Want to expose a new endpoint for my services to talk to unilaterally? Nope, need architectural sign off, network security signoff, and the infrastructure team. Anecdote: All of these have been areas where I, a reasonably skilled developer, would have compromised in various points in my career when my back was against the wall and I was under pressure to deliver.
Some corporate environments can be suffocating, other software places can be so lax as to be alarming. In my experience there’s a sensible balance in the middle and the best places to work have been where management is sensitive and reactive to the needs of developers to get the job done in as reasonably a safe way as possible.