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.'"

Comments

Very true, for many reasons.

[uCallHimDrJ0NES]

People who've never coded tend to have many "magic boxes" in their thinking about systems. I find it hard to fully trust an administrator who can't at least parse through other people's code.

Re:Very true, for many reasons.

[bolthole]

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.

Re:Very true, for many reasons.

[pinfall]

I don't code a lick after 15 years of sysadmin. I do solve incredibly interesting problems with hardware and that ability alone provides a serious interface to all those 'needs software' perspectives. All of my best friends are coders, we just solve problems differently.

Re:Very true, for many reasons.

[hairyfeet]

The problem is the way corps shit all over IT they'll just go "Hey, one more job we can dump on them without raising their pay!" and that will be that.

Lets face it folks, we are gonna end up with critical shortages of IT and infrastructure workers because between the offshoring, the H1-Bs, and the PHBs treating IT as this money pit that doesn't give them any profits? IT has been shat upon for the good part of the last decade.

I know myself and most of the old guard guys I knew ended up getting out of corporate IT for just this reason, piling more and more work upon us while expecting everything to be done with less help and a shrinking budget...now you want to add coding to the requirements? You gonna add a pay raise and pay for the classes? Yeah, thought not.

Re:Very true, for many reasons.

[countach74]

I think you missed the point. The coding helps save you time in the long run. Not the other way around.

Re:Very true, for many reasons.

[Mr2cents]

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:Very true, for many reasons.

[fsck1nhippies]

2Cents, you are absolutely right. Even in windows systems, a basic understanding of what can be done with code can stop 5 people from running around to a couple hundred machines each.

Should the sysadmin be a programmer? Not in the conventional sense, but they should be able to programmatically attack the problems placed before them before they just brute force their way through them.

Re:Very true, for many reasons.

[karnal]

I have coded in the past using Perl to give us some reporting ability from some non network-connected (think no email/notification ability) phone switches. They had relay outputs that would trigger on an alarm; so we used a box to generate a trap that would fire up my perl script to send out emails to whomever was in the config. I don't know a lot - I mostly use bits and pieces of code found around the web and customized to purpose. I initially thought I wanted to code for a living, but found in my first job that politics trump the technical, and boy were the politics thick. I do more security/administration nowadays, but still draw on the basic coding ability to create automated notifications for anything non-standardized. Really what I'm trying to say here is sometimes the basic experience of coding as well as a need to fulfill a solution that doesn't have a canned solution readily available can push you to do some interesting things.

Re:Very true, for many reasons.

[karnal]

And - sorry about the lack of line breaks there.

Re:Very true, for many reasons.

[scubamage]

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.

Re:Very true, for many reasons.

[fsck1nhippies]

I see a lot of admins in very large companies throw labor at a problem as their first course of action. It is typically a face palm moment for me as I often see the problems as fixable in minutes. I believe that all sysadmins should be able to program, but think that making a programmer a sysadmin is generally a bad idea.

Re:Very true, for many reasons.

[hawguy]

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.

[Crosshair84]

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.

Re:Very true, for many reasons.

[CAIMLAS]

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.

Re:Very true, for many reasons.

[hairyfeet]

Dude don't be fucking silly. yes I know the sonicwalls aren't Cisco but you sure as fuck can't say that those shitty $30 blue dlink specials are the same as a 24 port sonicwall, there is NO comparison. Like I said it wasn't because this moron thought the Dlink was just as good, it was because he had never done jack shit but home installs and didn't know his ass from a 7/11 when it came to pro gear.

