Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

How not to start a morning 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • These are the sort of clients who won't listen to reason. Have you showed them an itemized list of $$$ billed for fixing their mistakes? And how much larger it is compared to just writing some sanity checks? That sometimes opens people's eyes. And if it's only a few hours, wouldn't it be worth it for your company to just eat the time and be able to call the client first to tell them they screwed up? I've always loved showing someone that the "bug" is really their error. :=)

    You have to figure out if the ex

    --
    "Perl users are the Greatful Dead fans of computer science." --slashdot comment

    • I can't help but wonder if your title was a typo -- 'me versus 'em :)

      We have broken this down for them before but the response is typically something along the lines of "once we nail this thing, it won't change any more" (which, of course, is the reason most of us with jobs still have them.)

      You are correct in thinking that giving up the ongoing revenue from their stupidity is worth my sanity, but I have three other problems with issue. First, I hate to have a system that I know is wrong. The data vali

      • D'oh! I hate it when I do that... Where's a spell check when you need one?

        Point #1: I hate having a fragile system as well. It really bugs me that I have to keep tweaking it for no _good_ reason. I had a project like this once at my current job, but I finally bit the bullet and got things right. Life has been much simpler since.

        Point #2: Right on! This also applies to inter-business projects. I'm constantly getting notes about how something didn't work right. 95% of the time it's either a known issue I've found & resolved a workaround w/ another employee or it was human error. Yes, this probably means at some point I should revisit some of these "problem" areas and make sure they don't happen in the first place. I've heard the sighs a little to regularly, but often don't have the luxury of fixing them. :-(

        Point 3: Agreed again. For me, it's often difficult to get into a groove. Those are the days I work a little late because I don't want to lose the momentum. This is not expected (and often not noticed except for CVS commit logs), but I do it because it's better for how I work.

        Even if the new request is _very_ simple, I lose time having to figure out what I was doing (and since I'm a good programmer I try to add comments to aid the next person who comes behind me), fix it, test it, and launch it. Even for trivial requests it's at least 1/2 hour. So more complex things ofter get pushed off just because it would break my existing schedules. I'm fortunate in that I have few _hard_ deadlines because everyone prefers a well-designed & implemented application. But I know people get annoyed nonetheless.

        I think for me Point 2 is the most important. My company is small, and I can't afford to be known as the guy whose apps are flaky. That reputation doesn't get me raises! :-)

        --
        "Perl users are the Greatful Dead fans of computer science." --slashdot comment
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.