You allow naming schemes to change every two weeks? That’s just insane! You might as well not have a naming convention then, since the project is going to be full of different conventions.
You might as well not have a naming convention then, since the project is going to be full of different conventions.
Oh, I skipped this. Lol. Obviously not. As a team, they can implement whatever convention change they want, every two weeks.
As manager, I expect them to update all active projects, in their entirety, to the new convention, each time.
And as I mentioned in my other comment, if their test coverage isn’t at a level that makes me confident in that kind of global change (70% tends to be plenty), then I reserve the right to table it - until they bring the test coverage up (on all impacted projects).
Well that makes more sense, but it is still a lot of churn. I guess it’s fine in a project where you can change it all in a couple days. We have tens of thousands of files in the project I’m in charge of, so we’d never consider such an extensive refactor. We discuss naming conventions whenever we start a new project, and then it’s locked in. Thankfully we’re all pretty much of like-mind. Nothing changes from project to project in the naming realm. I did do away with BEM when I started, because I despise that clusterfuck of a convention for more reasons than I care to explain here, but I waited until a new project to do it, and everyone agreed with me.
Well that makes more sense, but it is still a lot of churn.
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.
Thankfully we’re all pretty much of like-mind. Nothing changes from project to project in the naming realm.
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.
We discuss naming conventions whenever we start a new project, and then it’s locked in.
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.
We have tens of thousands of files in the project I’m in charge of, so we’d never consider such an extensive refactor.
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.
I did do away with BEM when I started, because I despise that clusterfuck of a convention for more reasons than I care to explain here, but I waited until a new project to do it, and everyone agreed with me.
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”.
That’s some holy and righteous work you accomplished. All future developers on that effort owe you a debt!
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.
You allow naming schemes to change every two weeks? That’s just insane!
Yes. Everything is open for discussion every two weeks, during our retrospective meeting.
Of course, that doesn’t mean things will actually change that fast.
But let me push back a bit, too - a global find and replace on our entire source code would take maybe a couple hours. A substantial naming convention refactor would take maybe a couple of days.
The reason we don’t do anything that aggressive is we don’t trust ourselves to make the change correctly - not because it’s actually a difficult change to make. Where our test coverage is where it should be, it’s a perfectly safe change.
If my team tells me (in agreement with each other) that a change like that is necessary, my job is to go make time for them to get it done.
On the scale of requests my team has given me, a couple days to rename some variables is no big deal.
There’s absolutely stuff I won’t allow, as team manager, but flip flopping on variable naming is owned by the team, and I would allow it, within reason.
A couple fair-game manager reasons I might shut down a variable naming convention change are:
The test coverage on that part of the code doesn’t inspire enough confidence to make any unnecessary changes. Improve the test coverage, and we will revisit.
(Hypothetically) We made two similar changes in recent memory, and as manager, this is affecting our team reputation. Let’s make a plan to make this change in a way that does not impact our team reputation.
Anything short of those two scenarios, and - should my team present it to me in agreement - I go make the time for them to make the change.
A shorter version is: I’ll discuss and do my best to support whatever my team wants to change - every two weeks. It’s a small price to pay for some peace for 9 out of every 10 business days! (And honestly, it’s a big part of my success formula.)
You allow naming schemes to change every two weeks? That’s just insane! You might as well not have a naming convention then, since the project is going to be full of different conventions.
Oh, I skipped this. Lol. Obviously not. As a team, they can implement whatever convention change they want, every two weeks.
As manager, I expect them to update all active projects, in their entirety, to the new convention, each time.
And as I mentioned in my other comment, if their test coverage isn’t at a level that makes me confident in that kind of global change (70% tends to be plenty), then I reserve the right to table it - until they bring the test coverage up (on all impacted projects).
Well that makes more sense, but it is still a lot of churn. I guess it’s fine in a project where you can change it all in a couple days. We have tens of thousands of files in the project I’m in charge of, so we’d never consider such an extensive refactor. We discuss naming conventions whenever we start a new project, and then it’s locked in. Thankfully we’re all pretty much of like-mind. Nothing changes from project to project in the naming realm. I did do away with BEM when I started, because I despise that clusterfuck of a convention for more reasons than I care to explain here, but I waited until a new project to do it, and everyone agreed with me.
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.
Yes. Everything is open for discussion every two weeks, during our retrospective meeting.
Of course, that doesn’t mean things will actually change that fast.
But let me push back a bit, too - a global find and replace on our entire source code would take maybe a couple hours. A substantial naming convention refactor would take maybe a couple of days.
The reason we don’t do anything that aggressive is we don’t trust ourselves to make the change correctly - not because it’s actually a difficult change to make. Where our test coverage is where it should be, it’s a perfectly safe change.
If my team tells me (in agreement with each other) that a change like that is necessary, my job is to go make time for them to get it done.
On the scale of requests my team has given me, a couple days to rename some variables is no big deal.
There’s absolutely stuff I won’t allow, as team manager, but flip flopping on variable naming is owned by the team, and I would allow it, within reason.
A couple fair-game manager reasons I might shut down a variable naming convention change are:
Anything short of those two scenarios, and - should my team present it to me in agreement - I go make the time for them to make the change.
A shorter version is: I’ll discuss and do my best to support whatever my team wants to change - every two weeks. It’s a small price to pay for some peace for 9 out of every 10 business days! (And honestly, it’s a big part of my success formula.)