Why shouldn't you let developers near root passwords? [duplicate]

I just came across Something is burning in the server room; how can I quickly identify what it is?. In the comments I found the following quote:

you don't let a developer anywhere near your root passwords

As a developer but also someone very interested in sysadmin stuff, I'm wondering if there's anything to this phrase more than just the standard for everyone - that is, don't give away passwords? The commentor states this as though it's fairly common knowledge in the sysadmin community. Is it?

I am not saying sysadmins are perfect, but there are a huge number of examples of developers that shouldn't even be developers. Let alone being permitted to having root access to systems with mission critical data.

But in any case it is mostly about taking responsibility for changes made. For many sysadmins it seems that developers will go do things on servers, and then they do not take responsibility for what they have done. Developers are often only focused on getting the single program/task they are working on going, and don't take the time to think about the big picture or long term state of the system they are touching. They haven't learned habits about how to make changes safely.

These aren't true for all developers, there are certainly some great developers that can maintain systems just fine. It just often seems like these are true 95% of the time.

Habits like:

• Don't make changes to a system without testing on dev systems first
• Don't make changes that you don't understand (blindly Googling, and doing things you don't understand)
• Don't make changes without verifying that you know that the backups systems are working, and how to roll back anything you do.
• Don't make changes that will make the system more difficult to maintain in the long term. (ie, don't add any technical debt)
• Don't compromise the security of the system
• Don't change the system in a way that will increase the potential regulatory risk (see PCI-DSS, HIPPA, FERPA, etc)

Since the operational responsibility of a production system usually pertains to a Sysadmin, only a Sysadmin should have full administrative access to the system - it's as simple as that.

Now, you might say "Well, sometimes we make code changes that require system reconfiguration, shouldn't we have access to reconfigure the systems accordingly?"

NO

If your code changes require system reconfiguration, you should be able to explain to a sysadmin what requirements you have. That way, the sysadmin can review your change requirements and halt the change if it might have operational implications that you - as a developer - might not have foreseen.

In response to @NathanLong, I realize that in smaller businesses this is sometimes the case. In these situations, where admins and devs are the same users, an alternative is to divide system ownership between multiple persons, and make sure that no one - and I mean NO ONE - pushes their own configuration changes. Have another dev review your changes, let a third one carry out the reconfiguration.

Whenever doubt occurs, start over with change planning and reviewing - anything else would constitue horrible change management