If indentation and newline policies prevent developers from migrating from one project to another then either your developer suck or your language does.
That said, C# is somewhat special in that it is both a language and a corporate flag by Microsoft. Similar to how Google pushes to have their style guides made public so that other projects will adopt them. Which has less to do about making it so that one developer can bounce between projects (because they should be able to anyway) but to instead push Google as the goal everyone aspires to and emulates.
When a developer joins a team, they will not be as productive as they have to learn the code, frameworks, libraries, the project purpose, the tooling, etc… Often this impacts other members of the team lowering the entire teams productivity.
When you use productivity tracking (e.g. things like capacity planning) you will see the teams performance drop and it will take time for it to exceed the previous measured performance. This is the cost of adding a new starter.
So if it takes 6 weeks for a new starter to increase overall team producitivty then planning someone on a project for 4 weeks is pointless since the team will have a higher delivery rate without the extra person. This is typically why an organsation loses its ability to migrate staff between projects.
Code formating affects the layout of the code and our brains do all sorts of tricks around pattern recognition, so if your code formatting rules are too different a someone migrating between projects has to spend time looking for code and retraining their brain.
Its an additional barrier and a one within an organisations skills to remove (by forcing a common code standard).
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…
There’s a lot more than indentation and newline policies. The default editorconfig is a few hundred lines. But there’s also no reason not to standardize indentation and newline policies.
Feel free to point out a disadvantage. As a .NET dev I appreciate the semblance of consistency. Different codebases differ enough already, it’s just easier on the eyes when everyone is using the same basic conventions.
If indentation and newline policies prevent developers from migrating from one project to another then either your developer suck or your language does.
That said, C# is somewhat special in that it is both a language and a corporate flag by Microsoft. Similar to how Google pushes to have their style guides made public so that other projects will adopt them. Which has less to do about making it so that one developer can bounce between projects (because they should be able to anyway) but to instead push Google as the goal everyone aspires to and emulates.
This is about thew new starter cost.
When a developer joins a team, they will not be as productive as they have to learn the code, frameworks, libraries, the project purpose, the tooling, etc… Often this impacts other members of the team lowering the entire teams productivity.
When you use productivity tracking (e.g. things like capacity planning) you will see the teams performance drop and it will take time for it to exceed the previous measured performance. This is the cost of adding a new starter.
So if it takes 6 weeks for a new starter to increase overall team producitivty then planning someone on a project for 4 weeks is pointless since the team will have a higher delivery rate without the extra person. This is typically why an organsation loses its ability to migrate staff between projects.
Code formating affects the layout of the code and our brains do all sorts of tricks around pattern recognition, so if your code formatting rules are too different a someone migrating between projects has to spend time looking for code and retraining their brain.
Its an additional barrier and a one within an organisations skills to remove (by forcing a common code standard).
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…
There’s a lot more than indentation and newline policies. The default editorconfig is a few hundred lines. But there’s also no reason not to standardize indentation and newline policies.
Standardizing within a project or even a company is important.
Standardizing across an industry or language is not
Feel free to point out a disadvantage. As a .NET dev I appreciate the semblance of consistency. Different codebases differ enough already, it’s just easier on the eyes when everyone is using the same basic conventions.