Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming IT

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.'"
This discussion has been archived. No new comments can be posted.

System Admins Should Know How To Code

Comments Filter:
  • by boundary ( 1226600 ) on Monday October 22, 2012 @07:47PM (#41735301)
    As an IT manager, I don't want my sysadmins to code. I want my coders to code. I want my testers to test. And I want my sysadmins to...ermmm...admin the sys. Mixing roles & responsibilities can be really dangerous, especially when there's a strict development and deployment lifecycle in place (and if there isn't you're living in uncontrolled chaos), including change management and release management, that must be gone through properly. Uncontrolled changes, with sysadmins using production systems like they're test environments, is a bad idea and will end in tears.
  • Re:Not only admins (Score:5, Interesting)

    by Mr2cents ( 323101 ) on Monday October 22, 2012 @07:48PM (#41735309)

    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.

  • by Mr2cents ( 323101 ) on Monday October 22, 2012 @08:05PM (#41735461)

    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)

    by scubamage ( 727538 ) on Monday October 22, 2012 @08:32PM (#41735691)
    I'm a systems engineer for a fortune 500, and I spend a significant amount of time developing. Now, am I making fancy OOP code using an IDE? Nope, not really. I am however making python/perl/awk/expect/tcl/shell scripts with a heck of a lot of frequency. I don't think I could do my job effectively if I didn't.
  • by scubamage ( 727538 ) on Monday October 22, 2012 @08:42PM (#41735779)
    Exactly - it comes down to a matter of cost very often. If you can spend a half hour throwing together a script to make a configuration change across, say, 2000 devices (or in our case, several million), it is far cheaper than trying to find a vendor solution, or having folks go out and do the work themselves. The vendor will often have maintenance fees and high initial costs for a tool that "sort of" does what you want. You can have people go out and pound pavement, but if you have 2000 devices and send out 50 people, and it takes each person 20 minutes to do the work on the device plus 30 minutes trave time, times 17$ an hour... well, that adds up fast too. Not to mention the opportunity cost and backlog of tickets that that would generate.
  • by JakFrost ( 139885 ) on Monday October 22, 2012 @09:59PM (#41736449)

    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
    - 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 & .NET FrameWork, Activator, Marshall, Reflection, COM+, Jobs, Runspaces Guy
    $ The Visual Studio C, C++, .NET, API, SDK, MSDN, Compiler, Remote Debugger, Memory Dump Analyzer Guy
    $ Kernel Developer

  • by hawguy ( 1600213 ) on Monday October 22, 2012 @10:08PM (#41736489)

    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.

  • by Crosshair84 ( 2598247 ) on Monday October 22, 2012 @11:10PM (#41736893)
    This is why so many small businesses,like the one I work for, can run rings around larger firms..The boss/owner started the company. He was the one running cable for many years, while he doesn't understand a lot of the newer stuff as well as me or my co-worker does, he understands it more than enough to understand what we are saying.and why we are saying it. He owns the business outright, he is in it for the long haul and wants things built properly.

    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)

    by account_deleted ( 4530225 ) on Tuesday October 23, 2012 @01:22AM (#41737807)
    Comment removed based on user account deletion
  • by White Shade ( 57215 ) on Tuesday October 23, 2012 @01:44AM (#41737947)

    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.

"Life is a garment we continuously alter, but which never seems to fit." -- David McCord

Working...