The DevOps movement is supposed to promote a closer collaboration between developers, testers, operational people, and really anyone else that must help software gets build and deployed. The developers need to coordinate their needs and requirements with operational staff. They should work early on with any staff performing testing to help them ensure that bugs are caught quickly and fewer slip through to production. At the same time, operational staff should be responsive  and helpful in all the environments software moves through. Operational staff should help build and automate the configuration of development and testing environments, ensuring that systems are built in a repeatable fashion as well as the same way in each stage of the software development pipline.

However, is devops killing the developer? If developers are becoming responsible for testing, that's bad. If developers must learn to function as a DBA as well, then I certainly expect they'll write less code. If developers need to ensure the software can be installed on production systems and train operations staff, then I suspect they aren't very happy with their jobs.

But that's not DevOps. If that's how your organization runs its development, it doesn't understand DevOps. Developers should be leaning on and learning from, as well as teaching other staff. When I read that post, I think the developer has missed the idea of DevOps. It isn't that developers need to become completely versed and responsible for the full stack. It's that they should be working with everyone involved in the process the entire time that software is being developed, using the specialized knowledge each person has.

DevOps isn't something new. I've worked in teams that worked like this in the past, but we never had a name for what we did. We just thought we were part of the same team. I've also worked in organizations with walls between all groups. That wasn't a team, and we had lots of four letter words for that style of process.

DevOps is a good term and a good idea for software development. If a company implements it well, then it works and people are happier with the way software is produced. If they aren't, then the process hasn't been configured correctly.