Knupps idea of the totem pole rubbed me the wrong way too. I've met great developers who didn't have a clue about how to scale or monitor their software outside of their framework. How to properly deploy across DEV, UAT and PROD without making code modifications. How to keep these environments clean and flexible to enable these deployments. Nor should they have to. Call me a Dev because I read and write code. Call me Ops because I do deployments and fix production issues. At the end of the day I solve problems and just plain make stuff work. With or without so called DevOps tools.
You think that deploying code just means "push to master and reload/restart servers"?
Even if you think that it entails more stuff, like knowledge about AWS, rackspace APIs, provisioning tools and whatnot, it's not enough. Mostly because in any medium to large
company they build tools and processes on top of them. Have fun learning all of that,
while you only need to commit your code.
Plus, since I've been for many years a sys admin guy that turned into a developer, I can
tell you that there are different skillsets involved, albeit with some overlapping ones.
No doubt deployment is not a simple process in many cases, and I have respect for the ops position. But the line I was referring to specifically stated, "I've met great developers who didn't have a clue about how to scale or monitor their software outside of their framework." To me, being completely clueless once you leave your IDE is a pretty strong sign of a "not-great" developer. For instance, how do you know how to write good scalable code if you have no clue how the sausage is being made? Not saying you have to be an expert at the full stack, but you should have an idea of the basics.
For me, the idea of devops was always to help developers gain enough insight into operations, to be more useful. I don't care if you can easily test your war-file from within eclipse -- make sure that it can be sensibly deployed and upgraded on a locked down headless box.
Basically turning great developers into great system architects.
To me, it seems like it makes sense that a great developer should absolutely know how his code is running, how his changes interact with the production environment in which the code runs, etc.
You'd take a hit if you visit any big company that's not centered around IT.
It's quite common for the developers to be forbidden from knowing the details of the production environment, and usually they have no easy way to get that info. But don't mind, a DBA will think about the interaction between the several programs, and the ops people will think about performance.
It's worth taking to heart. It seems to have come out of Heroku-land, and it's baked into Heroku. Of course, that's an even more restrictive environment in some ways, but the underlying concepts are true for larger and more complex things than can be easily executed in Heroku.
Now all you have to do is get them to grok immutability...
Those don't sound like great developers to me. Those are the kind of people who are going to introduce subtle bugs and say 'welp, works on my machine closes ticket'
