3 ms·

I am in Ops and I can understand this point of view. The author is probably overwhelmed with issues that are 'not his problem' and this is his rant on it. To b

I am in Ops and I can understand this point of view. The author is probably overwhelmed with issues that are 'not his problem' and this is his rant on it. To be fair, Developers are getting slammed with their responsibilities too. At one time it used to be that they could just know one programming language really well, like java, compile their code and hand it off to QA. Now they have to know a dozen languages, frameworks, do their own testing, deploy the service, monitor it and trouble shoot everything in production in some 'cloud'. Or they are just being lazy and this guy is sick of it. That is when you do your best to train people up and get them to put in the leg work. Ask pointed questions about if they Googled the error and help them work through the problem. Then add some things to the docs to help others out in the future.

znpy 5y ago
> To be fair, Developers are getting slammed with their responsibilities too. At one time it used to be that they could just know one programming language really well, like java, compile their code and hand it off to QA. Oh no, responsibilities! Meh, the days of throwing a tarball to QA and log off at 5pm are gone, thankfully. Some organizations empower their ops team to close support tickets by just saying "not enough information to diagnose a problem". I've seen with my own eyes team metrics improvement (SLAs etc) by just counting the time the ticket was "in progress" to the ops team instead of waiting for the developer (or customer, whether internal or external) to reply.