this post was submitted on 20 Dec 2024
186 points (97.9% liked)
Programmer Humor
19821 readers
2 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Sure, I mean it risks a lot of churn, but it hasn't happened, in practice.
My team will debate the merits of a change until the cows come home, but they know that if they actually decide to make the change, I'll expect them to put in all the necessary work to do it right. Ironically, that tends to curb their appetite for perfectionism.
Yeah. Same here. That's really why I get away with technically allowing a change during any retro. My teams appetite for refinements settled down after our first four sprints as a team.
Things might get interesting again, when we make our next hire; but I consider that part of the onboarding process. It should be worth the trouble just in case the new hire brings brings smart new practices we might have been ignoring. And whether anything changes or not, it creates a time and place for the new hire to argue their differences with the team.
That's very practical, and really accomplishes the same net effect as my team's policy, with less theoretical risk of thrashing.
A possible difference is that sometimes my team will insist on a refactor of some old code to update to the latest standards, at the start of a new project updating an old product.
As long as the code test coverage is acceptable to me, I'll green light that effort as part of sprint zero.
Oh yeah. I would probably use my manager veto in that case. At some point it's just too much work to verify the change.
We do have one big repo that we're breaking up over time, and I insist that such changes be limited to the current actively developed component. It's a unique case, because the vision for the repo is to get smaller as parts of it are decoupled (and released as open source). So we don't deeply care if different modules have mildly different code standards, since they're destined for separate public repos, in the long run.
That's some holy and righteous work you accomplished. All future developers on that effort owe you a debt!
That's cool that you take input from new-hires and consider the viewpoints they bring to the team. It's always annoying to be excited about a new job, and then be told "this is the way we do it, and that's final".
Ha! Thanks! They were using it because that's what Adobe recommends, and I made a very strong and opinionated case as to why Adobe needs to pull their heads out of their asses. Haha. Unexpectedly, everyone agreed with me.