Tools and frameworks do indeed take time to come up to speed on. That is onboarding and training
Code formatting should not. If it is taking new developers any meaningful degree of time to adapt to a new style then, again, either your developer or your style sucks. The time it takes to ping HR because they never sent you a document is a much bigger delay than anything else.
And, the very nature of coming up to speed on a code base ensures you figure out any quirks. Because you aren’t making a 10 thousand line pull request on your first day. You are doing something small. So you can get your editor set up to automate most of that and the rest you figure out while going through code review/linting/pre-commit.
So yes, different coding styles will result in minor fluctuations on your “productivity tracking” software. So does having a chair where the reclining lock is in a different position or remembering where the coffee machine is. And if you are at the point where you are optimizing having your developers learn the preferred structure for an if block? You have already won and have the most optimized organization on the planet.
But the reality is that this is the kind of thing that bean counters who use productivity trackers get off on. It allows managers to quantify their employees without ever having to understand what they are doing. And it similarly provides a quantifiable way to say “I improved efficiency by 4% relative to some baseline I cherry picked from the day after a long weekend. Money please!”. Often at the cost of annoying their staff and decreasing the time before people update their linkedins.
Fun story/group therapy time! Couple years back I was on a project where the lead was a REAL moron. Got the job because he was married to the head of a different department and threatened to leave if he didn’t have opportunities for career advancement, etc. Anywho, he insisted we all needed to switch to a “more efficient” coding style (I don’t think it was the google style guide, but one of the popular ones). Took a whole day off of development so we could sit through presentations and do exercises on the benefits of this style while also, obviously, not having time to just set up the pre-commit hooks to automate the migration.
But I was actually in the final days before taking leadership on a different project (which made handing off responsibilities a real pain in the ass but…). And he presented on how amazing the improvements were during one of the project leads meetings. I want to say he measured something like a 30% improvement in SLOC per day which set my BS alarm off massively. Fortunately, as a lead, I now had access to the tools used to collect those metrics. He chose the day where nobody was allowed to code for about 6 hours straight because we were learning about the new system as his baseline. And still only had a 30% gain…
Tools and frameworks do indeed take time to come up to speed on. That is onboarding and training
Code formatting should not. If it is taking new developers any meaningful degree of time to adapt to a new style then, again, either your developer or your style sucks. The time it takes to ping HR because they never sent you a document is a much bigger delay than anything else.
And, the very nature of coming up to speed on a code base ensures you figure out any quirks. Because you aren’t making a 10 thousand line pull request on your first day. You are doing something small. So you can get your editor set up to automate most of that and the rest you figure out while going through code review/linting/pre-commit.
So yes, different coding styles will result in minor fluctuations on your “productivity tracking” software. So does having a chair where the reclining lock is in a different position or remembering where the coffee machine is. And if you are at the point where you are optimizing having your developers learn the preferred structure for an if block? You have already won and have the most optimized organization on the planet.
But the reality is that this is the kind of thing that bean counters who use productivity trackers get off on. It allows managers to quantify their employees without ever having to understand what they are doing. And it similarly provides a quantifiable way to say “I improved efficiency by 4% relative to some baseline I cherry picked from the day after a long weekend. Money please!”. Often at the cost of annoying their staff and decreasing the time before people update their linkedins.
Fun story/group therapy time! Couple years back I was on a project where the lead was a REAL moron. Got the job because he was married to the head of a different department and threatened to leave if he didn’t have opportunities for career advancement, etc. Anywho, he insisted we all needed to switch to a “more efficient” coding style (I don’t think it was the google style guide, but one of the popular ones). Took a whole day off of development so we could sit through presentations and do exercises on the benefits of this style while also, obviously, not having time to just set up the pre-commit hooks to automate the migration.
But I was actually in the final days before taking leadership on a different project (which made handing off responsibilities a real pain in the ass but…). And he presented on how amazing the improvements were during one of the project leads meetings. I want to say he measured something like a 30% improvement in SLOC per day which set my BS alarm off massively. Fortunately, as a lead, I now had access to the tools used to collect those metrics. He chose the day where nobody was allowed to code for about 6 hours straight because we were learning about the new system as his baseline. And still only had a 30% gain…