Cow-orker wtf



  • Here's another good one from Gigantitron Corporation...

    Last week my supervisor (Joe) and I were talking about a project he was working on.  He told me that Bob was supposed to be working on it, so Joe could do other things.  It turned into a peeve-fest.  Bob had claimed that he completed and TESTED the program he was assigned but when Joe looked, it didn't even work.  So Joe spent all weekend fixing it and making it work.  I commented to him that I had noticed in the past that Bob seemed very weak in his programming skills but yet never asked for help.  He would just get stuck and sat on the project for weeks until somebody followed up to see what was going on.  He tended to cut and paste from similar programs (which is ok) but never seemed to understand how the code snippets fit in or how to debug them (which is not).  Basically he would fix any compiler errors, and call it done.  We'd agreed that Bob needed the supervision of a high-schooler - constant hand-holding and prodding and was really a very poor programmer.  We wondered together how long Bob worked here, since it was longer than either of us.  (Me:  6 years, Joe:  15 years)

    Later that day I overheard Joe on the phone (we're in a cubiefarm) talking to the manager about that very same project.  He mentioned the problems he'd had with Bob's work and asked how long Bob worked for us.  A pause, and then a shout:

    TWENTY YEARS???

    Phew!  Twenty years' worth of spineless supervisors who wouldn't or couldn't teach Bob how to do better work and failing that, wouldn't terminate him.  Egad!



  • Not firing the man is bad but what's up with Joe not only fixing Bob's mess, but doing it over the weekend?!



  • Yeah, clearly the problem is completely ingrained.  On the one hand I understand his position:  it would take too long to show Bob what's wrong, how to fix it, and to hand-hold him until it's done.  Faster just to do it yourself.  On the other hand, Bob remains clueless and protected in doing his crappy job. 

    I might have fixed it myself also, but definitely not over the weekend.  But it's easy for me to say that since I'm not a project manager, being held responsible for keeping to the project schedule and budget.  Going over budget and schedule is the price paid for not getting rid of the cruddy employee.  IMHO.



  • @jetcitywoman said:

     Going over budget and schedule is the price paid for not getting rid of the cruddy employee. 

     

    I agree. Count the 20 years worth of salary. If he wasn't pulling his own weight during that time, they should have gotten rid of him. But of course, the rest of them are just taking up the slack, so there he sits collecting a paycheck.



  • The woman has a coworker like that, I'll call her Norma.  She says that Norma is getting better at testing, and it's a good thing, as she's had a couple years to practice it.  I mean really, how hard is it to run a test case created by someone else?



  • @CRNewsom said:

    The woman has a coworker like that, I'll call her Norma.  She says that Norma is getting better at testing, and it's a good thing, as she's had a couple years to practice it.  I mean really, how hard is it to run a test case created by someone else?

    it depends... 

     



  • Color me evil, but when I have encountered people whose incompetence causes my workload to increase, I have always found a way to diplomatically get their butts out the door. Programming is thankless enough as it is without some "liability" making it even more so. I refuse to fix their garbage and let them get credit for it.

    Being asked to join an existing project to get it up to speed is one thing. Working an entire weekend to get something functional while the "Bobs" of this field sit at home and drink beer or take off to Reno for the weekend is completely unacceptable. get them out the door and hopefully, they will find a different line of work (flipping burgers?) and not infest someone else's workplace with their uselessness.



  • @tster said:

    it depends...

    Gee, really? You really think so? Golly. 



  • @Zylon said:

    @tster said:

    it depends...

    Gee, really? You really think so? Golly. 

     

    I'm sorry, did I offend you in some way or are you just beyond hopeless?  The difficulty of running a test depends on many factors.  If you disagree with this statement, then perhaps you should elaborate.  I personally think that the statement is self-evident.



  • The actual act of running a test case may be as trivial as double-clicking a single icon, but testers do far more than just that.  They're on the lookout for bugs.  They have to try to anticipate the strange things users might do (especially users for whom the program might be totally new, whereas a programmer or a tester may be intimately familiar with it's correct operation).  A really good tester might be the most valuable asset a programmer has, and should never be underestimated.



  •  I love testing - when I'm testing other people's products. There's just some inherent pleasure in breaking someone else's stuff.

    "Let's try this..." (click)... BANG!!! "Oops, wasn't expecting that, was you? Bwahahahahaha! Fail."



  • @mfah said:

    The actual act of running a test case may be as trivial as double-clicking a single icon, but testers do far more than just that.  They're on the lookout for bugs.  They have to try to anticipate the strange things users might do (especially users for whom the program might be totally new, whereas a programmer or a tester may be intimately familiar with it's correct operation).  A really good tester might be the most valuable asset a programmer has, and should never be underestimated.

     I agree with mfah. A good solid QA team is a great asset and can help ship a more reliable product. Their testing is varied based on what they are trying to reproduce. Rarely ever do we depend on automated tests, but usually have some steps to reproduce problems that we have seen. Depending on the issue, some problems are harder to reproduce than others. Persistant QA testers are a great benefit to us because they will beat and beat on our software and try to make it break. The only downside is that they can probably reproduce things you'll never see in the field (by running it at a greater speed or load) but by accounting for all those cases, we make a more reliable product to give our customers. And fixing those things that are troublesome at high speed or load cases will probably prevent a problem in a critical situation.



  • @RayS said:

     I love testing - when I'm testing other people's products. There's just some inherent pleasure in breaking someone else's stuff.

    "Let's try this..." (click)... BANG!!! "Oops, wasn't expecting that, was you? Bwahahahahaha! Fail."

     

    You know how sometimes when you're using a certain piece of software -- not even testing, just using -- and you suddenly realize that there's some bizarre corner case that you're just certain the developer didn't think of?  I cannot resist immediately trying it out.  And it always ends with things going haywire and spending half an hour trying to fix what I broke, but I still can't resist.



  • @tster said:

    @Zylon said:

    @tster said:

    it depends...

    Gee, really? You really think so? Golly. 

     

    I'm sorry, did I offend you in some way or are you just beyond hopeless?  The difficulty of running a test depends on many factors.  If you disagree with this statement, then perhaps you should elaborate.  I personally think that the statement is self-evident.

     

    Congratulations, you got the point. 



  • NOTICE:  Sarcasm Detection

    TO:  Zylon

    FROM: The Internet

    It is hard to detect sarcasm on the internet.  When you use words often used in sarcastic ways, people will probably assume you are being sarcastic. 



  • It's a good thing I was being sarcastic then. 



  •  Alright guys, now kiss and make up.



  • @MasterPlanSoftware said:

     Alright guys, now kiss and make up.

     

    And no tongues.

     

    OK then, just a little. But be quick. 



  • @RayS said:

    And no tongues.

    OK then, just a little. But be quick. 

     

    Just close your eyes and picture Irish Girl!



  • I didn't mean to say that testing was all following the specific directions of the test case, but rather, that at its absolute easiest, that is what you are doing.  I certainly appreciate a good quality check no matter the project, but this woman was incapable of performing the task unless you walked her through each step of the process ad nauseum.  Even then, she couldn't start to do the same process again on her own.  Not being able to finish the process, I may be able to understand, but to not have the ability to start it would have driven me crazy.

    /By crazy I mean crazier than I already am.  Difficult to do, but possible.


Log in to reply