Why admins should know how to code

We’ve all been on the receiving end of that essentially unanswerable question, “What do you do?” I usually answer, “I work in computers,” just to see where the questioner’s mental association goes. I often get responses like, “Oh, you make websites?” or “Oh, you mean like you are a programmer?” or the dreaded “Oh really? Can you fix my laptop? It’s been doing this strange thing where blah blah blah.”

Strictly speaking, I have written many Web applications, but I’m not necessarily a Web developer. I’ve written hundreds of thousands of lines of code over the years, but I don’t consider myself a programmer. My answer to that programmer question is usually, “I develop elegant solutions to difficult problems.” That’s the most accurate portrayal of what I do day to day without getting mired in specifics that would be lost on most folks.

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. I can sense my brain reorganizing to fit the language I’m using to write that tool. It’s a bit eerie.

Tools of the trade

Bottom line: Admins need to be at least passable with some sort of scripting language for their chosen platform; ideally, they should be familiar with several. They may be VB and PowerShell on Windows or Bash and Perl on *nix. These are the pathways that open up all kinds of possibilities for problem resolution and the aforementioned elegant solutions. Not that you’re going to embark on massive projects running into tens of thousands of lines (though that can happen) — most of the programs you write will be surprisingly short.

I did a quick check on a network monitoring server I’ve been maintaining for a while now and calculated just the Perl scripts that I’ve written to support various services and packages on that box, from Nagios to Cacti and back again. It came out to around 15,000 lines of code across 53 scripts. That’s an average of 283 lines of code per script. Further inspection showed that three scripts alone accounted for more than 5,000 lines, skewing the average. There were a dozen scripts that were only 30 to 40 lines. This is the nature of IT admin coding: crafting small, critical tools that hold everything else together.

Take, for instance, a set of Perl scripts I wrote eons ago, when there was no good way to track FLEXlm licensing across an enterprise. This was well before there were any third-party monitoring tools for FLEXlm, and the commercial license monitoring apps weren’t cutting it.

So, in 109 lines, I wrote a polling daemon in Perl that would query each lmgrd (license manager daemon) instance and determine the number of licenses in use per feature, how many licenses were available per feature, and the license expiration date. The script would store this data in shared memory space as a Perl hash. Then a companion script that was only 34 lines long could be called at any time, by any other process, to evaluate the licenses in use and each package’s proximity to the license limit. This script was used to produce Nagios plug-ins that warned when licenses were close to expiration and to populate RRDs for Cacti to graph that data.

Further, I attached a Web app to the same data that allowed developers to quickly check the license status of any of dozens of tools and to see exactly who was using them so that they could ask for a license release if necessary. All of that stemmed from 144 lines of Perl, and the extended apps and plug-ins were only perhaps 300 lines combined.

Peace of mind in 100 lines

That’s the kind of coding that admins should be able to summon when necessary. 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. Insanity may be a foregone conclusion for many who do exactly that, but while I find Perl, PHP, and even Bash scripting to be absolutely crucial to my normal working environment, I see them as scalpels, saws, and hammers, not the primary focus of my mental efforts.

To be sure, this handyman approach means you won’t necessarily become a coding virtuoso in any of these languages. It’s clearly important to write tight, secure code, but it’s certain that heavy hitters can quickly point out better and cleaner ways to do many operations within that code. That’s OK for the most part, as long as the script gets the job done without becoming its own problem.

I firmly believe the foundations of a good Windows or Linux admin start with a clear understanding of scripting and how to leverage that skill. If you limit yourself to working within the confines of code given to you, you’ll find many problems seem to have no answer other than to purchase more software. Even then, that may not fully address the issue. The ability to roll your own is simply integral to the process.

This story, “Why admins should know how to code,” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.