3 ms·

> Churn should be avoided One of the big Taylorist mistakes of our industry IMO. It is OK to have churn, and it's certainly better to have a little too much th

by pyrale 4y ago

> Churn should be avoided One of the big Taylorist mistakes of our industry IMO. It is OK to have churn, and it's certainly better to have a little too much than too few.

ilyt 4y ago
Disagree. Mixing random style fixes in-between actual code just makes reading changelog more annoying. Sure, if you are refactoring some function put format changes with it but that's the most you should do. If you want to make those: * make it in separate bunch of commits * make sure team uses tooling that will not allow new style problems to happen, like mandating certain formatter with certain settings before each commit. Most editors have hooks to do it automatically, and if they don't, Git have them too It also makes git blame less useful althought it now have options to ignore moved code or whitespace changes so it isn't as much of a deal now.
- pyrale 4y ago
  It seems like your definition of "churn" is "all those petty and annoying things I shouldn't be concerned with or can be easily automated away". By that definition, of course, churn should be avoided when possible. However, plenty of useful changes also qualify as churn, for instance: * renaming stuff * extracting a function to split a block that may have been fine for the author, but that you found hard to read. And yes, sometimes, reviews don't catch all those. * Add a comment to provide context to an algorithm after you talked with business All of these things (and others) are pretty valuable, and the cumulative effect of reducing friction against these changes add up to much better codebases, with less places where no one wants to work because of abandonment. This kind of light touches should take a couple minutes while reading your codebase, not half-a-day because you need to fill a PR and wait for someone to be available.

3 ms·

> Churn should be avoided One of the big Taylorist mistakes of our industry IMO. It is OK to have churn, and it's certainly better to have a little too much th

by pyrale 4y ago

> Churn should be avoided One of the big Taylorist mistakes of our industry IMO. It is OK to have churn, and it's certainly better to have a little too much than too few.

ilyt 4y ago
Disagree. Mixing random style fixes in-between actual code just makes reading changelog more annoying. Sure, if you are refactoring some function put format changes with it but that's the most you should do. If you want to make those: * make it in separate bunch of commits * make sure team uses tooling that will not allow new style problems to happen, like mandating certain formatter with certain settings before each commit. Most editors have hooks to do it automatically, and if they don't, Git have them too It also makes git blame less useful althought it now have options to ignore moved code or whitespace changes so it isn't as much of a deal now.
- pyrale 4y ago
  It seems like your definition of "churn" is "all those petty and annoying things I shouldn't be concerned with or can be easily automated away". By that definition, of course, churn should be avoided when possible. However, plenty of useful changes also qualify as churn, for instance: * renaming stuff * extracting a function to split a block that may have been fine for the author, but that you found hard to read. And yes, sometimes, reviews don't catch all those. * Add a comment to provide context to an algorithm after you talked with business All of these things (and others) are pretty valuable, and the cumulative effect of reducing friction against these changes add up to much better codebases, with less places where no one wants to work because of abandonment. This kind of light touches should take a couple minutes while reading your codebase, not half-a-day because you need to fill a PR and wait for someone to be available.