I think that the scale of tidyings a developer can perform safely and comfortably can grow as the developer's experience with performing them grows. Do you agree?
For example, I can comfortably perform several changes that are slightly larger than many of the Tidyings you've described "at once" (ie, in one commit) in some code bases, but only now after 25+ years of experience in general and 15 or so in a particular language. I sometimes overestimate that ability and end up having to revert or spend more time than I should, but I feel safe because I'm aware of those triggers you've described - I just choose to ignore those "I've got a funny feeling about this" every once in a while.
Now, having written that thought down, I realize that certain code bases might be more "large tidyable" than others. It would be interesting to explore the characteristics of a code base that contribute to its tidyability scale.
So really 2 thoughts/questions here: 1) the individual developer's personality and experience level might contribute to the types and sizes of tidyings, and 2) the code base itself might contribute.
I think your point is spot-on, save for a single difference: scale depends on experience, but the more experienced engineer will favor smaller tidyings.
It's not the "do more at once" mentality that grows over the years, but rather the humility of "I'm not as smart as I think". The less resistance there is to double-check your work and be at ease with a small step, the faster such a person will compose smaller steps together into a cohesive whole.
In my experience the engineer's personality is orthogonal to skill—there are some who are impatient or anxious about the outcome, so they would rather gorge themselves on scale, rather than have an increment that seems incomplete to them. I'd label this "perfectionist tendencies".
Then there is the "overly catious" developer who is constantly building things outside of feedback loops. There is nothing to prove them right and nothing to stop them, so more is better ,right?. ... right?
PSA: tidying is not the same as refactoring OOP code to functional because it's your style preference or creating many new abstraction without consulting the rest of your team regarding the agreed upon design patterns to use.
A vast majority of our commits represent their own single Jira ticket, with very focused content and from 1 to 4 (or perhaps 8 at most) hours of work in them.
You can read the list of commits since the last production deployment and understand the changelog from it - there would be from 10 to 30 such commits.
Simulating in my head the extreme where I could take the approach from the article, I personally could have perhaps 3-5 tidyings per day, and overall we could have an order of magnitude more commits like this.
It just sounds like there needs to be something extra in this system, to prevent pure chaos :)
I think you're (mis/ab)using code repo history for a purpose other than what it's best suited for. The code history of a piece of software is _not_ the same as the feature/capability history. The two can and should evolve independently.
The way you describe it, any refactoring doesn't seem to fit. I see Kent's Tidying approach as a variation of Refactoring; one with finer granularity perhaps.
My advice, find another tool or technique to track your software's capability history, and let the code repo handle the code's history.
Although there is a way to use commit comments to track features and generate release notes. In such a scheme, you have tags for features, tags for bug fixes, and so on. Tidying changes get different tags if they are their own commits (under most conditions, I'd expect to tidy only as much as needed to do the bug-fix, feature).
I rather like the use of Tidying over Refactoring, mostly because I have met too many developers who use "refactoring" as a synonym for "changing code." Tidying describes the goal of improving the state of the code, which makes things clearer.
I think that the scale of tidyings a developer can perform safely and comfortably can grow as the developer's experience with performing them grows. Do you agree?
For example, I can comfortably perform several changes that are slightly larger than many of the Tidyings you've described "at once" (ie, in one commit) in some code bases, but only now after 25+ years of experience in general and 15 or so in a particular language. I sometimes overestimate that ability and end up having to revert or spend more time than I should, but I feel safe because I'm aware of those triggers you've described - I just choose to ignore those "I've got a funny feeling about this" every once in a while.
Now, having written that thought down, I realize that certain code bases might be more "large tidyable" than others. It would be interesting to explore the characteristics of a code base that contribute to its tidyability scale.
So really 2 thoughts/questions here: 1) the individual developer's personality and experience level might contribute to the types and sizes of tidyings, and 2) the code base itself might contribute.
I think your point is spot-on, save for a single difference: scale depends on experience, but the more experienced engineer will favor smaller tidyings.
It's not the "do more at once" mentality that grows over the years, but rather the humility of "I'm not as smart as I think". The less resistance there is to double-check your work and be at ease with a small step, the faster such a person will compose smaller steps together into a cohesive whole.
In my experience the engineer's personality is orthogonal to skill—there are some who are impatient or anxious about the outcome, so they would rather gorge themselves on scale, rather than have an increment that seems incomplete to them. I'd label this "perfectionist tendencies".
Then there is the "overly catious" developer who is constantly building things outside of feedback loops. There is nothing to prove them right and nothing to stop them, so more is better ,right?. ... right?
PSA: tidying is not the same as refactoring OOP code to functional because it's your style preference or creating many new abstraction without consulting the rest of your team regarding the agreed upon design patterns to use.
Agree
If we try this (a tiny team of let's say 5 people), our repo history will lose a lot of the cleanliness and intentionality it has now.
Is there anything to mitigate it, or should we just accept it as a price for better code in the long run?
What do you mean here by “cleanliness and intentionality”?
Washing hands by intentionally spilling coffee (opposed to accidentally).
Obviously :)
A vast majority of our commits represent their own single Jira ticket, with very focused content and from 1 to 4 (or perhaps 8 at most) hours of work in them.
You can read the list of commits since the last production deployment and understand the changelog from it - there would be from 10 to 30 such commits.
Simulating in my head the extreme where I could take the approach from the article, I personally could have perhaps 3-5 tidyings per day, and overall we could have an order of magnitude more commits like this.
It just sounds like there needs to be something extra in this system, to prevent pure chaos :)
I think you're (mis/ab)using code repo history for a purpose other than what it's best suited for. The code history of a piece of software is _not_ the same as the feature/capability history. The two can and should evolve independently.
The way you describe it, any refactoring doesn't seem to fit. I see Kent's Tidying approach as a variation of Refactoring; one with finer granularity perhaps.
My advice, find another tool or technique to track your software's capability history, and let the code repo handle the code's history.
Although there is a way to use commit comments to track features and generate release notes. In such a scheme, you have tags for features, tags for bug fixes, and so on. Tidying changes get different tags if they are their own commits (under most conditions, I'd expect to tidy only as much as needed to do the bug-fix, feature).
I rather like the use of Tidying over Refactoring, mostly because I have met too many developers who use "refactoring" as a synonym for "changing code." Tidying describes the goal of improving the state of the code, which makes things clearer.