in reply to Why I hate Perl (discussion)
Preface: The following isn't personal, dep. Your node just happened to tread very heavily on a very sore toe right now and what follows may seem inflammatory. It isn't meant that way. Please read generally when you think I'm getting personal.
I agree with your sentiment that everyone needs to be responsible for making sure they're doing the right things, for using the most idiomatic approaches available, and for learning as much as possible as the tools they're working with. However, I think you may be overstepping things a bit by not acknowledging your part of the process. As a SysAdmin, it's your job to help ensure that the developers have the information available and to help make certain they know how to obtain the information they need.
One of the most frustrating things I'm going through right involves a set of unknown network admins who are clearly ignoring the advice and tips I'm trying to give them. I've built this very simple file-upload/email script and very carefully tested on my server before submitting it for production. It uses CGI.pm, MIME::Lite, and a few other CPAN modules. As one might expect, these modules weren't installed on the target server. Now, I'm not certain how familiar you are with MIME::Lite, but it requires a lot of modules itself.
While MIME::Lite is now installed, I've had to physically request each module it depends on. Why? Because the admins on that server either don't know or refuse to use the CPAN module. I've tried to be as helpful as I can, sending diplomatically worded instructions for using perl -MCPAN -e "install MIME::Lite" to install MIME::Lite. I know these instructions are being passed on to the Admins in question...yet, they insist on installing things by hand.
How do I know they're doing this? Because CPAN.pm automaticaly detects and installs dependent modules. If they'd installed MIME::Lite using -MCPAN, I wouldn't have to request the dependent modules; they'd already be there.
I don't know why they're doing this. But I suspect it's because they don't think a lowly software developer is smart enough to take the time to find a community like the Monastery, to learn basic Unix skills, to understand enough about their job to provide useful suggestions (including recommended permissions and file locations).
In other words, they've copped an attitude because I'm not part of their club.
If that's what happened with the folks that I have to deal with, then I find that unprofessional and inexcusable.
What does this have to do with you? Haven't you copped an attitude of your own?
You're right; it is my job not to cast blame inappropriately and to take responsibility for my code. However, it's your job (as Tilly, Ovid, Masem, et al) have suggested, to take the time to review what the developers have given you, to provide good (and complete) answers when asked, and to prompt for additional information when you think there are questions that aren't being asked.
Furthermore, it's your job to foster a spirit of teamwork in your organization. If you do not have a "team ethic" in place and you wish one existed, it's your responsibility to start one. Start by setting aside the advocacy. Some people know and like Unix, others know and live with Windows. Cope. This is business, not religion.
Consider spending time with your software developers. Ask them what their frustrations are. Ask if there's anything you can do to make their work easier. Do this often enough, they'll start learning and--through your example--responding in kind. It does work; I've seen it happen.
On the other hand, if you cop a superior attitude, your co-workers will start avoiding you. They'll start thinking you're incompetent and they'll start thinking you're an intolerable jerk.
I don't really care if you like Perl, but I do care when you make asinine (and unfounded) assumptions about me, my skills, or my potential. We're all part of the same team, which means each of our efforts are directed toward getting the job done, typically for profit. So stop wasting your company's money by bemoaning the lack of cooperation. Instead, take control of the situation...initiate change. Consider software developers as colleagues and start treating them like people.
I freely confess that I don't know Unix very well. However, I can learn it and am slowly learning it. I'm having to fumble my way in the dark because I don't have people (outside the Monastery) that I can use as mentors. I can read all I want, but books rarely cover real world scenarios. Man pages are fine, but many are either poorly written or so detailed that those missing the basic education get lost in the details. I'd happily work with a NetAdmin to learn this stuff--if I could find one that's civil enough to give me the time of day.
Also, FOLLOW UP. If you find that a problem was caused by a mistake in the code, then diplomatically report that back to the developer in a kind way, one that doesn't start with "You stupid jerk."
And, yes, my "script" uses strict, -w, and -T. Give me enough of a break to know what I don't, to accept my limitations, and to ask questions that, while basic to you, are important for me. Furthermore, give me enough of a break to be able to learn what I need to do a good job. If I make a mistake and you find it, I want you to tell me--preferably without rancor, antagonism, or oneupmanship. We're all working toward the sames goals, helping the project, team, and/or company/organization succeed.