5 ms·

> I was let go once for having too many commits in a PR. You were fired for having too many commits in a PR? That seems like an extreme overreaction unless the

by defen 4y ago

> I was let go once for having too many commits in a PR. You were fired for having too many commits in a PR? That seems like an extreme overreaction unless there's more to the story.

otagekki 4y ago
There definitely has to be, on the other end of the commit count spectrum I've seen people being reprimanded for having too few commits. Looks like they had bad management anyway, he might have dodged a bullet there
closeparen 4y ago
The fundamental performance complaint you can make about a developer is that their PRs are bad… whether that’s too little/too late, too many problems, or too unwieldy to reasonably review. You don’t fire someone over one incident. But if someone declines to internalize the feedback and continues to make PRs that are very far from acceptable or even reviewable, yes that is grounds for termination.
- gabereiser 4y ago
  I agree. A volume of commits to get to a workable/reviewable PR is in relation to the code quality and ease of change of the codebase. If I made 20 some odd commits to get to a good working PR (which you compare with develop, or main, or whatnot) you only see the complete change view, not the individual. I think it’s something to discuss. Why did it take so many commits? Is our testing broken? Is our runtime broken? Or is it the fact that we programmed in a lot of hard coded values that only work on the codebase owners machine? Hmmmm…
- defen 4y ago
  > You don’t fire someone over one incident. But if someone declines to internalize the feedback and continues to make PRs that are very far from acceptable or even reviewable, yes that is grounds for termination. I agree; it's just that the way OP phrased it ("I was let go once for having too many commits in a PR", emphasis mine) made it seem like it was just one incident. Unless it was something completely egregious like a 50-commit PR to make a one-line change, I don't see how firing is a reasonable response. Which is why I want to hear the rest of the story :)

by defen 4y ago

> I was let go once for having too many commits in a PR. You were fired for having too many commits in a PR? That seems like an extreme overreaction unless there's more to the story.

otagekki 4y ago

There definitely has to be, on the other end of the commit count spectrum I've seen people being reprimanded for having too few commits. Looks like they had bad management anyway, he might have dodged a bullet there

closeparen 4y ago

The fundamental performance complaint you can make about a developer is that their PRs are bad… whether that’s too little/too late, too many problems, or too unwieldy to reasonably review. You don’t fire someone over one incident. But if someone declines to internalize the feedback and continues to make PRs that are very far from acceptable or even reviewable, yes that is grounds for termination.

gabereiser 4y ago
I agree. A volume of commits to get to a workable/reviewable PR is in relation to the code quality and ease of change of the codebase. If I made 20 some odd commits to get to a good working PR (which you compare with develop, or main, or whatnot) you only see the complete change view, not the individual. I think it’s something to discuss. Why did it take so many commits? Is our testing broken? Is our runtime broken? Or is it the fact that we programmed in a lot of hard coded values that only work on the codebase owners machine? Hmmmm…
defen 4y ago
> You don’t fire someone over one incident. But if someone declines to internalize the feedback and continues to make PRs that are very far from acceptable or even reviewable, yes that is grounds for termination. I agree; it's just that the way OP phrased it ("I was let go once for having too many commits in a PR", emphasis mine) made it seem like it was just one incident. Unless it was something completely egregious like a 50-commit PR to make a one-line change, I don't see how firing is a reasonable response. Which is why I want to hear the rest of the story :)