The word you're looking for is Cocky.

So maybe you didnt use it because you didnt want to be that harsh, or perhaps (as I hope is the case) you didnt use it because you and I are on pretty friendly terms. Maybe it seems like a little too much of a word to put on a thread that was clearly intended to be pros e, and to be discussion. Well...

Youre damn right, Cocky.

I have had an interesting day watching the --'s and ++'s roll in. The post is at a positive rep, but I have lost as many XP as there ar e rep. At a 1/3 chance of a loss, that means I have gotten in the neighborhood of 24 --'s and the same number of ++'s. Gosh, I feel lik e princepawn. So maybe, everyone, pull up a chair and check your egos at the door. I'll happily explain why I'm Right And You're Not (tm).

I'll explain the scenario, and then add qualifications so you all know that I am not just blowing smoke up the collective ass of the mo nastery.

So lets assume a large company has a not very large division. This division is concerned with a large website, which handles a large vo lume of traffic. Lets also say that there are 2 dba's, 2 unix admins, and 2 software developers. For the sake of discussion, everyone i n question is using Solaris -- although the organization also has a slew of Windows boxes.

For some reason, the dba's hate the software developers. For some equally obscure reason, the software developers hate the dba's.

This situation has gotten so out of hand that I was brought in as a consultant to fix some of the problems we've been having between so ftware developers, software testers, and database administrators. Everybody thinks everyone else is at fault for a huge number of probl ems. Namely, the software sucks. It does what it is supposed to do, but is fragile, and static. You touch it, it breaks.

footpad, whose reply to my above node will reply to (if I find the time) separately, makes the excellent comment about administrators unwilling to install modules with CPAN.pm. Well, that is where this particular journey into Dilbertsville begins.

I have developed code the likes of which have simply never been seen at this company. It uses warnings and strict. It uses modules rath er than reinventing every wheel in the book. It doesnt make system, qx, ``, open PROG, "foo|" calls. Its all perl. I am met with sidewa ys looks when I suggest that something is easily fixed with perl because -- even though this is a perl development department -- the pe rl scripts around are causing problems. Theyre fragile, they need human help, and so on. You've all seen stuff like this before and if you havent, youre lucky.

So, when I started writing code that required the module Mail::POP3Client and also the HTML::* modules, I realized that before it was moved from my perl install in my home directory to the development server (mind you this is pre-dev code), that I would have to have modules on the dev server. So I sent the unix guys an email asking for about 12 modules.

This morning, I came in to the first meeting of the day, which was "Why the database sucks in a nutshell." Basically, the database is r eturning errors in a manner that the perl scripts dont like. The users then see errors that arent very explanatory, and they would like that to cease. For complicated reasons, it seems easier to fix the database than to fix perl (does perl seem to you like something tha t is un-easy to fix? me, neither!!).

At this meeting, I learn that "you broke perl on the dev server. X section of the website is DOWN." Well, apart from the fact that I di d not actually touch perl (remember, I'm not root here), I found it preposterous that installing perl modules would break anything. The yre simply not an issue unless you use them.

So after the meeting, I went to go talk to the unix guys. Apparently what has happened is that perl has been upgraded from 5.0053 to 5. 6.1.

Now knowing what the problem is, I went over to the SW guys and asked what the problem was. "Well, the new perl handles data differentl y when youre passing variables." (thats a direct quote!) I explained that I thought this was probably not correct, and sat down to look at the code.

The first thing I did was fix two typos. This could have been avoided entirely by simply using strict and warnings. Do they care? No.

The second thing I did was point out that, no, you're not supposed to invoke a module that way. You need to:

use CGI qw{ :standard };
[download]

if you want the standard stuff out of CGI. I'm not going to go into detail with the rest of this code. What I will tell you is it was h opelessly <!- FUCKED!!!!!!!!!! FUCKED!!!!!!!!!!!!!!!!!!!!!!!!! -> broken. I could not get either of the SW people to explain to me what the problem was, nor could I get them to reproduce it.

My next suggestion was "well, just switch your shebang to #!/usr/local/bin/perl5.003. Fat chance. The fact here, though, i s we have at LEAST five other installs of perl all in separate places, all with their own correctly named binary in /usr/local/bin. If your code requires 5.0053, USE THE CORRECT BINARY!

The admin, bless his heart, went and made the symlink in /usr/local/bin/perl back to /usr/local/bin/perl5.0053, and informed me that sh ould I want to use 5.6.1 that it was there and correctly named.

Now, We have a name for this. When a user comes to me (as an admin) and says "my blah is broken" where "blah" is the name of the progra m that they feel is the center of their existence, I attempt to figure out what the problem is. I go and look around at permissions, lo gs and the like. When a user comes to me and says "you broke my blah", I tend to get a little pissed. If I then go looking and find tha t they are doing some egregiously WRONG and STUPID things, we use this great (if mean) word.

BDU

Yeah. Brain Dead User. You <!- FUCKED UP !!! -> are having a problem, and youre blaming it on something else, because it couldnt possib ly be you. And you know what, software developers can be BDU's.

So, lets get back to my original post.

I think that while my point wasnt subtle, it took a little bit of time for your average user to read it and understand I was not in fac t saying I hate perl. Would I be here if I hated perl? <!- give me a fucking break. -> I think one of the things we overlook when we fi nd somebody who hates perl is that they indeed may have a good reason for it. Maybe you asked them to install a module, and then whined that they broke perl when YOU could have been a more responsible programmer. Maybe they had a bad experience with the world's worst co de (I am convinced that I am dealing with that code now, but I'm sure many of us have horror stories.).

Now, tilly, friend, lets look at what you added as a personal note here.

I'm being rather cocky.

Well, the fact of the matter here is I have got experience and I am a good perl coder. I do pretty good work. I've also been coding in perl for a while. I have been doing perl professionally for almost two years, and coding in it about four. I have not however said that "I am x good perl coder" where x is a quantity above what you think it should be. I have said that what I need to learn to progress as a perl coder I am not finding here. In fact this is true. In order to be a better perl programmer, I need experience.

MeowChow correctly asserts that my code reflects a background that I think many of the monks here simply dont have. We see a lot of m onks with no C knowledge, and certainly no shell background. My code is different -- but it works. It may not be the most perfect algor ithmically, but often times I <!- dont give a fucking shit. not a fucking shit. -> am not aiming for a mathematical beauty. My skills l ie in diagnosing problems and proposing fixes for them. Randal has mentioned that my code is sometimes ugly. I'll be the first to admit that. But I have a firm grasp of perl's syntax and mechanisms.

What I am learning now, which is making me a better perl programmer (and I dare say a worse !perl programmer), is from experience. Tryi ng to find ways to blend readability with stability and efficiency are teaching me new tricks.

So dont insinuate I am claiming to be the be-all and end-all of perl programmers. I think you would agree that I have at least a reason able facility for spotting <!- SHITTY -> poorly written code. In fact my employer thinks so, and that is what I am getting paid for. A wholesale audit of a site that just doesnt work when put under pressure.

So I maintain here that I am right. and I was right. and maybe, possibly, people didnt think before they sent --'s my way. its also qui te possible that I <!- just shouldnt give a shit. -> shouldnt worry. princepawn doesnt, and I dare say he is the better man for it. I like what he has to say, and I think people unfairly jump the gun on him.

Any unix admin in their right mind, working this site, would shudder at the thought of these perl developers running loose on their ser vers.

Yes, thats a soapbox. Yes, I'm stepping down.

brother dep.

--
Laziness, Impatience, Hubris, and Generosity.