[crdoconnor]

>"getting your work done" (which is admittedly a subjective, hard-to-quantify metric)

Getting "work done" is fairly easy to recognize - you can tell when bugs are getting fixed and features are being delivered and when they are not.

Getting work done to a high standard and delivered at an appropriate speed is, I think, only recognizable by another developer who is as good or better than you.

>Personally, I always try to get to the bottom of this stuff during job interviews - nobody wins if the employee assumes there will be flex-time and the company doesn't allow it!

Yeah, that's one of my red flags during interviews. Companies that are strict on this type of stuff are essentially advertising the fact that management is clueless about what development does and rely upon intrinsically meaningless social cues to build trust. Like suits.

[dagw]

Getting "work done" is fairly easy to recognize

Bob closed 20 tickets this week, and Dave is still working on that one ticket from last week. Who got most work done this week?

[cdevs]

This seems like it would be subjective but it actually tells a story. Most likely tickets aren't being broken down enough, one employee could be snagging easy bug tickets in the morning and another employee could be working on a epic feature.

On the other side of things I have a guy at work who rocks out 20 tickets and a guy at work who tries to go into super plan mode and take his time and make sure every semicolon is perfect 20 times. This is ok, it's what management is for I need to make sure the fast guy is a little more careful sometimes and I need to check on mr planner and make sure he speeds it up sometimes.

[slgeorge]

You just literally defined subjective by using a "story" rather than an objective measure.

[brlewis]

As long as you don't take the story points too seriously, Planning Poker can help avoid misunderstandings about the complexity of a ticket.

To be clear, though, "Who got most work done this week?" is not a useful question.

[ionforce]

One time I got laid off for not closing enough stories. Meanwhile the guy that was kept on was the source of a lot of bugs. So what is that if you generate your own problems and "solve" them?

[brlewis]

That's a different problem from the one Planning Poker addresses.

But to answer your question, the original story should have acceptance criteria such that the ticket can't be closed if there are bugs. Failing that, the bug ticket should be linked to the original ticket.

Continual feedback is also important. If the manager who laid you off valued velocity over bug-free code, that should have been communicated way earlier.

[AnimalMuppet]

"It is essentially impossible to judge a programmer on the basis of a single year's work." - Bjarne Stroustrup

[crdoconnor]

>Bob closed 20 tickets this week, and Dave is still working on that one ticket from last week. Who got most work done this week?

You get an equally or more skilled developer than Bob and Dave to monitor their output and ask them that question. That's the only way.

Was that not obvious from my answer? C'mon.

[rtpg]

Alice works with both of them, and knows that the one ticket Dave is working on requires a lot of refactoring work to solve it nicely.

Or knows that Bob is just that good. Or Dave's having a bad week because of X.

Direct superiors tend to have at least a vague idea of what is happening, along with a certain level of trust. These two make it less likely for the answer to your question to be as ambiguous. At least for ballpark estimates of whether one should be worried.

[Clubber]

If you manager only relies on that one statistic to make a judgement, he is a bad manager. He should know the details of what Dave is working on.

[tk75x]

Metrics should always be supplemented with communication. If Dave's performance is under question, talk to him and find out his progress on the one ticket he's been working on.

EDIT: realized after posting that multiple people made this point. Just goes to show that it should be common sense.

[organsnyder]

Ask Bob and Dave's colleagues as part of a 360-degree review. Their peers definitely know who is being productive and who is slacking off.