Production access is not a privilege
Access to production is not a privilege, and it is not a reward for writing good code. If something goes wrong, finding someone to blame matters far less than restoring the system quickly and minimizing the impact.
When I was a junior developer, I wasn’t allowed to run queries in production. Not even the simplest ones.
Back then, it bothered me a little. I thought: how hard can it be? I know what I’m doing.
Now I’m in a lead role myself, and I’m just as reluctant to let other people perform potentially dangerous actions in production.
Because access is not a privilege. It is a responsibility.
Someone can be a good developer and still not know some of the project context. They might run the wrong UPDATE, delete the wrong data, restart the wrong service, or simply miss a consequence that only becomes obvious after years of working with the system.
And the problem is not even who is at fault.
Let’s say someone makes a mistake. They get told off, lose their bonus, lessons are learned. So what? Production will not come back up any faster because of that. And recovering the data, dealing with the fallout, and explaining to the business why everything was down will most likely fall to me.
That is why I prefer to handle dangerous actions myself.
Not because I do not trust people. But because if I am responsible for the outcome, it makes sense for the critical permissions to be mine as well.
Funny, of course: this used to annoy me. Now I understand perfectly why those people did not give me access back then.