in reply to Re^9: RFC: feature proposal re code in @INC
in thread RFC: feature proposal re code in @INC

I try to follow the writer's rule: "write for your expected audience"; and you seem to have a more sophisticated expected audience than I do. In my case, most of the programmers in my workplace who will be asked to maintain my code just aren't very experienced with perl. If they can't understand it, they'll just come back and ask me; I'll end up maintaining it myself. By using simpler constructs, I improve the odds that someone besides me will be able to maintain the code.

Maybe spend some of your time bringing your co-workers up to speed? I usually find teaching stuff a more effective use of my time than coding to the lowest common denominator or turning myself into a bottleneck.

  • Comment on Re^10: RFC: feature proposal re code in @INC

Replies are listed 'Best First'.
Re^11: RFC: feature proposal re code in @INC
by Anonymous Monk on Feb 02, 2006 at 17:25 UTC
    Maybe spend some of your time bringing your co-workers up to speed? I usually find teaching stuff a more effective use of my time than coding to the lowest common denominator or turning myself into a bottleneck.

    Your point is a good one; and if I were in charge of the department, that's what I'd do. On the other hand, I'm not.

    1) I'm not a manager; I don't get to decide how to spend my time. Projects get given to me and I do the best I can with them. Training is not really part of my job description; so I'd have to do training for free after hours. I don't mind teaching, but doing it for free after a long day's work, knowing it will benefit my employer more than it will me, doesn't seem all that fair to me.

    2) Many of my co-workers don't speak English as a first language; discussing technical concepts is more difficult because of a language barrier. Essentially, at times I end up teaching two languages at once (English+Perl); so progress is frustratingly slow, and, like I said, it's not something I'm supposed to spend much time on.

    3) I just don't find it that hard to write simpler code; part of what I was railing at was an ex-coworker using an incredibly obfuscated micro-language solution (with ties, coderefs, objects, evals -- the whole kitchen sink) where a simple SQL query would have sufficed. I find that if I write in a simple, consistant style, I don't have to worry about the alternative ways of "phrasing" something; there's the simple, straightforward encoding, and then there's "something else". If I have to think about something else, odds are I need to think about how to encapsulate the problem better. Nothing I work with is very hard.

    Perhaps if I were an engineer working with differential equations, or a statistician analysing stock market trends, or an AI researcher, I'd need some of those exotic features in Perl. But I just don't need that much complexity to automate FTP downloads, or convert file formats, or do simple financial calculations, or to implement other simple business logic. I get no benefit from @INC codrefs, or other wacky perl features. I just have to make sure they're not being used against me. :-(

    -
    Ytrew

      1) I'm not a manager; I don't get to decide how to spend my time. Projects get given to me and I do the best I can with them. Training is not really part of my job description; so I'd have to do training for free after hours. I don't mind teaching, but doing it for free after a long day's work, knowing it will benefit my employer more than it will me, doesn't seem all that fair to me.

      I'm certainly not suggesting doing it for for free :-) But it might be worth proposing it to your manager and getting them to pay you to do it instead