> "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
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.
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