4 ms·

Talking in terms of mine and yours means we are not on the same side. And this is the problem. If there is a problem with the deploy let's meet, fix the issue

Talking in terms of mine and yours means we are not on the same side. And this is the problem. If there is a problem with the deploy let's meet, fix the issue and most importantly learn from the problem, and document the incident for future reference. And them move on without fingerpointing.

CodeMage 5y ago
Just because I have my responsibilities and you have yours, it doesn't mean we're not on the same side. I've come to dread cute management phrases like "everyone should pull on the rope". I agree with the sentiment, but software development is not as simple as pulling on a rope. There are lots of moving parts and lots of things to specialize in. And I say this as a generalist dev, not as an ops engineer. I agree with TFA completely. I was interviewing for a job recently, and one of the questions I would ask when the interviewer signaled it was time for me to ask questions was "how do you handle QA?" On some occasions, this got me weird looks, because "QA" seems to be an antiquated concept. In a similar vein, my stint at Amazon taught me that one of the questions to ask my interviewers is to tell me about their on-call rotation. Is there any? How often are you on call and for how long? Who gets paged first? Yeah, we're all on the same side, but there needs to be some structure and order. Otherwise, you end up with something like this: "Twenty-seven people were got out of bed in quick succession and they got another fifty-three out of bed, because if there is one thing a man wants to know when he's woken up in a panic at 4:00 A.M., it's that he's not alone." -- from "Good Omens", by Sir Terry Pratchett and Neil Gaiman
- deleted 5y ago
  [deleted]
hakre 5y ago
> If there is a problem with the deploy let's meet, fix the issue and most importantly learn from the problem, and document the incident for future reference. Not being on the same side should not be the problem, it's the solution if you divide the work as each side has to treat things differently while working together. Operations takes care to restore the operational side. The faster the better. Developers need or normally want to tackle the issue differently and most likely after operations reports updates they can decide whether the workaround is acceptable or development wants to maintain further on. this normally works very well this way as operations does not have the time to maintain the application but the developers have.

CodeMage 5y ago

Just because I have my responsibilities and you have yours, it doesn't mean we're not on the same side. I've come to dread cute management phrases like "everyone should pull on the rope". I agree with the sentiment, but software development is not as simple as pulling on a rope. There are lots of moving parts and lots of things to specialize in. And I say this as a generalist dev, not as an ops engineer. I agree with TFA completely. I was interviewing for a job recently, and one of the questions I would ask when the interviewer signaled it was time for me to ask questions was "how do you handle QA?" On some occasions, this got me weird looks, because "QA" seems to be an antiquated concept. In a similar vein, my stint at Amazon taught me that one of the questions to ask my interviewers is to tell me about their on-call rotation. Is there any? How often are you on call and for how long? Who gets paged first? Yeah, we're all on the same side, but there needs to be some structure and order. Otherwise, you end up with something like this: "Twenty-seven people were got out of bed in quick succession and they got another fifty-three out of bed, because if there is one thing a man wants to know when he's woken up in a panic at 4:00 A.M., it's that he's not alone." -- from "Good Omens", by Sir Terry Pratchett and Neil Gaiman

deleted 5y ago
[deleted]

hakre 5y ago

> If there is a problem with the deploy let's meet, fix the issue and most importantly learn from the problem, and document the incident for future reference. Not being on the same side should not be the problem, it's the solution if you divide the work as each side has to treat things differently while working together. Operations takes care to restore the operational side. The faster the better. Developers need or normally want to tackle the issue differently and most likely after operations reports updates they can decide whether the workaround is acceptable or development wants to maintain further on. this normally works very well this way as operations does not have the time to maintain the application but the developers have.