Monday, December 14, 2009

on job requirements and resource utilization

If i'm hired as a sysadmin, make me do sysadmin work. Don't make me do programming work.
If i'm hired as a programmer, make me do programmer work. Don't make me do sysadmin work.
Allow me to do either if necessary, but don't task me with something I wasn't hired for.

There's a very logical and simple reason for this. Would you hire a plumber to fix your shower drain and then instruct him to teach a high school English class? It may be possible for him to perform the basic duties of the teacher. But don't expect the kids to make it in to any nice colleges.

Likewise, if you hire a sysadmin and make him take on a programming project you're going to end up with a retarded program. If you really want him to take on a programming project, evaluate him as you would a software developer you were about to hire (because that's what you've just effectively changed his title to). Is this the person i'd want to hire full-time to develop software? Am I confident he is the best person qualified to take on this job? If not, you're barking up the wrong tree.

I'd trust a developer with my system about as far as I could throw them. I think most sysadmins would agree they would rather a developer have less access over a system than more. We've seen the mistakes they make when they don't fully understand the platform they're developing for. The same mistakes are made by sysadmins when developing with a language or framework they don't fully understand, or without the fundamental knowledge of how to develop and maintain software properly.

The job of a "sysadmin/coder" is effectively asking for half a sysadmin, half a programmer (unless you're paying me double the salary). And that's probably what you'd get in the end. We gain experience and strength in our fields by working on them for the majority of our time, not by dabbling here and there and becoming jack of all trades, master of none.

No comments:

Post a Comment