And look I got NO problem with "Tigerdirect specials" as i make my bread and butter off the boxes..but I would NEVER EVER try to set up a business on those, not unless they gave me enough to set up the whole office AND have some spares in case one goes down...why? Its the drivers dude, trying to support a mish mashed mess of hardware where no damned driver matches is a royal PITA to admin, and this guy had dribbed and drabbed the place. The worst part? He built them fucking OCed from the factory "gamer specials!", my guess is because he wanted one for himself and just added it to the bill, but fuck! You wanna talk about some seriously fucked up issues! Why don't YOU try dealing with over 30 OCed from the factory unstable messes, where even the RAM timings are aggressively OCed! And this was for a fricking law firm, not some gaming place, yet every damned system had gamer cards!

Sure even if you don't like the sonicwalls you can see that situation was a clusterfuck from hell. Frankly they only gave a shit about his lowball price and never once stopped to ask "Why is he cheaper than the other guys?" and the reason he was cheaper was he didn't know shit, he was some "gamer guy" pretending like he knew enough to do corporate. I mean picture trying to track down a networking issue only to open up the closet and find more than a dozen of those damned blue dlink 4 port jobs with half a dozen ISPs and not a damned thing labeled? We had to shitcan the whole place and start over, it was just too big a mess to untangle and fix.

And not to rain on YOUR parade but unless you live in one of the major metro areas Apple sucks big hairy balls. I get to deal with a doctor tomorrow who has been to Apple's genius bar more than a dozen times with networking issues, all they do is reload the OS and apply the patches and hand it back, needless to say that don't fix shit. At least if he had Dell or HP under contract he could get an actual tech out there to work on the problem on site, but since Apple don't do that I'm gonna have to try to fumble my way around an OS I've avoided like an STD because frankly nobody else will even try, he says Apple and they say "fuck that proprietary crap, we won't touch it" and then they try to sell him a new system. I'm at least willing to try, which is more than he's gotten from Apple.

Re:Very true, for many reasons.

[White Shade]

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.

Re:Very true, for many reasons.

[LongearedBat]

make a configuration change across, say, 2000 devices (or in our case, several million)

Running a bot net, are ya?

Re:Very true, for many reasons.

[dropadrop]

I work in a multinational company with an IT department of about 120 people (about 5500 total employees). We have maybe 10 people that write code. Why on earth would anyone labeled as a system administrator have to write code? What am I doing maintaining multiple SANs, ESX farms, MS clusters, Cisco switches, routers, VPN, and firewalls that I should know how to code?

The 10 people have that write code do exactly that. Write code and build applications. I would not expect them to have a working knowledge of setup routing our WAN, they should not expect me to code an application.

Sounds like a multinational corporation :)

I've done everything you are doing, but still occasionally needed to write code. Maybe you have a database and instead of purchasing an expensive license to be able to get clean backups you write a script which puts it in a clean state, connects to the SAN, takes a snapshot of the LUN, mounts that snapshot so you have a clean backup. Maybe you are using SNMP to monitor servers and need to get information on some service (active dhcp leases for example). Maybe you need to periodically clean old files from somewhere that fill certain requirements etc...

Most of these examples can also be solved by throwing money at it, but if I was hiring somebody I'd rather take a person who also has the ability to solve problems with sense and in a hurry. It could be the difference between a team having 5 people to maintain 100 servers or 5 people to maintain 5000 servers.

Re:Very true, for many reasons.

[Anonymous Coward]

2Cents, you are absolutely right. Even in windows systems, a basic understanding of what can be done with code can stop 5 people from running around to a couple hundred machines each.

Should the sysadmin be a programmer? Not in the conventional sense, but they should be able to programmatically attack the problems placed before them before they just brute force their way through them.

The "sysadmin" can be anything from a guy who runs a single mail server, to someone who has to deal with thousands of remote workstations. There's no hard and fast definition for what exactly a "system admin" actually is. This entire discussion is just a collection of people assuming that every other "sysadmin" has the exact same job environment, the same duties, and the same problems. Nothing could be further from the truth. So the answer to the submission is "Define what you mean and you might get a decent answer".

