Re: Re: to perl or not to perl

As far as programming Perl if you're conforming to the (sub)standards they demand, I don't see why not. It's still Perl and you're still learning something about it.

I just want to second this advice. So often, what I hear instead is along the lines of "Just throw up your hands, yell 'You people are so clueless', and stalk out in a huff."

adamsj

They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen

Comment on Re: Re: to perl or not to perl

Replies are listed 'Best First'.
Your client/boss is your (somewhat) god by hackmare (Pilgrim) on Jun 07, 2001 at 20:06 UTC
I think we've all seen this requirement before over and over again. Particularily when we work in multi-faceted teams where everyone comes from a different background and learned the language for various reasons. My current contract is an investment bank with serious in-house perl experience. Yet the team where I am had never even heard of strict as a concept, did not use -T or -w, did not use any OO methods, did not have a working perl debugger working, and used CGI by seeding print statements throught the subroutines. When I started here, I was appalled. I thought I had regressed to babyperl (thank you, monk who used the term on the CB yesterday, I'd give you credit if I knew who you are). Quickly I adjusted to the new problems I had to deal with, such as living in fear of scoping problems and willy-nilly use of local to make up for the lack of strict. Here is the philosophy I approached in this case to cope with the situation: I am a contractor employed to: do what the client wants me to do within some ethical bounds add value to the price my client pays by providing the greatest amount of features possible. Point 1) helps me remember that the client needs to be able to understand my work - like posting Monk is facing. Point 2) helps me remember that it is sometimes a good thing to warn the client of the dangers of such behaviour as not using strict, and of the increase in effectiveness and portability that the client will enjoy from improving the team's adherence to general standards. After 9 months on the job, we have finally managed to convince the group's manager (retired perl/sql coders) that better behaviour was good for everyone, and we now have fully strictified templates, and even managed to teach these old dogs about the benifits of templates and OO design. Summary: We need to do what our managers want us to do. If there is a better, safer, smoother way to do it, we need to give a meaningful defense for that method, and see if we get a bite. But in the end, IMHO, we need not to try to force our own concept of standards down the throats of uninterested people faced with thousands of lines of well spaghetti-ized legacy code. Hope this little story helps. --Hackmare	[reply]

Replies are listed 'Best First'.

Your client/boss is your (somewhat) god
by hackmare (Pilgrim) on Jun 07, 2001 at 20:06 UTC

I think we've all seen this requirement before over and over again. Particularily when we work in multi-faceted teams where everyone comes from a different background and learned the language for various reasons.

My current contract is an investment bank with serious in-house perl experience. Yet the team where I am had never even heard of strict as a concept, did not use -T or -w, did not use any OO methods, did not have a working perl debugger working, and used CGI by seeding print statements throught the subroutines.

When I started here, I was appalled. I thought I had regressed to babyperl (thank you, monk who used the term on the CB yesterday, I'd give you credit if I knew who you are). Quickly I adjusted to the new problems I had to deal with, such as living in fear of scoping problems and willy-nilly use of local to make up for the lack of strict.

Here is the philosophy I approached in this case to cope with the situation:

do what the client wants me to do within some ethical bounds
add value to the price my client pays by providing the greatest amount of features possible.

Point 1) helps me remember that the client needs to be able to understand my work - like posting Monk is facing.

Point 2) helps me remember that it is sometimes a good thing to warn the client of the dangers of such behaviour as not using strict, and of the increase in effectiveness and portability that the client will enjoy from improving the team's adherence to general standards.

After 9 months on the job, we have finally managed to convince the group's manager (retired perl/sql coders) that better behaviour was good for everyone, and we now have fully strictified templates, and even managed to teach these old dogs about the benifits of templates and OO design.

Summary: We need to do what our managers want us to do. If there is a better, safer, smoother way to do it, we need to give a meaningful defense for that method, and see if we get a bite. But in the end, IMHO, we need not to try to force our own concept of standards down the throats of uninterested people faced with thousands of lines of well spaghetti-ized legacy code.

Hope this little story helps.

--Hackmare

[reply]