You learn more from your mistakes than anything else, and I have made my fair share. The trick is to actually learn from them rather than just suffer through the consequences and call it experience.
I have watched developers push code to production on a Friday afternoon because the business was breathing down their necks. The deadline was immovable, the pressure was real, and the production environment was treated as an afterthought. I have seen it happen more times than I care to count, and each time the same thing goes wrong: someone breaks something, and nobody wants to own it.
The reason is straightforward. Developers are caught between two fears. Refuse the request and risk being labelled uncooperative, maybe even replaceable. Comply and you inherit the mess when things go sideways, but by then the blame has already been diffused across the team. Most people choose the second option because it feels safer in the moment, even though they know full well what is coming.
System administrators live in the opposite headspace. Their job is to keep things running, and running means nothing happens. A stable production environment is their entire reputation. The idea of deploying untested code on a whim is not just unappealing – it is professionally dangerous for them. One bad release and the entire team takes the heat, but the administrator is the one who has to fix it at 3am.
This is where the friction sits. Developers are rewarded for shipping. Administrators are rewarded for stability. Neither side is wrong, but both sides are incentivised to push the problem onto the other. The developer says “it works on my machine” and the administrator says “we have a change management process for a reason.” Both are technically correct, and both are avoiding the real conversation.
The organisations that get this right are the ones that stop treating deployment as a handoff and start treating it as a shared responsibility. When developers understand the operational impact of their code and administrators understand the business pressure to ship, the conversation changes. You stop arguing about who owns the problem and start figuring out how to ship without breaking things.
It is not about drawing a line in the sand and saying “this is your job, this is mine.” It is about recognising that the line exists, understanding why both sides of it matter, and finding a way to cross it without setting the whole building on fire.