one 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
life hack: live longer by dying on fewer hills
@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).
@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 @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.
@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)