Just a new index



  • A fiftyish woman I didn't know came up with a request for my coworker. I don't know about you, but a fiftyish serious-looking woman writing COBOL immediately gave me a vibe like "gotta know her stuff, been doing this for decades".



    She asked my coworker if he could add an index to a certain
    table (DB2 database running on an IBM mainframe). It's urgent because she's working on ${BigProject}.



    "Sure, I can do that in the dev environment, what's the problem?"



    "Otherwise this project I'm working on won't work."



    "Erm . . . how so? It's just an index?"



    After twenty excruciating minutes of increasingly vague explanations and calling up her source code:



    "But that's not just a new index for performance, you want me to modify the primary key of that table!"



    "Yeah whatever. Otherwise my code won't work."



    "I understand, but I can't possibly do that. You need to ask ${Manager of DBA team}.



    "Oh her, yeah, I already asked her, she told me I couldn't do that and that I was going about it the wrong way."



    So much for vibes. She actually was a COBOL expert, on paper -- she was a contractor retrained for some months in COBOL after losing her probably non-computer-related previous job. Her contract wan't renewed, but last thing I heard she'd been rehired by another of our divisions because of her extensive previous experience with our systems.


  • Trolleybus Mechanic

     "I need you to make this change to some XML processing for me."

    {twenty minutes later}

    "Umm, that isn't XML processing. You want me to completely change the signature of the webservice API that literally every client uses."

    "Yeah, otherwise my project won't work, and the project lead said I was going about it the wrong way."



  • I have had projects where the script would take hours to run instead of minutes, and lock tables for nearly as long without an index. Of course the answer to the question would "why would it not work" would be "the spec says for the script to complete within our lifetimes".



  • @Lawrence said:

    A filthy woman

    This is how I read this initially. And I imagined her looking like Jane Lynch.



  • @Shoreline said:

    I have had projects where the script would take hours to run instead of minutes, and lock tables for nearly as long without an index. Of course the answer to the question would "why would it not work" would be "the spec says for the script to complete within our lifetimes".

    I may be wrong, but there's a difference between "Would not work" and "Would speed up processing speeds by several orders of magnitude, with said speedup not being attainable through any other way".



  • @Rhywden said:

    I may be wrong, but there's a difference between "Would not work" and "Would speed up processing speeds by several orders of magnitude, with said speedup not being attainable through any other way".
    My former mobile broadband providers did not limit my monthly amount of traffic.

    They only throttled the bandwidth down.

    Until I couldn't download Google's front page before the request timed out.



  • Well, then, while we're comparing apples to oranges, my duck won't fly because the elephant next door isn't grey.



  •  @Rhywden said:

    Well, then, while we're comparing apples to oranges, my duck won't fly because the elephant next door isn't grey.

     So give the duck a new primary key.

     


  • Discourse touched me in a no-no place

    @kilroo said:

    So give the duck a new primary key.
    And change the locks on the doors.



  • @Lawrence said:

    I don't know about you, but a fiftyish serious-looking woman writing COBOL immediately gave me a vibe like "gotta know her stuff, been doing this for decades".


    Haha, no.

    I thought vaguely like that too, but then I got hired on at my current work that has a pretty heavy complement of COBOL devs, who are mostly mid to late fifties. And no, that is not true at all. Generally, the older COBOL people are the ones who weren't skilled enough to retrain into a better language and GTFO. You see a couple of outside consultants who can be considered as "knowing their stuff" but the bulk of the in-house COBOL talent is really mediocre and mostly just putting in time before retirement.

    See, what happens is that COBOL ends up being like a filter. Anyone under 40 with the ability to get a different job quickly retrains on something else and gets the fuck out of there. And anyone older who was actually good with COBOL either died a decade ago, is in Upper Management, or moved on to being a consultant for much, much more money. So if you see someone who is still writing COBOL code as a mere in house developer in their mid-fifties, you can pretty much guarantee that the only reason they're still around is because nobody else wants them.



  • @Snooder said:

    I thought vaguely like that too, but then I got hired on at my current work that has a pretty heavy complement of COBOL devs, who are mostly mid to late fifties.

    To be quite fair in my company the HR people have a policy that means somehow works out to all age groups having their complement of COBOL devs, and all age groups being somewhat equal. Somebody has read about the age pyramid and about the dangers of forgotten competence and taken steps to prevent it. The newest hire in my team, just out of school, has had his COBOL training, even if his neighbor is diligently syncing to the data to Hadoop... but that's not a WTF :)


Log in to reply