I've seen sysadmins who simply have no need to ever code or script anything, and others who need to do it all the time. I've seen sysadmins who will spend an hour coding and save a week's worth of work, and I've seen sysadmins who will spend a week coding to save 5 minutes work.
Do you need to know how to code? It ALL DEPENDS on the job you're given. Usually it will be of benefit, but it's not always required.

Re:Very true, for many reasons.

[hairyfish]

I never trust a plumber who can't wire up a fuse box either. Same goes for a doctor that can't practice law. Fuck specialist skills, everyone should know everything

Re:Very true, for many reasons.

[Chris Mattern]

You missed the OP's point. The point isn't that you'll necessarily be coded for the system you have. The point is that knowing how to code provides critical understanding of how a computer operates that a sysadmin needs regardless of whether or not he's actually coding.

Coders should know how to admin

[Anonymous Coward]

...and support for that matter.

Re:Coders should know how to admin

[scubamage]

Agreed. Several companies I have worked for have had coders who couldn't care less about the fineries of system administration. All they care about is having a nice development environment and a working svn/git where they can store their code. They couldn't care less how the infrastructure behind it works.

Sure thing

[Anonymous Coward]

Next you'll tell me my developers should know how to admin a server and do so at a drop of a hat.

Sure

[xaoslaad]

And if you're going to say I'm a programmer then pay me like one. I don't think most sysadmins get paid as much as programmers, and I don't think most companies want to pay sysadmins as much as developers.

Also, developers trying to write tools for sysadmins usually suck at it, unless they've been a sysadmin at some time in the past. I have used a few products lately which are trying to solve all our sysadmin problems, and the one that doesn't suck comes from a dev who is a former sysadmin. And when I talk to him and make suggestions he sees exactly where I'm coming from.

Developers just want to solve use cases that fit neat little scenarios without any corner cases, and it shows when their tool is so inflexible as to be useless.

Not only admins

[Mr2cents]

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.

Re:Not only admins

[Mr2cents]

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.
Unfortunately, many people are not trained to identify automatable jobs.

Re:Not only admins

[Mr2cents]

You're right. But you could always write a script to flip the axes, might come in handy if you encounter similar graphs ;-).

Re:Not only admins

[scubamage]

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.

Re:Not only admins

[garcia]

Not trained? What? Most people I know realize the tasks they do could be automated. However, they do everything in their power to ensure they aren't because they believe it keeps their relatively mindless and easy job "safe". This mindset is prevalent in the public sector and the unionized public sector especially.

I was able to come in and completely revamp a position I was hired to do to expand it to encompass at least 50x more work with a little Access/VBA and some learned-on-the-job DW knowledge.

They are still running the same exact reports I wrote when I left 5 years ago and haven't added a single one to the mix. Someone has now taken over my position and enters text in the fields the scripts prompt for and passes out the paperwork it automatically prints. It's a sad day for our tax dollars.

Re:Not only admins

[Mr. Freeman]

> Never assume you will live forever, nor work forever for that company.

This is very important. I worked in one place where this one guy was responsible for a bunch of shit. I would often think to myself "if this guy is hit by a bus we'd be fucked for weeks". The guy got sick and was out for a few days. Lo and behold, work ground to a halt until he got back. During this fiasco everyone was saying that we needed to make changes and have redundancy so this doesn't happen again but once this guy came back everyone forgot all about that. I guess people don't care as long as things are working. I tried to bring it up a couple times after that but the only response from everyone was "we don't have time for that, we'll do it later". Oh well, it's their funeral.

Re:Not only admins

[tibit]

I think that these days programming is like being literate. Sure you don't really need to know how to read and write, your secretary can do it for you all day long. It just seems like a big waste of effort to me. For many simple and repetitive things related to their jobs, everyone should be able to whip up a quick script, just like everyone takes notes as needs arise, without calling their secretary on the intercom every time they need to write down a phone number.

Re:Not only admins

[tibit]

The "abomination in VBA" may be so, but it has likely replaced tons of manual labor. When it outgrows the original author's skills, then there's no reason not to do a proper reimplementation. Yet all those abominations, usually, make their authors more productive. That's their goal. Scoffing at that is going full retard.

Another skill we will only get underpaid for

[NetNinja]

The ammount of skills Network admins should know and still get paid a 10th of what we are worth is ridiculous.

I should be making close to 300k a year, Do you think any company would pay that?

So now I need to add codder to the resume which will effectively fall on my shoulders to maintain code? Bad idea.

I guess I should be happy and count my lucky stars that I have a job?

The one thing I have noticed in companies that Sales weasels get paid a lot more money than I and the responsibility lies on the network admin to keep it all running.

Perl

[slapout]

So, does Perl drive you crazy or do you have to be crazy to program in Perl?

Re:Perl

[toygeek]

Yes.

Re:Perl

[grouchomarxist]

Having to document code is a code smell. Documentation is something that can easily fall out of sync with the source. It is best to program in a fashion that doesn't require documentation, if possible.

Re:Perl

[scubamage]

I disagree - if documentation is falling out of sync with the code, then whoever is writing the code isn't doing their job properly.

Is this what any programmer does?

[PeanutButterBreath]

I'm fairly certain that if all I did was write Perl, I'd go insane.

As a programmer, to me this is like someone equating author and typist. Code is just a medium. Figuring out what to do with it, and how, is the fun part.

Remember the judge?

[michael_rendier]

I remember the judge... http://lazytechguys.com/news/business/judge-for-google-and-oracle-case-is-also-a-programmer/

Unfortunately

[sackofdonuts]

Many IT professionals called systems administrators have no idea how to code. They basically perform the strict description of systems administration activities. But those who can code tend to be the better sys. admins. and usually end up directing those who do not know how to code. Coding is one of many tools a proficient sys. admin. has. Another is problem solving skills. Believe it or not there are systems administrators out there that can actually solve a problem without calling the vendor.

Re:Two different worlds

[countach74]

But the sysadmin's job is to support the code and OS, not figure out what is wrong with the code when things break.

Strawman's argument. The article clearly is talking about using programming/scripts to facilitate the system administration jobs, which is a no brainer. It does not say to be a developer and hack in some change to a large app to fix an issue. Or perhaps I missed that part?

Sounds like a plan!

[Lumpy]

You doubling my salary for that extra work? I'm tired of the constant scope creep people keep shoveling in without an increase in compensation.

Re:Sounds like a plan!

[PeanutButterBreath]

Don't you see? Knowing how to code will make you more efficient. So, if anything, the amount of, er, whatever it is that you people do, can be increased!

Yes, early adopters will be able to demand a higher salary for any additional skills that they bring to the table. That is, until we can update our job requirements to include these skills (5 years minimum).

Re:Sounds like a plan!

[PPH]

Monkeys get time and a half for overtime. Professionals work on salary.

Sure so long as coders l2sysadmin

[Sycraft-fu]

Then maybe I wouldn't spend an inordinate amount of time fighting with programs that can't understand how to run as a deprivileged user, that can't properly set up their own environment variables and so on.

So I'll promise to learn to program if they'll learn to sysadmin. Since I already know how to program then they'd better get on it.

Corollary: All IT People Should Have to Do It All

[Motard]

I've worked in companies ranging from 5 people to 40,000 (and plenty in between). In the smaller shops I've had to do administration, development, desktop, and customer support. In the larger 'enterprise' shops, I'm constantly amused by the myriad breakdowns in communications caused by folks being incapable of putting themselves in the shoes of their coworkers.

Being a developer made me a better system administrator. Being an admin made me a better developer. Same with operations, support, et. al.

Depends on the Job Definition

[bill_mcgonigle]

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.

Ah, age.

[Anonymous Coward]

At one point, we *had* to code. Tools didn't exist until we made them. Or at least tools that did what *we* wanted didn't exist until we made them.

