> "sysadmin" as that term was used in the 80s/90s job roles was usually not a hard-core C++ programme

I am now a "SRE" as a very large "webscale" company.

I was, am, and will continue to be a sysadmin. All of the principles that I've been using for the last 15 years have not really changed. only the tools.

The concept that sysadmins were only ever point-and-click, or physical lift and shift, is a stereotype that needs to die. We were _always_ programming our way out of things. The whole point of a sysadmin is that you are lazy, to be lazy you need to:

1) find out what changes are coming down the track

2) automate those changes.

You could only every be a good sysadmin if you knew what the business needed. Sure tech is fun and all that, but if we have the most stars on our repo, but no income stream then we are sunk.

That means:

o providing a rock solid platform for devs to work on.

o Removing the thorns and friction from the entire system.

o making reliable, logged, secure and metric'd code the easiest type of code to deploy

o clearly documenting how to do things

o keeping costs down

o bugging people when their shit breaks and they refuse to fix

The best sysadmins have always been programming/automating (and are lazy in an enlightened way).

But the stereotype exists for a reason; many admin roles and admin staff were/are “zero scripting expected” help desk type roles.

I feel like this version of "sysadmin" went out of favor some time ago.

Back in the early '00s I got my start in industry as a sysadmin, working in non-SV startups. Although I had taken courses in C++ and could muddle through it, I seldom did much low level programming - the C/C++ knowledge I did have was helpful to read code, submit the occasional bug report, and understand the rube-goldberg build processes which really seemed to be in style at the time.

Most of the code I wrote was the kind of glue you needed to make sites work and web-ify basic tooling so normal users could access it - and that meant hacking in shell, perl, or python. These things I simply took for granted as part of a sysadmin's job. As the "web" stuff really took off, that eventually landed me doing more with PHP, Django, and Rails.

All of these things matched my conception of what a "sysadmin" would be, but the industry seemed to disagree with me. I worked in other sectors and came to realize there were a lot of "sysadmins" who not only didn't know how to code anything, but also had no interest in learning anything. Eventually I just stopped being a sysadmin and started being a web developer.

Now here we are, with devops and SREs, and I smirk a little. The guy coding up web sites to present internal metrics and writing software to facilitate point-and-click deployments while dropping into Valgrind to help out a lost developer? He's an SRE, I'm sure. But then, so is the guy in the next cube over, who worked the help desk for a couple months and really knows how to click install and reboot.

These labels come and go and they mean different things at different places. Like "agile" or "devops" - once they escape the FAANGs, they start to lose all real meaning.

Exactly - especially in more technical areas Sysadmins quite often doubled as systems programmers as well.

I once got hired as developer on billing systems for BT as I had SYSAD experience on the relevant hardware (PR1ME) and could run the systems as well as program them.

> a classical "sysadmin" as that term was used in the 80s/90s job roles was usually not a hard-core C++ programmer

I did not work in the 80s but the sysadmins I worked with in the 90s were the most skilled C programmers I've ever worked with.

Unless you mean C++ specifically, which has always been a bit divisive that world, UNIX has always been inseparable from C. UNIX, C and TCP/IP were joined at the hip. You would have to try hard to avoid learning at least the basics.

If anything sysadmins (or SREs or DevOps Engineers) these days program less, not more. So much have moved into frameworks and yaml. As reliability expectations of individual components tends to be lesser now, things like inspecting core dumps are not as common.

The mockery of the non working sysadmin has been a running joke as long as the job existed (BOFH, anyone). But the idea of simpler times is mostly a chimera. Things have certainly changed and become more complex, but our brains are still as limited as they have always been.

On a related note, "waterfall" was also never really a development model. It's just something to call processes more rigid than you'd like. Software developers have always had to contend with fluid requirements, with the expected varying outcomes.

>"In contrast, a classical "sysadmin" as that term was used in the 80s/90s job roles was usually not a hard-core C++ programmer."

No they weren't likely "a hard-core C++ programmer" since UNIX was written in C. SysAdmins at that time were however likely to be a hardcore C programmer working at an ISP or large university network. There you had to know how to maintain and modify source to things like Sendmail, BIND, Apache and RADIUS. There was no StackOverflow or Google to consult. Your comment seems to be propagating some baseless trope that was never true. Your statements really suggest that you weren't actually there in the time period you are commenting on.

>To clarify, an SRE as Google thinks of it[0] is a deeply skilled programmer (e.g. C/C++ data structures algorithms knowledge) ... and the custom software they code helps keep the website running. In contrast, a classical "sysadmin" as that term was used in the 80s/90s job roles was usually not a hard-core C++ programmer. I made a previous comment about the difference that was motivated by COTS vs internal custom software stack.[1]

Quite the opposite actually.In the 80s/90s many of the sysadmins were skilled C/C++/Perl programmers.

Another unnecessary BS term. Other day I read SecOps... whenever I read SRE on HN, I think software reverse engineering [1], and I keep feeling disappointed every time I read the term on HN.

Classic sysadmins were, in my opinion, most certainly programmers. The shell involves programming (or "scripting" which is a derogatory term for high level languages). I know a fellow who programmed punch cards. Very unforgiving.

A sysadmin who's skilled with shell would also pick up Awk, Sed (hence regexp and Perl). Nowadays, Python. You don't need to be skilled with the shell anymore in order to admin a system. There's GUIs such as Windows, cPanel, and Webmin.

[1] https://en.wikipedia.org/wiki/Software_reverse_engineering

The fact that Google have many type of SRE, ops and more programming oriented, contradict what you're saying.

Some SRE will do little coding where other will work on tools 80% of their time.

There's an important distinction here: if your development team also holds the pager, you're not doing SRE. You're just skimping on sysadmin roles. You're doing SRE once you field a 12 person team of skilled programmers whose only duty is working on reliability.