There's a quote from Blaise Pascal that captures my feelings on small changes fairly well: "I have made this longer than usual because I have not had time to m

There's a quote from Blaise Pascal that captures my feelings on small changes fairly well: "I have made this longer than usual because I have not had time to make it shorter." Small changes mean front-loading a lot of the thought into breaking down the problem. Large stories/changesets is often a sign of a vague requirement or design up-front where the developer mostly figures out how to solve the problem while writing the code. It's not really the size that's the problem, it's the uncertainty. But the size is much easier to observe and use as a forcing function for increased planning (i.e. large stories need to be broken into smaller stories before a developer can start work.) When you talk about the best developers being the ones that push small changes, what I believe you're really saying is that the best developers are the ones that are able to be given a large problem and break it down into its constituent parts most easily and the ones that have the discipline to do that in planning rather than while coding. Which, to me, is a lot less controversial statement.