System Admins Should Know How To Code
snydeq writes "You don't need to be a programmer, but you'll solve harder problems faster if you can write your own code, writes Paul Venezia. 'The fact is, while we may know several programming languages to varying degrees, most IT ninjas aren't developers, per se. I've put in weeks and months of work on various large coding projects, but that's certainly not how I spend most of my time. Frankly, I don't think I could just write code day in and day out, but when I need to develop a tool to deal with a random problem, I dive right in. ... It's not a vocation, and it's not a clear focus of the job, but it's a substantial weapon when tackling many problems. I'm fairly certain that if all I did was write Perl, I'd go insane.'"
Depends what they're administering.
There are plenty of systems that are more closed, and the sysadmin should be spending their time living in the pre-provided frameworks, rather than coding their own.
Many times, it's a matter of learning what is already available for the system, rather than coding your own, lesser quality replacement.
In general, everybody dealing with computers can benefit from a bit of programming knowledge, not only admins. The rule of thumb is: if you're doing a repetitive, braindead job, you're doing it wrong. Computers are built to do exactly that. A small script can automate a lot of work for you, if you have that skill it can help you tremendously.
"It's too bad that stupidity isn't painful." - Anton LaVey
Sometimes I play 'sysadmin'. It winds up as the "this doesn't work, make it work" role. Today it was reading the RFC's to figure out how DSN's are supposed to be returned, writing the java.mailx code to make the developers' app do that, and explaning how SMTP works. Other times it's working through a SQL query planner, finding why packets are headed in the wrong direction, re-doing an architecture, etc. It's not possible to do the job well without good CS training, a solid background in coding, a solid background in networking, and just plain blood, sweat, and tears.
Then again, you could study for a test exam in 21 days and call yourself a sysadmin too. It's always the definitions.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Experience has told me something about automated batching of config changes which your 'senior' admin should've known as well. This is crucial:
DEPLOY IN (SEQUENTIAL) PHASES. I don't care if you tested it in one situation or 5: if you've got 50 different situations, you need to 'test' it in each of those unless you know those different situations are in fact the same situation. This means a longer deployment, but you need to test ad verify everything, especially something infrastructural. It will take longer, but it's inerrantly necessary.
Not only does it reduce the outage potential, but it allows you to more quickly back out of it. Sure, it's not as lazy as deploying everywhere at once after a couple quick tests, but it's more foolproof than having half a dozen people look at your changes. Yes, having a second set of eyes is important, but its mostly pointless if they don't fully understand what they're looking - that's why they're the junior, after all.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers