• Jay (unregistered) in reply to Grey
    Grey:
    Burn, Java, burn in Hell. Easy for programmers means more morons in the industry. Mwa-ha-ha!

    Years ago I came across this piece of wisdom: You can write a Fortran program in any language.

  • bob (unregistered)

    Cannot believe some of the really poor solutions.

    Especially the ones opening up GUI elements for message printing(Headless java,on a server!!!).

    catch (Exception ex) {
            Error_package.processError(ex);

    }

    route all errors to a package to deal with them in a single place.

  • Prism (unregistered)

    e? Naw. ex

    e is event

  • lsmod (unregistered) in reply to blarg

    Picture : E handling the drama exception

  • (cs) in reply to The Poop... of DOOM!
    The Poop... of DOOM!:
    This remidns me of a temp job I had as software tester for a company making hospital software. The parts in the testscripts involving modules that got removed versions ago (and nobody told me that they got removed) left aside, I followed the tests to the letter, including the general "check for GUI inconsistencies". I reported everything I found, going from testing steps that simply failed, blocking the rest of the tests, to buttons that did one thing on one form and then the same button doing something completely different and unrelated on the next one.

    At one point, the guy in charge came in to complain I shouldn't file so many bugs, since it meant "he had to close all of them." I didn't file any bugs since, so that guy was happy, and a few days later I was out of there. I'll never ever go to one of the hospitals using their bug-riddled software, though. Too dangerous.

    I see two possibilities here:

    1. What the guy in charge meant was, "a lot of the bugs you are filing are caused by a common underlying behavior. Please psychically identify this case and do not file redundant bugs when this happens."

    2. What the guy in charge meant was, "I'm not actually going to fix any of these, so please stop doing your job."

    In my limited experience, the first situation is more common (although not by much). However, the people who mean this that phrase it as you indicated are generally very poor at communication, and their work suffers as a result (for example, most people told what you were told react similarly to how you reacted - and suddenly the testing he requested fails.)

    Generally, when I'm a tester in this situation, I'll use my lesser psychic power "requesting clarification." If he (or she) really did mean the first choice, I'll end up reporting each bug verbally, to find out if it's covered by something I (or possibly someone else) already filed, until such time as I'm instructed in how to determine how to determine a bug is related to a particular underlying issue.

    Of course, if he (or she) meant the latter possibility, he (or she) will quickly get to the point of asking me to stop with the verbal assault as well, or she (or he) will guarantee a confrontation by initiating an undermining campaign designed to resolve the issue I present without confrontation. At this point, I'll do my best to leave - although, in the case of the undermining campaign, I'll also do my best to inform someone above said individual exactly what happened.

Leave a comment on “The Pesky "e"”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article