I blame Windows weenies for the loss of this skill. They cannot function without pre-packaged clicky things. Nitwits.

If all I did was write Perl

[Seumas]

I'm fairly certain that if all I did was write Perl, I'd go insane

And that's the point when you officially become a perl hacker.

Coders Should Know How To Sysadmin

[MisterP]

I don't think anyone could argue that having skills in both areas isn't a good thing. I've been a sysadmin for 20 years and i've had to do basic development over the years (apache modules, ldap-ifying applications, etc). When it comes to troubleshooting complex problems as a sysadmin and the whole team is whiteboarding, you can tell pretty quickly who understands how systems work below the user interface. This is often only learned through writing code.

The opposite is true for coders too. With a few execeptions, the most competent developers I've worked with have had sysadmin duties at some point in their career. Not that long ago, I had to sit down with a Sr. (Java) developer and explain load balancers and TCP session state.

It's the mindset that matters

[dbIII]

A lot of the time you don't want developers administrating other people's gear since you get shit like unnecessary reboots of servers during peak working hours leaving 300 people with nothing to do apart from read newspapers (one memorable example). It's not skills that separate a good developers from a good sysadmin but instead a consideration of inter-related systems and caring about consequences of actions.

Re:It's not all about the code

[aXis100]

Wow..... just wow. As an IT Manager you have failed to grasp the concept of this article, and that is a worry.

They are not talking about sysadmins writing production code - they are talking about using one of a variety of scripting languages to solve sysadmin problems - eg repetitive tasks like backups, deployment scripts etc, maybe even some html status monitoring screens or a cactus plugin.

Maybe

[asmkm22]

I don't know about full-blown compiled coding or anything, but sysadmins definitely should have a grasp of a scripting language relevant to their environment (such as vbscript for windows). There are too many times you get requests for stuff that inexplicably have no official support for, such setting up a default Outlook signature for all users that pulls information from their login profile. The sysadmin who can say "give me 30 minutes minutes and I'll have it ready for testing" will look a lot better than the sysadmin who says "we could buy an $800 program that will allow us to do that, but we'll still have to test it out."

This just in...

[epp_b]

Experience in one field can be an asset in another due to inherent interdependent qualities! Wow!

But as many others here have pointed out, the last thing businesses need is another job to dump on the IT department while continuing to tighten their budget (because, hey, computers are just computers, if you know about them, you know everything about them, right?)

Re:OO

[scubamage]

Psh, real men use goto statements.

Re:It's not all about the code

[boundary]

You have failed to grasp that *anything* that could influence correct operation of a production environment, even a little 'harmless' script that manipulates production systems and/or their data, needs to be managed correctly, assessed for impact (by someone other than the guy that wrote it), tested properly and deployed carefully. Risks to production need to be managed, and the biggest risk I know is a sysadmin with a god complex and a hobby in scripting.

Re:It's not all about the code

[boundary]

The sysadmin is one member of a team. The article's talking about 15000 lines of code, which isn't a small amount. That's dangerous territory for sysadmins to get into. Do they understand design for performance, security, error checking, maintainability, corner cases? Have they done the right analysis? Are they solving the right problem? Do they understand how to test? These are not rudimentary skills, even though people think they are. The likelihood is that they haven't done enough to get past the company's (not my) Change Management/Release Management process (which is a fact of life in most organisations that have any level of sophistication) and the coders will be able to do it better, faster and get it through first time. So the total cost of ownership is what I'm looking at, it's not just about solving an immediate problem - it's also about how much effort it will take in future to keep that problem solved.

Those who can and those who can't.

[JakFrost]

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

Re:It's not all about the code

[PPH]

There's a difference between knowing how to code and doing it outside of established processes. The knowledge enhances the admin's ability by giving them a big picture view of the product life cycle. The same holds true the other way around (coders understanding admin tasks).

If the only way you can keep your employees from mucking about outside of established procedures is to hire those who don't know anything beyond their job description, you've lost control of your people.

