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 🙄
@aeva haaaaaaaaaaa wow that pisses me off.
and that is also familiar for reasons I'm not going to allow my brain to consider for now.
and that is also familiar for reasons I'm not going to allow my brain to consider for now.
unable to decrypt message
SnoopJ
d@nny disc@ mc²@hipsterelectron @aud it was a very upsetting and confusing place. At the time I felt like I got along with the people on my team and they certainly seemed friendly. I'm not even sure they realized they were doing it.
@hipsterelectron @aud unexamined prejudice and cognitive dissonance makes people do strange and awful things sometimes. (and sometimes people are just twofaced jerks idk)
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)
@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?"...
@aeva all my PRs, magically delayed! Either review just somehow takes longer to get around to and/or it includes trivial matters not grounded in anything except "I would have done this differently"... or sometimes with made up standards. Or I "committed" things incorrectly and should rewrite my entire branch. And...
yeah. yeah. oooooh. still quite mad about that, actually. Feeling my blood pressure rise.
yeah. yeah. oooooh. still quite mad about that, actually. Feeling my blood pressure rise.
@aud @aeva Ah, but might this possibly break this tiny thing that hypothetically someone might have used once 10 years ago even though the only way anyone would find out it exists would be by reading this source code? I guess we have to bend over backwards to verify this hypothetical person won't be upset if we change this. Yeah so what that people have complaining about the thing for years, we have to think about the hypothetical guy who might want it to be broken.