I have done both application development and ops. In my current job, I am doing both. There is a big difference between the mindset of what makes a good applic

I have done both application development and ops. In my current job, I am doing both. There is a big difference between the mindset of what makes a good application developer and what makes a good ops person. Application developers, by and large, have a sort of "sandbox" within which features are developed. This sandbox results from working with abstractions, each with some kind of guarantee. For example, most application developers assume that what you write into memory will be what you get out. That is, hardware is abstracted. The idea that the memory chips themselves can have defects or can sometimes fail, even if one gets error-correcting memory chips, is a violation of guarantees. Memory that just works is taken for granted. Another example is assuming that the system clock is monotonic. This extends to things like networks, storage, operating characteristics, and so forth. Very few application developers get into that nitty gritty, let along all the plumbing and interactions among different systems. I've seen application developers get incredibly frustrated and angry when those underlying guarantees are violated in some ways. I've been like that when I put on my application developer "hat". The main reason is that the developer is holding as much of the state and logic as they can, and they do this by excluding things through abstractions. They want their tooling and platform to just work so they can focus on writing good software. The thing is that, for a good ops person, all those nitty gritty and plumbing is the focus of their jobs. It takes a very different mindset to troubleshoot: you start looking at those "guarantees" and find out what they are actually doing. I once interviewed at a place which has this amazing way of figuring out if someone has the mindset and tenacity to be a good ops person. It was not writing algorithims on a white board. It was a deceptively simple task of installing a piece of software. And even though there are documentation for installing that software, there are not documentation for installing that software for every single environment and requirements and its interaction with other systems. When adding in a time crunch, and the scrutiny of an observer, that simulates a pretty typical day pretty well. You have to have enough emotional intelligence to keep working through it until it works. Documentation is always sparse and can't be guaranteed to be correct. Runbook? Good idea, but there is no way even meticulously crafted runbook for one component is going to be able to describe how systems interact with each other. Someone, somewhere has to figure that out. (Well, they don't have to. We can just let the system fail). And sometimes, as an ops person, you have to open that "black box" and read code. Just like sometimes, an application developer needs to pop open the abstraction layer and pull out netcat or sysdig. In the end, I'm not lamenting that DevOps blurs who owns what. Maybe this is because I've mostly worked on small, early-stage startup teams. Complexity has to live somewhere. I like working on the teams where people talk to each other to figure things out.