The creeping IT apocalypse

I can't stress how important this is. Folks going to things like boot camps or other educational outlets that focus on one language will utterly kill their career if they aren't aware of how fast things move. If you don't learn the underlying abstractions and paradigms that take various forms in different languages, you will get left in the dust in a matter of a few years.

The best programmers I've ever worked with got excited about programming patterns and paradigms, not frameworks and syntactic sugar. Those are also the ones I paid the most attention to.

Bottom line for both software and IT engineers: you learn to learn, not just to do.

I'd argue that skill applies even after you get hired. Fudging details to get around wasteful trivialities without outright bullshitting the person asking for the requirement is truly an art, and it's very hard to navigate this field without that skill.

But... the job, if you were a mid to senor sysadmin, was always to automate away your job. There was always this race against yourself and the other sysadmins to keep your skills ahead of the scripts, and there were always people who fell behind during the crashes and couldn't get back in.

Really, I think the radical change that cloud brought us sysadmins was that employers care so much less now about your ability to go from a kernel backtrace to bad hardware. Knowledge of hardware in general has lost most of it's value; that's a lot of my knowledge and experience that isn't worth much anymore, and a lot of people who will have to find new roles. in my early 20s, I paid expenses while trying to start a company being on-call datacenter guy for a few small companies. I mean, I'd charge a minimum number of hours, they'd call me up or depending on the customer, my systems would page me when something needed fiddling with at the datacenter. - this job... almost doesn't exist anymore, because most of the customers are on AWS. (I mean, the job does exist; prgmr.com still even has co-lo customers, though I don't think they are accepting more... but it's super rare.)

Now, it seems like we want to split the sysadmin role into different titles;

SRE - production sysadmins; you have a high bar for programming skill and Linux internals knowledge, but a very weak requirement to have experience with standard configuration management tools (often SRE implies you will be using custom configuration management tools) -

then you have the devops title for smaller scale cloud sysadmins with a low bar for Linux knowledge, a medium bar for programming knowledge and a high bar for knowledge of standardized configuration management tools.

The sysadmin title remains for people who hit SRE standards for linux knowledge but don't meet the programming bar of SRE or necessarily have the experience with the standard configuration tools of the devops.

Generally, both in terms of pay and in terms of the number of machines you manage, SRE > DevOps > Sysadmin - of course, that's modified by level, location and company;

(Note, both SRE and DevOps involve systems design in ways that I don't understand well enough to speak about. I mean, I can pass SRE interviews at 3rd tier companies no problem, but at the first tier, I'm not even sure why I'm failing, which means I'm a long ways from passing. I mean, I also need to level up my programming to be a SRE at a first-tier company, but I have a solid idea of where that bar is and what I need to do to get there. I don't understand the systems design questions well enough to even really know what I have to learn.)

Also note, I personally think that SRE is probably a more solid career path than DevOps going forward, if you are in an operations career. Programming basics has been the thing that has changed the least during my career; the skill that is most portable. You don't want to marry a particular tool any more than you have to, 'cause that tool... might be out of favor next year.