4 ms·

this devops is also a dumping ground for anything else not happening on a developers computer which they should control but wont because "That is devops job" mo

this devops is also a dumping ground for anything else not happening on a developers computer which they should control but wont because "That is devops job" mostly this happens alot with node projects for some reason..

duxup 4y ago
Humans are kinda terrible when they can just "not my problem" things.
chrisweekly 4y ago
"anything else not happening on a developers computer which they should control but wont" Ok, I've seen this, but IME (24y in industry, the last 6 as a consultant) in the vast majority of cases, it's more like "things devs should control but CAN'T [bc CICD etc are silo'd and owned jealously by an overburdened ops team unable or unwilling to facilitate self-service]".
- outworlder 4y ago
  Some of the 'jealousy' may also come from bad experiences. It only takes a few instances of people royally messing stuff up in production for their deployment rights to be stripped away – and other groups catch the fallout too, as new "procedures" get implemented.
  - dijit 4y ago
    "Safety rules are written in blood" applies to parts of the organisation too. Sure, there are some overbearing procedure monkeys who really want a process on everything, but a lot of "protection" rules are there because something really bad (and expensive, financially or reputationally) has happened before.
  - kazen44 4y ago
    Also, some developers do not seem to know what kind of impact a production issue can have. Having something not work during the development cycle is annoying for one person or a team. Having something break in production usually means people get paged and (depending on what you do) the resulting issues can have major societal aswell as economic impact. In the ops world, this is especially visible if you go further down the stack. (from applications down the the network). Network architecture moves at a toad's pace compared to webdevelopment, which is a good thing considering breaking the network will usually break every other system inside a IT department/landscape.

duxup 4y ago

Humans are kinda terrible when they can just "not my problem" things.

chrisweekly 4y ago

"anything else not happening on a developers computer which they should control but wont" Ok, I've seen this, but IME (24y in industry, the last 6 as a consultant) in the vast majority of cases, it's more like "things devs should control but CAN'T [bc CICD etc are silo'd and owned jealously by an overburdened ops team unable or unwilling to facilitate self-service]".

outworlder 4y ago
Some of the 'jealousy' may also come from bad experiences. It only takes a few instances of people royally messing stuff up in production for their deployment rights to be stripped away – and other groups catch the fallout too, as new "procedures" get implemented.
- dijit 4y ago
  "Safety rules are written in blood" applies to parts of the organisation too. Sure, there are some overbearing procedure monkeys who really want a process on everything, but a lot of "protection" rules are there because something really bad (and expensive, financially or reputationally) has happened before.
- kazen44 4y ago
  Also, some developers do not seem to know what kind of impact a production issue can have. Having something not work during the development cycle is annoying for one person or a team. Having something break in production usually means people get paged and (depending on what you do) the resulting issues can have major societal aswell as economic impact. In the ops world, this is especially visible if you go further down the stack. (from applications down the the network). Network architecture moves at a toad's pace compared to webdevelopment, which is a good thing considering breaking the network will usually break every other system inside a IT department/landscape.