I think that the op is missing a side.
The article is about dev -> ops.
The other side is ops->dev. I.e. since infrastructure is software, ops become dev (and not just dev become ops).
The article is about dev -> ops.
The other side is ops->dev. I.e. since infrastructure is software, ops become dev (and not just dev become ops).
Atleast in my experience (ISP/DC world) most operational people where expected to do troubleshooting which at some points, results in one having to program to get to the nitty gritty efficiently. At a certain scale, issues start to creep up that are hard if not impossible to troubleshoot without atleast some programming and CS experience.
Are operational people developers? Not in the traditional sense, but the development of specific tools is required to efficiently keep the lights running.
A good example of this is troubleshooting packet loss. In a large network, this can become very difficult to pinpoint because more then a few dozen hops exist, and packets drop seem to occur randomly.
Without tooling to gather this data from different points in the network and doing statistics on it, it becomes nearly impossible to get a clear picture and troubleshoot efficiently.
It's one of the biggest differences I see day to day in enterprise operations and developer mindsets. Developers generally do not worry about who will support code before they write it, because their entire job is to write code. Operations teams on the other hand want to find an off the shelf tool, with enterprise support, even for what could be a fairly simple task.