You know what is more important for a infrastructure/devops engineer,
previously simply called "sysadmin"? Understanding several compilers and
interpreters (and actually learning several programming languages). Unix C API
(fork(), exec(), file descriptors, pipes, sockets, and others). Understanding
how services daemonize and how they log. Learning how packaging systems work,
how to build a new package, and how to install it. Learning what can be
read/detected about the system and what does this information mean. Learning
how does the networking work (address configuration, resolver, routing,
firewall, packet inspection). Traditional networking helpers, along with
several protocols carried out by hand. NSS and PAM, and how the accounts work.
And many, many more basic things.
I've never seen anybody understanding the basics, who would have any trouble
picking up anything that was a fad in the last ten years from its
documentation directly. On the other hand, I've seen Docker or Ansible
fanboys that couldn't unify accounts across dozen servers in a sensible way,
despite their "modern automation" tools.
And screencasts are the second most useless way of conveying technical
material (the top one being podcasts). You can't skim through the material,
you can't search it, you can't copy-paste it, you can't print its fragments,
it's inherently hard to navigate.
I share your sentiment that there are way too many copy-paste "devops" people in the industry these days; I always thought the idea was to hire people with both sysadmin and coding skills, yet a perplexingly high proportion of people I interact with these days have neither. I'd never choose to hire somebody who can't describe a tcp handshake, explain what epoll_wait() does or whiteboard a hashtable, but that's the state of our industry (and, probably, why those of us who can are in such high demand...)
Nonetheless, it seems silly to complain about a lack of knowledge and then complain about somebody trying to share knowledge. I've definitely wanted to lock coworkers in a room with a copy of _The_Linux_Programming_Interface_ before, but maybe a video series on similar topics would be better-received.
> And screencasts are the second most useless way of conveying technical material (the top one being podcasts). You can't skim through the material, you can't search it, you can't copy-paste it, you can't print its fragments, it's inherently hard to navigate.
I've learned a huge amount from screencasts such as destroyallsoftware.com, so I think we can agree to disagree on this point. Additionally, I think the success of Codeschool, Code Academy, Pluralsight etc. show that I'm not really in the minority here.
A number of points you mention are possible topics. Although I can't think of a single situation where "understanding several compilers" would have helped me design/maintain/troubleshoot infrastructure I'm responsible for.
But hey, looks like you're not in my target market, and that's ok!
> [...] I can't think of a single situation where "understanding several compilers" would have helped me design/maintain/troubleshoot infrastructure I'm responsible for.
Oh, sure, you don't need to understand how ELF binaries work, until you try to
do anything non-trivial to them (building chroot image anyone?). You also
don't need to know how Ruby or Python work with modules, but I'll want to stay
away from any your system where you happen to install a random recently
developed software, because it will be a mess.
> But hey, looks like you're not in my target market, and that's ok!
Of course I'm not. What you proposed is a list for novice sysadmins,
except it doesn't touch the essence of the craft, focusing instead on shiny
bells and whistles of limited applicability that will be obsolete five years
from now.
I've never seen anybody understanding the basics, who would have any trouble picking up anything that was a fad in the last ten years from its documentation directly. On the other hand, I've seen Docker or Ansible fanboys that couldn't unify accounts across dozen servers in a sensible way, despite their "modern automation" tools.
And screencasts are the second most useless way of conveying technical material (the top one being podcasts). You can't skim through the material, you can't search it, you can't copy-paste it, you can't print its fragments, it's inherently hard to navigate.