I've worked at employers who insisted on hiring "technological savants" (a term coined by Scott Adams to describe employees totally unskilled outside of their narrow field). What you end up with is trained monkeys. People with no interest or motivation to improve themselves, their jobs or their products.

Re:It's not all about the code

[PPH]

So, you are willing to accept an admin task performed manually, mistake creepage and all. With 500 workstations, there's no guarantee that the last one will be configured the same as the first. After the first few dozen, fat finger mistakes will undoubtedly creep in. By number 400, your admin won't be seeing straight anymore.

When we say "admins need to understand coding" this includes all of the associated issues of testing and configuration control. Perhaps not to the same level of detail as the code for the product. But in some cases, it can come pretty close.

I'd much rather have my admins script everything. And save the script. So when we come running in and ask, "What the **** did you do??!!", they have the exact steps in hand.

Re:It's not all about the code

[PPH]

scripts need to be developed carefully, within a process, and there's better people to do them than sysadmins alone.

So, who do you suggest write the scripts? And how do you get the domain knowledge and requirements from the system administrators to these script coders?

Just have the Unix team do it

[shuz]

I've found that what can happen in the large corporate world is that you have Developer teams, Production run teams, various IT infrastructure teams, and the Systems Engineers. Networking gets blamed for every outage because well, they are the common thread that all the bits run over. Storage gets stressed out because it is the last thing anyone thinks about until they need it, and the Systems engineers well the Developers want to play all roles unless they don't want to. Production run sometimes lacks the deeper skills of either programming or IT infrastructure.

Enter Unix Engineers. We are expected to have general knowledge of all IT infrastructure, which we do, we program and script extensively, because our automation depends on it, and we have extensive production application run experience do to managing all the different back end services that everyone depends on. mail, dns, ftp, sftp, web server engines, monitoring, etc. Yes a good sys admin must know how to at least read code and ought to be able to code/script in at least one language even if that is Dos Batch. The problem in the end though is as others point out. The more you know the more production run teams may lean on you to solve their problems. "Just ask the Unix team", Not because it is their responsibility, but because they can solve the problem quickly as they have the widest berth of knowledge.

Coding as a Sys Admin is crucial. Just know when to say I can't(or won't), for your sanity.

Re:It's not all about the code

[tibit]

So if a sysadmin does it manually with all the risk of mistakes it entails, that's fine and dandy, but if they dare write code for it, only then it's subject to the holy process? LOL.

Re:Corollary: All IT People Should Have to Do It A

[robot5x]

you're bitter because you solved a problem that was 'above your pay grade'??

Wow, maybe this is what's wrong with the IT industry. Yeah, big corps are complicated and bureaucratic etc etc etc, but if more people actually WANTED to make an effort to do stuff, and worked outside their own defined sphere of influence just to y'know, actually get shit done, then maybe things wouldn't be so bad?

All the discussion here leads me to the conclusion that the key to happiness is as simple as continuing to learn and develop your skills and to occasionally stick your neck out and do whatever it takes to solve the problem.

Re:Corollary: All IT People Should Have to Do It A

[SomeStupidNickName12]

Buddy, this how you get promoted - doing things above your pay grade and making sure management knows about it. You then become the go to guy for management to solve problems. Then during salary/bonus/promotion time if they don't reward you drop them and leave.

Re:Corollary: All IT People Should Have to Do It A

[DigiShaman]

Been working IT for almost 15 years now. The respect is the same then as it is now. You wade through shit to solve a problem, only later to get bitched at for not finding it sooner when in fact you were originally trying to make a case of how pro-active you've been. Oh, and because I've been wading in shit, I smell bad.

There is no respect in IT and the pay sucks. I'm looking to find another career patch that isn't already tainted with disdain. Fuck this, life is too sort. I'm tired of falling on the sword and not getting any recognition for it...for 15 years.