System Admins Should Know How To Code 298
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.'"
It's not all about the code (Score:1, Interesting)
Re:Not only admins (Score:5, Interesting)
PS: YOu don't really need to know how to program, if you can just identify tasks that are braindead and repetitive, that's already a plus. Then you can go and talk to someone who does know how to program, explain the problem, and this person might come up with a simple solution for you. It all boils down to this [imgur.com].
Unfortunately, many people are not trained to identify automatable jobs.
Re:Very true, for many reasons. (Score:5, Interesting)
You don't or you can't? Because even when I'm not coding, just in day-to-day computer use, I often write scripts to batch-process or automate various things. I have found this highly beneficial. I don't want to break you down, I just want to know your reasoning. Personally, I can highly recommend learning scripting, be it bash/awk/php (yes, I wrote php scripts)/powershell/whatever, I'm sure you'll benefit from it.
Re:Not only admins (Score:4, Interesting)
Re:Very true, for many reasons. (Score:5, Interesting)
Those who can and those who can't. (Score:3, Interesting)
In my years as a Windows admin I found it interesting to find out which other admins could or could not write scripts and then classify them by the level of their abilities:
- The GUI clicker Guy .NET FrameWork, Activator, Marshall, Reflection, COM+, Jobs, Runspaces Guy .NET, API, SDK, MSDN, Compiler, Remote Debugger, Memory Dump Analyzer Guy
- The Command Line ipconfig.exe Guy
- The Google for a Script Guy
- The Cut-and-Paste Each Line Separately Guy
- The Excel Drag-and-Fill Guy
- The Search and Replace In a Script Guy
- The Batch Script with No "@echo off" Guy
+ The For loop Guy
+ The Reg.exe Guy
+ The PsExec Guy
+ The 2>&1 Redirect Guy
+ The Pushd/Popd Guy
+ The Setlocal Guy
+ The Rundll32.exe Guy
+ The Findstr.exe RegEx Guy
* The GnuWin32 Sed/Grep/Tee Guy
* The Cygwin Guy
* The Perl Guy
* The VBScript Retarted Syntax Language Guy
* The JScript Cool Web Language Guy
* The Script Signing Certificate Guy
@ The PowerShell Guy
@ The PowerShell & Quest PowerGUI Guy
@ The PowerShell & PowerGUI & 3rd Party Cmdlets Guy
@ The PowerShell & [.NET Framework] Accessing Guy
@ The PowerShell &
$ The Visual Studio C, C++,
$ Kernel Developer
Re:Very true, for many reasons. (Score:5, Interesting)
To be honest, most of my managers have been very nervous about my suggestions to even use tools which I'm knowledgable in because they don't understand the concepts. Ad the bigger the company the more likely they are to want a vendor solution rather than use internal resources.
As a manager, sometimes I see the tool to automate and script changes to be a risk of taking down the network faster than anyone can do anything about it.
Like the time a senior network admin accidentally took down our network by setting the IP address of all of our network switches to the same set of IP address. He tested the script and it worked perfectly on one network closet - then he proceeded to apply the remaining set of IP addresses the the remaining hundred network switches in our organization.
He knew as soon as the first alarm went off what had happened, but by then it was too late to stop it. Fortunately, he had the good sense to not write the config to memory, so recovery just walking to each network closet to power cycle the switches -- much faster than if we had to walk around with a console cable to back out the changes on each switch
That said, he still uses the same tool to push out changes, but he tests his scripts on 2 IDF's before pushing out changes and has the junior network admin double check his work.
But I can see why a manager would be cautious about a new and untested automation tool.
Re:Very true, for many reasons. (Score:4, Interesting)
Several years ago I developed a method to resolder the capacitors on a particular motherboard that we HAD to have, but had the caps with the bad electrolyte. (Nothing fancy, but the board has a few issues that made replacement difficult.) The Mark 1 variant was very ugly, but functional and proved the concept, the Mark 2 variant is what we still do today. When looking at the invoice the boss asked me why I was using capacitors that cost over 75 cents each, I simply pointed to the spec sheet and told him that the ones I bought were rated for 8,000 hours at 105C while the ones that were 10 cents each were rated for 1,000 hours at 80C. He immediately understood and saw how my decision was correct. No need to try to explain cost-benefit to some bean counter. No need to write up some fancy report, just point out the specs and he understands that by going with the expensive caps we will never have to re-solder those caps again and saving us gobs of money in the long term.
Hard drives in our recorders? WD Blacks all the way. Greens are so much cheaper, especially during the shortage, but he never even considered telling us to use cheaper drives and the increased cost was easily factored into our budgets. Contrast that with my brother, who works for a national company. When hard drives skyrocketed, getting them to authorize the funds they needed for hard drives was a monumental task and took several weeks of daily emails and phone calls.
There are many inefficiencies in small companies, however there are many inefficiencies as well that give them an advantage. Despite the government giving the large firms heaps of advantages,many small firms can still compete, though many simply leave the country, some better than others, as we have seen over the last couple decades.
Comment removed (Score:4, Interesting)
Re:Very true, for many reasons. (Score:4, Interesting)
I feel like even if you're not going to be doing any hardcore programming, at least having the mindset to be able to reason out the functional blocks that make something in the computer happen is a huge benefit.
If you know that to do X, you need to do something along the lines of A,B, and C, even if you don't know exactly what A, B and C are , or you don't know how to actually implement it, you're still miles ahead of someone who just doesn't get it.
That was my experience in programming classes in college too... some people just got it and could make things work relatively efficiently within the boundaries of their knowledge, but others just had no idea at all and were always so far of the mark that it was almost a waste of time for them to even try anymore.