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)