I agree that there are a lot of languages out there, but how many can you say contribute to the core of programming the way that C does? *This* is why it’s being hailed in this article as *essential*, not because it’s the *only*, but because it provides a respectable degree of insight into “what the programmer was thinking”, and therefore “what the problem could be”.

From my experience those with programming-phobic and “not my job” mentalities stick to doing what their peers have always done to fix an issue, and that’s the extent of it. There’s a fundamental drop off of creative problem solving there, and it’s the bane of progress in computing.

That “it’s the developers job”, to me, is more of a “fogey”-ish attitude than someone who can think on their feet and get to debugging a flaw, whether it be JavaScript, C, a BASH script, or whatever other language you can think of. Covering a lack of determination by saying “it’s the vendor’s problem, they’ll fix it” is a cop out. I would even dare to say it’s engendered by the result of dealing with bugs in closed source software, where you are left powerless, and most often don’t have the tools to help fix the issue, or even better, the option to open the source and attempt to debug yourself.

I think arguably the problem is sysadmins don’t pay attention to the libraries / modules they are choosing to use and you end up coming across a perl script using an unmaintained module from CPAN with a mess of dependencies that are a pain to track.

Speaking for myself, I’m a lazy sod, if someone has written a library that will take the pain away, I’ll use it instead. I hate making exec calls. If I have to, I start looking to bash instead of perl/python.

You do for sure need at least a scripting language under your belt, Perl or Python for *nix world, preferably capable in both, and more than that in one of them (the latter sems to be becoming increasingly popular?)

Um, not they don’t. I deal with far too many different applications and services to be proficient in all the languages they were written in. I took basic programming and have a basic understanding and that is more than sufficient to efficiently do my job. The job of a sysadmin has evolved. There are a lot of fogeys here that don’t realize, or willfully ignore, that the job of systems administration has changed from the days where you had a handful of technologies and it made perfect sense to master them all. Those days are long gone.

Also, I became a sysadmin because I didn’t want like being a programmer, and that is OK. Learning to code is not some rite-of-passage for sysadmins and it’s not necessary in most environments anymore. We let the programmers program and we pay them for their support when the code breaks.

Somewhere along the way sysadmins stopped coding probably because they stopped building. The new rule is to use supported packages and not build for source. I got back into coding because when system and application performance becomes an issue sometime all you can do is debug code to find bottlenecks and fix it.

I disagree with “scripting in not coding”. Granted, interpreters and VMs are not great but for most things they are fine.

The state of systems administration is a wreck right now. In the past we looked to Usenix/SAGE to help build best practices and standards. Young admins probably don’t know what Usenix is. We probably need to get back to Usenix.

If you want to start coding that are a ton of orphaned packages at the debian project. Pick a package, ask to support it, and start fixing.

Employers nowadays seem to discourage admins from writing their own utils and would much rather pay big bucks to license products that they only use a small portion of and that could readily be replaced with small in-house developed code.