The New DevOps
My first five years as a software engineer, I worked primarily with a particular programming language. I had some responsibilities around testing and deployment scripts, but mostly I just worked with code and code-related activities. The following five years have been much different - there are entire projects that would have gone undelivered if I wasn't able to provide support in some area of Operations - networking, databases, operating systems, etc.
The development landscape has changed over the past several years. The lone-gunman programmer going off in a corner for months to deliver functionality has been replaced by development teams delivering business value every few weeks.
A similar shift has recently occurred in the area of Operations. Developers used to be responsible only for writing and (hopefully) testing their code. Infrastructure, networking, operating systems, RAM, CPU, power, and similar topics were someone else's problem.
Today, the landscape has again shifted to a more collaborative model merging development and operations (DevOps). Developers need to know much more about the operational components of their software - especially around network programming, services development, and continuous deployment. Likewise, the developer's IT counterpart needs to know much more about development - especially around infrastructure automation (Chef/Puppet), automated testing, and continuous deployment - I recently read a resume for an operations candidate that listed Ruby as one of the core skills.
As time progresses, the lines between developers and operations specialists will continue to blur, resulting in an ever increasing need for collaboration and communication between groups.