3 ms·

Interesting that you perceive a dichotomy there, can you elaborate where you see the conflict? As a reviewer, I see myself as a (extremely near, time T+epsilon

Interesting that you perceive a dichotomy there, can you elaborate where you see the conflict? As a reviewer, I see myself as a (extremely near, time T+epsilon) future developer who is trying to see what the hell is happening.

michaelcampbell 3y ago
There's a dichotomy between a history of actual code changes, oopsies and redos included, and "a carefully crafted story of the intent of this change". One is an ugly reality, the other is a pretty story of intention. The process vs. the final result. Both are useful, but in different contexts. The latter is good for a PR, but when optimized for that often loses a lot of other context, and is meant to be a throwaway bit of data that once the PR is approved, never seen again, nor meant to be seen again. The former can delve a bit into what experiments were tried and abandoned and can give a lot more meaning to the final result. > As a reviewer, I see myself as a (extremely near, time T+epsilon) future developer who is trying to see what the hell is happening I generally find this to not be the case; reviewing is to see what this might "break" and has IME been extremely transactional. Not all PRs nor reviewers are like this of course, and you may not be one. But, again, IME, this is the "modern" workflow.
- Capricorn2481 3y ago
  > The former can delve a bit into what experiments were tried and abandoned and can give a lot more meaning to the final result. I haven't found this to be true at all. Commits don't tell me anything other than when the coder left their desk for the moment. When there's a policy that allows people to have a "rough, ugly history", where a coder chooses to commit is completely arbitrary. I would argue that the clean, crafted story is the only helpful one. You can argue that a coder shouldn't be committing unless they are at a natural milestone that can be annotated, but I would consider that the "crafted" story.

michaelcampbell 3y ago

There's a dichotomy between a history of actual code changes, oopsies and redos included, and "a carefully crafted story of the intent of this change". One is an ugly reality, the other is a pretty story of intention. The process vs. the final result. Both are useful, but in different contexts. The latter is good for a PR, but when optimized for that often loses a lot of other context, and is meant to be a throwaway bit of data that once the PR is approved, never seen again, nor meant to be seen again. The former can delve a bit into what experiments were tried and abandoned and can give a lot more meaning to the final result. > As a reviewer, I see myself as a (extremely near, time T+epsilon) future developer who is trying to see what the hell is happening I generally find this to not be the case; reviewing is to see what this might "break" and has IME been extremely transactional. Not all PRs nor reviewers are like this of course, and you may not be one. But, again, IME, this is the "modern" workflow.

Capricorn2481 3y ago
> The former can delve a bit into what experiments were tried and abandoned and can give a lot more meaning to the final result. I haven't found this to be true at all. Commits don't tell me anything other than when the coder left their desk for the moment. When there's a policy that allows people to have a "rough, ugly history", where a coder chooses to commit is completely arbitrary. I would argue that the clean, crafted story is the only helpful one. You can argue that a coder shouldn't be committing unless they are at a natural milestone that can be annotated, but I would consider that the "crafted" story.