in reply to Perl Safety

Most people cannot up and quit their jobs just like that. No offense Randal, but that is some horrible advice you gave the man. Quitting is not an option.

By Nature, I do not quit at anything, and that has proven very helpful throughout my short life. Now given that you are older, and most probably wiser than I, I still must express what I believe in.

My suggestion would be to look for another job. Try to find a nother job, go to interviews. Do something to find a place you like. Now, If by chance you want to stay where you are, or are unable to find another suitable job, TAlk to your coworkers, and tell them what you think.

I am sure noone likes to be criticised, but sometimes it is necessary (once again, i appologize to Randal for Criticizing him).

The most important thing is to be happy where you work. Most people dont like their jobs. I am one of the few that does (like his job that is I am just an intern) . And I wish this for everyone.

So gaspodethewonderdog, my advice is simple. Be Happy, and if you're not.. do anything in your power to become happy. Spend the few days that you have in life, enjoying it. Work is something we have to do. Might as well make it enjoyable.

- Have Fun, XDB19

Replies are listed 'Best First'.
RE: Re: Perl Safety
by gaspodethewonderdog (Monk) on Aug 25, 2000 at 23:29 UTC
    I do have to say, I have had to laugh at this thread a little... I've been working with perl off and on the last seven (gosh maybe more...) years and have always enjoyed it... my current employer wanted me to implement some code in perl (I argued for java or c pretty hard... but hey sometimes money talks ;)... anyway I was hoping more somebody would come in with a nice solution and say "here is some neat trick... try this :)"

    Instead I've gotten professional help ;)... which is cool, but I'm a *lowly* contractor here *and* too young... hrmmm... so I can't really get in and play the political games to actually fix the problem correctly... I've bugged the guy a few times to help him fix some things, but he's a little put off by having some 'green' punk kid teach him anything. If anything I think it bothers him more that I've been programming longer than him... and more than likely getting paid more. :(

    Be that as it may, are there *any* tricks I can pull off to protect myself. I know I could localize variables and all that fun stuff, but I'm more afraid he'll go off and create new variables and such and walk all over my code. It has happened a few times to me and unfortunately talking to his manager hasn't helped any because he is basically given free reign to do whatever he wants.

    So can I do something weird like localize main:: or somehow seperate his memory space from mine without his code knowing about it? I really don't care to spend the time to re-write any of his code, especially since I don't want to be walking on any toes.

    I've already ran into enough problems now that I am trying to get him to fix anyway... so this isn't highest on my priority list to get him to fix... I'd rather get him focusing any time he can give me to *not* crashing out on me and killing my programs that use his code.

    Oh well... I guess this thread has become more 'off topic' than what *I* expected at least :)... guess I'll have to see what I can do on my end to get this engineer to help me out :).

      Use package as a buffer.
      Write a package of wrappers around his functions, and then only export those functions from the wrapper. There is no way for a module's code to run over yours if you don't import it into your package. Most of us (well, me anyway) use the main package without bothering to name it. Java doesn't let you get away with this, but since you argued for using Java, maybe you should adopt this habit. Then don't import anything into your named package that you didn't write.

      Does this make sense or is my blood sugar too low?

        Well... I am getting at his module via:
        use Package Package::get_data();
        yet mysteriously in my code after I call Package::get_data() all of a sudden I have variables $x, $y, $z that are defined... now I would have expected theses variables to be Package::x Package::y Package::z, but there they are. I asked the engineer about this and he said that there wasn't any other way to pass multiple variables back through a return... when I suggested a hash he was particularly receptive to the idea...
      Instead I've gotten professional help ;)... which is cool, 
      but I'm a *lowly* contractor here *and* too
      young... hrmmm... so I can't really get in and play the 
      political games to actually fix the problem correctly...
      I've bugged the guy a few times to help him fix some 
      things, but he's a little put off by having some 'green'
      punk kid teach him anything. If anything I think it 
      bothers him more that I've been programming longer than
      him... and more than likely getting paid more. :(
      
      
      ###########
      
      This is precisely the culture that I work so hard to avoid,
      yet landing there seems to be unavoidable.  
      
      If you have a valid point ( and it looks like you do based
      on your description of the problem ), then I suggest you
      become an evil, manipulative bastard by asking the following
      question:
      
      "What am I missing?"
      
      This insidious little question is extremely confrontational
      because it forces them to explain to YOU exactly how their
      way will work.  Their explanation will not make sense, so
      be sure to ask it in the presence of at least 1 ally.  If
      they dodge, repeat the question.
      
      If they dodge, repeat the question.
      
      If they dodge, repeat the question.
      
      If they dodge, repeat the question.
      
      If they dodge again, say "Excuse me, but I really do not
      understand what you are doing here.  Can you please help
      me understand what you are trying to do and how I can
      succeed with your code?"
      
      If they don't help you, then that is a refusal to help
      a coworker whose work depends upon their success.  At that
      point, maybe some sort of third party intervention shall 
      be required.  Be sure to present it as in the context of
      how you do not understand what the other person is doing and
      they are refusing to work with you to solve the problem.
      
      Also, be prepared to leave if your company is extremely sick
      culturally.  They will not like this.  Having allies 
      present is extremely important.  This is a CYA for your
      presentation to HR...if 3 people complain to HR, it will 
      probably be believed.  If 4 people complain to HR, it shall
      be believed and action will be taken.
      
      ##########
      
      On a lighter note:
      
      while ( $dodge ) {
      
         print "What am I missing?\n";
      
      } # while
      
      --moo
      
      Instead I've gotten professional help ;)... which is cool, but I'm a *lowly* contractor here *and* too young... hrmmm... so I can't really get in and play the political games to actually fix the problem correctly... I've bugged the guy a few times to help him fix some things, but he's a little put off by having some 'green' punk kid teach him anything. If anything I think it bothers him more that I've been programming longer than him... and more than likely getting paid more. :( ########### This is precisely the culture that I work so hard to avoid, yet landing there seems to be unavoidable. If you have a valid point ( and it looks like you do based on your description of the problem ), then I suggest you become an evil, manipulative bastard by asking the following question: "What am I missing?" This insidious little question is extremely confrontational because it forces them to explain to YOU exactly how their way will work. Their explanation will not make sense, so be sure to ask it in the presence of at least 1 ally. If they dodge, repeat the question. If they dodge, repeat the question. If they dodge, repeat the question. If they dodge, repeat the question. If they dodge again, say "Excuse me, but I really do not understand what you are doing here. Can you please help me understand what you are trying to do and how I can succeed with your code?" If they don't help you, then that is a refusal to help a coworker whose work depends upon their success. At that point, maybe some sort of third party intervention shall be required. Be sure to present it as in the context of how you do not understand what the other person is doing and they are refusing to work with you to solve the problem. Also, be prepared to leave if your company is extremely sick culturally. They will not like this. Having allies present is extremely important. This is a CYA for your presentation to HR...if 3 people complain to HR, it will probably be believed. If 4 people complain to HR, it shall be believed and action will be taken. ########## On a lighter note: while ( $dodge ) { print "What am I missing?\n"; } # while --moo
RE: Re: Perl Safety
by merlyn (Sage) on Aug 25, 2000 at 23:16 UTC
    Please don't misread my "quit" as literally "don't check in for work tomorrow". What I mean is change the situation. Work whatever way you can to make it different, because it's dangerous the way it is. "quit" doing business as you've been doing it.

    If you can't find a common purpose, and you've tried to find alignment, then you literally do need to find a different job, or be miserable. There's no third option.

    -- Randal L. Schwartz, Perl hacker