While writing up this quarter's performance review, I re-read last quarter's goals, and found one my boss edited and added a minimum to: "Release more features that customers want and enjoy using, prioritized by product; minimum 4 product feature/bug tickets this quarter."

... they then proceeded to give me, not four+ product tickets, but: three security tickets (two of which are big projects), a frontend ticket that should have been assigned to the designer, and a slow query performance ticket -- on top of my existing security tickets from Q3.

How the fuck was I supposed to meet this requirement if I wasn't given any product tickets? What, finish the monster tickets in a week instead of a month or more each and beg for new product tickets from the product manager who refuses to even talk to me?

Fuck these people, seriously.

This is why tickets should never be used as direct KPI.

KPI as a dev is impossible to find since every dev is hired based on their individual creative output.

A better metric would be to measure the whole team year over year based on tickets completed, and compare a single dev contribution to that effort with impact and priority weighing the stories heavier or lighter.

For example, if the team completed 100 tickets for the year and the dev in review completed 25% of them, but they were all the lowest priority and lowest impact they might not get a great review.

Just my opinion though. Sorry your boss is a bastard.

@sariel Preaching to the choir. And yeah… but there’s no way I could convince management of that. Management talks, it doesn’t listen. And it especially doesn’t listen to a depressed and burned out (and underpaid, as I’ve learned) female dev who routinely butts heads with (and shows up) their golden boy.

Did he just retcon your performance goals??

@TeachMeCode I just checked. He did, 21 days after I wrote the goals. I wasn’t aware of it.

…

@sariel agreed! In a previous company I saw person b being fired cause their tickets were being reopened “too much”… turns out person a was overriding their changes and person c was changing specs AFTER the tickets were closed

@piratefox My boss and one of the ten year devs were talking to the project manager person at work about jira and standard procedures around reopening tickets. They said they only rarely reopen tickets, and it’s supposed to mean the dev missed or screwed up enough that they need to redo the work. It’s meant as a mark of embarrassment. Normally, tickets are left in code review if the requested changes are somewhat minor, such as: make this O(n^2) more efficient, add these checks so it won’t crash, fix this bug, change the layout to this, double the number of specs, refactor it to use this code pattern instead, etc.

But they always reopen mine. Even if the only code review comments I receive are “maybe add another clarification comment here?” or “Hey, could you move this constant up a few lines to this constant group instead?” I hardly ever get any feedback or pushback, either, apart from the above. Still reopened.

@Root and let me guess, when you point out that they are reopening tickets that way it’s not “a developer’s concern”?

I wonder if they all behave the same

@piratefox or “just wanted to make sure you were aware of the comments :)”

Yeah.