aevaone of the more useful things I realized at some point for how to be a good code reviewer is "that's not how I'd do it" is not constructive feedback and is not a valid reason to request a change, and if you can't think of an actual good reason to block a review, you can save a lot of time for everybody involved by just chilling out about it
Asta [AMP]@aeva it was not until quite recently, in the grand scheme of things, that I had positive PR experiences that didn't involve pushback from a senior male employee that boiled down to (or was plainly stated as) this.
At my current job, in fact, I had a shit ton of anxiety about PRs for probably the first six months due to numerous, numerous experiences where a PR was used to gatekeep and delay my contributions. Especially when I could look at other PRs where male colleagues were doing exactly the same thing and were approved without even a comment on it.
I'm not as anxious now specifically because I've received good feedback at my current job (not coincidentally, none of it was ever shaped like this).
At my current job, in fact, I had a shit ton of anxiety about PRs for probably the first six months due to numerous, numerous experiences where a PR was used to gatekeep and delay my contributions. Especially when I could look at other PRs where male colleagues were doing exactly the same thing and were approved without even a comment on it.
I'm not as anxious now specifically because I've received good feedback at my current job (not coincidentally, none of it was ever shaped like this).
@aud my last job (about 10 years ago) I worked at a place like that and they tracked individual "velocity" as a performance review metric. every single thing I'd try to submit took a week to get through review no matter how trivial.
@aud that team also did a thing where the entire team votes on the "point" score of a given ticket, and mine always got voted low for some reason 🙄
Bee O'Problem 
@aeva @aud planning poker has to be one of the dumbest things I've experienced. Not so much on the consensus building RE time estimation, but the nonsense "complexity points" thing which ultimately maps to time anyway "1 point is an hour, 4 points is a day, 8 points is a week etc" It's still a time estimation, just with a bogus abstraction wrapped around it for some reason.
Maybe the abstraction exists to make it easier to handwave BS like you dealt with
@beeoproblem @aud my rule (i'm a lead now) is the person doing the work provides their estimates, and my job is mostly to keep track of the error bars and keep an eye out for signs of other problems. if someone were to ask a month for something that should only take a day, then the why is something I need to look into, but generally what happens instead is people usually under estimate the amount of time needed and I may need to ask them to add more time so our planning is more accurate.
@beeoproblem @aud imo velocity is a shit metric. imagine trying to budget your finances with "velocity". don't spend any less, just yell at your money until it spends faster
@aeva @beeoproblem I feel like it's obvious from what you said, but clearly in the hands of someone who is a team lead "in good faith", these metrics can be tools
but in explicitly or implicitly biased hands, they're weapons. Same story as ever, I suppose.
but in explicitly or implicitly biased hands, they're weapons. Same story as ever, I suppose.
@aeva @beeoproblem having said that, it's nice to hear your approach as a team lead. It's always nice to hear about good environments and practices...
@aud @beeoproblem I honestly don't think velocity is useful for anything other than being a stack ranking KPI for companies with no real deadlines. Like how do you use that to actually plan anything? "Oh my team can crank out an average of 3 complexity points per person per week" that doesn't mean anything.
@aud @beeoproblem like, how many story points is a pregnancy lol can you divide that up between a team 9 men to make it go faster?
@aeva @beeoproblem story: "As a new person, I would like to be born faster..."
@aud @beeoproblem somehow I've managed to get away with refusing to abide the infantalizing practice of writing feature specifications as "stories". my theory for why is because nobody actually gets anything out of it
@aeva @beeoproblem I have thankfully never had to do it. I only know it as a concept because my manager at Cray had gone to like, Agile School.
(even she didn't phrase stuff that way)
(even she didn't phrase stuff that way)
unable to decrypt message@aeva @beeoproblem ah, yeah, I just meant about points in general, not velocity. Velocity is...
I mean points across people aren't even comparable. It's a metric useful only to the individual, if they are allowed to do that. It is a thousand percent meaningless across teams.
You'd think people that had to get through some degree of education and who understand the concept of an "Easy A" would like... get this.
I mean points across people aren't even comparable. It's a metric useful only to the individual, if they are allowed to do that. It is a thousand percent meaningless across teams.
You'd think people that had to get through some degree of education and who understand the concept of an "Easy A" would like... get this.
FWIW the team I work with that used to do points/planning poker ended up ditching it for something roughly similar to how you're doing things.
Usually there's some postmortem done WRT how accurate estimates are vs how long the project ended up taking so we can determine if there's an issue with unanticipated difficulty. Blown estimates tend to fall into the usual suspects. Most recently I red-lit a release due to biz assuming a prerequisite feature existed when it didn't
@beeoproblem @aeva Our team is small, so I try to do that sort of like, post-mortem thing during my 1 on 1s (unless there's something else to bring up). But overall I agree re: the post-mortem. I think it can be a useful practice, if done in a positive environment. Sometimes a ticket is poorly scoped, sometimes it is poorly defined, sometimes I just vastly overestimated my own knowledge or underestimated the amount of work. Either way... learning process.
But this only works in a positive environment.
But this only works in a positive environment.
Philippa Cowderoy@aeva @beeoproblem @aud velocity has a different meaning in economics and I wish politicians paid more attention to it
you might recognise "how fast does this same $10 get spent to get different things done?"...