Re: [SAGE] Complexity of sysadmin scripts/programs in your organization?

["Steve Simmons" <steve.c.simmons@xxxxxxxxx>]

There's no clean line anywhere on this, just as there's no clean line
between where on is a systems administrator and a systems programmer.
I don't normally consider myself a system programmer, but having
trained and worked as a programmer I bring a distinctly different
touch to my scripting once it gets beyond a few lines.

Sysadmins here (University of Michigan) are allowed to do as much
programming as they think appropriate for their jobs and skill sets.
For some, that means essentially zero. For others, it's just a few
lines here and there. For me it can go thousands of lines.

One outgrowth of this is that the better coders tend to do work for
the less code-oriented. We all cross-train, we can all do each others'
jobs in a pinch. That means the more skilled coders often
spontaneously write scripts for the less skilled as we see things that
are cumbersome or error-prone or simply more automeatable.

Let me give you an example. We have one guy here who's a paragon of
reliability and consistency. He's the guy who gets all the boring
fiddly detail tasks. He doesn't have a deep understanding of
computers, but he can push the buttons and pull the levers perfectly.
Essentially, he is a system administration technician. Got 100
slightly different installations to do, customized per each user? He's
the man.

But he can't script his way out of a paper bag. He doesn't generalize
well. So when I notice something he's doing repetitively (usually when
I'm filling in for him) I write him a script. It takes me a few
minutes; it would take him days. All in all, it works out. And IMHO,
that's the way it should be. We have a dynamic and flexible
organization; skills get applied where they're needed.

We do have one guy in the group whose primary responsibility is as a
programmer, but he and I are probably on a par in skill set. I'm
better at sysadmin than he is, so I do the systems architecture and
day to day ops while he writes/debugs/extends C code. Again, skills
applied as needed.

This kind of tradeoff is pretty typical for our group (about 10
people). Breadth of skills, push them at the right problems, be
flexible, but know a bit of what everyone else is doing.

As for languages - my primaries are perl, sh (bash) and C. I can get
things done in tcl and python, and can usually debug simple
build/compile problems in other languages. I push our guys towards
bash and perl, but python is becoming a higher runner due to a recent
arrival with mondo python skills.