[halbritt]

No disagreement here.

There are, however, a number of people in the field that are all ops and have no development abilities. There is less and less of a need for those kinds of people.

This has been hashed about at length, but the inverse is also true. Developers must learn to operate their software in production.

[mmt]

> There are, however, a number of people in the field that are all ops and have no development abilities. There is less and less of a need for those kinds of people.

I very strongly disagree, unless what you mean by "no development abilities" is merely an inability (or refusal) to write or modify (maybe debug) code. There is here, what I believe, a very important distinction, that is routinely lost, and has all but totally devalued Ops skills in the minds of many tech hiring managers who have exclusively programming backgrounds.

I was on a phone interview today, in fact, lamenting, along with my interviewer, that there exist such sysadmins who don't even write scripts or automation. He suggested that they've started to call themselves "IT", and, IMO, that may well be a more apt term even than "Ops". My own experience is that, back in the dark ages, a traditional sysadmin not only had to be proficient at scripting but also at some amount of C just to port open source tools between various proprietary Unix version, especially with new releases.

That does not, however, bestow upon me, anything that I could call, with a straight face, "development abilities". I hold in my head none of the best practices having to do with programming that have accumulated over the 3 decades of my career, for example. Instead, I hold the Ops best practices. Being able to implement FizzBuzz in bash is neither necessary nor sufficient for software development.

> Developers must learn to operate their software in production.

I disagree here, as well, on behalf of developers.

I think you'll find having to learn what is, essentially, a completely separate, new, engineering discipline, in addition to software development, severely cuts into their productivity.

Unless I bring production to the developers, almost like bringing the upstairs downstairs in the cartoon pushbutton house[1]. I do actually feel it's a responsibility of Ops as part of Devops culture to create as frictionless (for their needs) a simulation of production as possible for developers. The practice has all sorts of benefits, including eliminating "works on my machine" debugging issues, that has been one of the rallying cries for containers.

[1] https://answers.yahoo.com/question/index?qid=20080403063620A...

[cthalupa]

>I very strongly disagree, unless what you mean by "no development abilities" is merely an inability (or refusal) to write or modify (maybe debug) code. There is here, what I believe, a very important distinction, that is routinely lost, and has all but totally devalued Ops skills in the minds of many tech hiring managers who have exclusively programming backgrounds.

Not everyone does the same job you do, even if they might share the same job title. I'm proficient in bash and python, have been learning rust, and know enough c to get around, but there have been many years in my career where my actual sysadmin duties required little more than being able to do 'while true; do x; done'

That's very much not been the case over the past half decade, but there were times in the 2000s where nothing was necessary beyond some basic bash scripts. No writing, modifying, or debugging of anything I would actually call code was needed.

I've also done hundreds of interviews for sysadmin positions. I'd say the minority of them were proficient beyond the very basics of bash. Most of them seemed to be doing well enough in their existing roles to not have been fired.

shrugs

[mmt]

> Not everyone does the same job you do, even if they might share the same job title.

That's true about any title across the entire computer industry (and maybe all technology), but it doesn't say anything about the categories those jobs fall into and skills/experience associated with those categories.

> my actual sysadmin duties required little more than being able to do 'while true; do x; done'

If you mean that was the level of the complexity of the scripting/automation required, there's nothing wrong with that. Consider, however, trying to do even that, without any scripting at all.

Presumably something like 'do x', up-arrow, return, up-arrow, return, ad infinitum. Apparently, that's the kind of person that's moved into "IT" that was being described to me, though this was pure hearsay.

> That's very much not been the case over the past half decade, but there were times in the 2000s where nothing was necessary beyond some basic bash scripts. No writing, modifying, or debugging of anything I would actually call code was needed.

That would be comfortably (up to a decade) past the dark ages to which I referred. Please don't misinterpret my mentioning having had to work with C as being in contrast to basic bash scripts.

My point was actually quite the opposite, that it's all code, but that it's a form of working with code that is (at least subjectively) different from software development.

[halbritt]

Development abilities would entail having the ability to take a task, or feature, write code around that task or feature including tests, and then submit a PR.

As someone doing the hiring for such things, people looking to get hired seem to have a different view of things. I don't need someone with an advanced degree in CS and mastery of algorithms to produce API endpoints and orchestration bits.

As for having software developers handing off their software for someone else to operate, well, that's an anti-pattern that inhibits throughput and software quality. There's quite a bit of data around this topic. I would encourage you to read this book:

https://itrevolution.com/book/accelerate/

I'll grant you that it's difficult to get there in a traditional IT org, but once you do get there, the results are glorious.

[mmt]

> Development abilities would entail having the ability to take a task, or feature, write code around that task or feature including tests, and then submit a PR.

No dissonance from my end, and I'd say that other than the very narrow overlap of being able to "write code", that's quite distinct from what, for example, my Ops skills are.

To be fair, I did think of some other potential relatively narrow overlaps, such as revision control systems, strace/dtrace, and debuggers, but the latter is a bit tenuous, since it's a niche/vintage skill. Even with VCSes, I don't need, know, or use most features (and miss features like "svn export").

> As for having software developers handing off their software for someone else to operate, well, that's an anti-pattern that inhibits throughput and software quality.

You may be implying a false dichotomy (or maybe I'm reading one in that you didn't intend). I don't think anyone, myself included, is advocating in favor of the "throw it over the wall" anti-pattern that the original Devops cultural movement advocated so vehemently against.

I absolutely agree that developers should remain responsible for the operation of their software in production and, to whatever extent necessary, be involved in that operation. I'm also saying that if "whatever extent necessary" isn't remarkably minimal, it indicates something seriously wrong with the software, with the production-like development environment Ops is providing (i.e. implementation of Devops culture), or both.

[halbritt]

I was precisely thinking the "throw it over the wall" anti-pattern. Now that I understand your sentiment, I concur with it.

[nasalgoat]

I've been doing Ops for 20 years and even back in the 90's I barely had to understand what a Make file was doing. I've certainly never had to do much actual dev work.

My main worry is that specialization won't return soon and my Ops skills won't be enough to keep me employed.

[mmt]

I consider this an important perspective, because it illustrates something I have heard criticized (and which I criticize in its narrow form, as well): overspecialization/overfocus.

> I've been doing Ops for 20 years and even back in the 90's I barely had to understand what a Make file was doing. I've certainly never had to do much actual dev work.

Although I ended up being pretty comfortable with Make, I wouldn't characterize what I did with it as actual dev work, either. The vast majority was tweaks of existing makefiles to get them to work on new platforms.

I'm not sure even the devs I worked with back then had as much exposure to Make as did the release engineers (part of QA).

> My main worry is that specialization won't return soon and my Ops skills won't be enough to keep me employed.

The latter part may end up being true regardless, in which case Ops skills will eventually be lost, to the detriment of the industry.

I doubt it, however, because even in the vast majority of Devops-as-a-title job postings, no matter how much emphasis is placed on automation, building internal tools, CI/CD, "dev", or "infrastructure as code", Ops skills (some of which those arguably were or overlap with) are still key. Otherwise, they'd just be hiring developers and having them perform these functions [1].

All that said, I don't know what the right answer is for staying employable.

I know it's not merely waiting for (a subset of) skills from the 90s to become valuable enough again. That would be doubling-down on what might be too narrow a specialization. However, even making sure one has at least some expertise in as broad range of Ops skills as possible, including networking, databases, and especially enough coding to enable routine (if basic) automation, may not be enough.

Maybe the answer is acquire just enough dev skills to get hired into those hybrid roles and then either wait until the Ops part becomes important enough to be full time or deliver so much more value with Ops than dev that the latter responsibilities get transferred to someone else. I have, so far, not done this, both because it feels slightly dishonest and because, like in the footnoted situation, I fear it leads to lower productivity/quality on the Ops side.

[1] Judging by some comments I've seen here, this also happens but has not yielded a large set of examples of successful outcomes (including keeping those developers happy and productively developing)