another emotionally gruelling day...
who would've known. i broke down today in my one on one meeting, because i've sat through too much this week of ppl telling me i don't do my job well.
add to that i sent out the comprehensive guide on an area of the site no one has any documentation about, complete with hand holding to guide u through, screenshots etc etc - i got great feedback from dev MANAGERS etc.
part of me almost didn't "publish" this helpful document, partly out of spite because they don't think this stuff is "as important" as bug count. partly because quite frankly, in MY opinion, that email, and all the kudos, make my dept look GOOD, as if this is planned, pre-mediatated, ENCOURAGED even - totally NOT the case. I scrape time by to create these docs and tools to help others, because i truly believe in teach others how to fish. i get penalized for them because i can spend the time filing bugs instead to up my personal and our org's numbers. i look around, identify what is needed and not yet there, create it not only as a document but as a tool, with bells and whistles and a nice looking UI, functionaly, pretty.
the dev managers probably think we are an org that fosters such "initiatives" and "creativities" and "innovations". in the end, i wonder how much they really know.
i'm at -5 for the week so far. filed a few p4's which may seem ridiculous. like "should be lower case isntead of upper case" or "should be singular instead of plurial" - fantastic genius stuff.someone asks, why do you go negative, why not start at 0 and count UP to 15 bugs/week?
i find the negative count more accurately reflect the connotations and spirit of the quota - afterall, i'm not held accountable for how many MORE bugs that 0 i file a week. i am accountable for how many bugs LESS than the required 15 a week, that's the important number.
in the positive light, i can't do worse than -15 count a week...
posted by Amy @ 7:28 PM
2 comments
2 Comments:
oh we have 'tools' groups, but they're usually swamped with requests anyway.
I gotta admit right now though, these last few days I've been thinking that you were resolving these bugs (ie.fix 15/week) Finding 15... that *is* retarded. I agree making tools in this case makes more sense - but get the billable hours for it first. There's a woman on our team who does your kind of work, and I can't compare you to her but sometimes I think she's a little off her rocker. For instance, she spent three weeks "investigating" a feature (which I admit wasn't completely straightfoward but didn't require 3 weeks) to code ONE line of code. Not a long line, just setting a flag or something. She wrote up a 20 page document on changing this one line. Yeah, she made some nice flow diagrams that didn't exist (although pretty useless in the grand scheme of things) that she supposedly "needed" to figure things out but c'mon. At most a week to implement, and if you want, waste your time testing the billion scenarios affected. She's always saying weird things that we thought she was red-flagged but turns out she's sticking around a little longer than some of us. She also spent monnnths cleaning up our testing scripts in order to make them backwards compatible etc. In the end, most of us who were already using the tool continued to use it but since we're always in a rush I don't think the test libraries were properly updated and this backwards compatibility was pretty useless. *I* personally hated it because everytime I had to write some scripts I would find errors, and compilation methods were changed ("to make it easier") but it just meant I would waste more time just trying to re-learn how to use the tools. Grrr.
The "yes" man approach. You're right, for me, my job is not my life. Tri is what I enjoy - but a lot of the stuff I've seen is proprietary and pretty useless once you get out. (Not to mention outdated, from what I hear.)
amy, your tools rock and they definately help me in my day to day testing. imagine how many lost souls there will be if you decided to take lilo down . . . ;)
Post a Comment
<< Home