3 ms·
Agreed, but you have to be lucky to be not on a toxic team for that otherwise you are going to get a ton of comments by your peers in your Pull Request for triv
by robofanatic 2y ago
Agreed, but you have to be lucky to be not on a toxic team for that otherwise you are going to get a ton of comments by your peers in your Pull Request for trivial things that you left out even though you had clearly stated the scope before, just so that the peers can show that they are doing their job of peer reviewing. And later the ignorant manager questions you in 1:1 about the number of comments on your PR without actually reading them.
This is based on my recent experience.
- diarrhea 2y agoFrom their perspective, what are you going to do? Say you implemented a new function and missed some clear edge cases in the new tests. Or perhaps there's no tests written at all, because it was half-assed. You will have to speak up in a peer review. I'd speak up just to have it written down. Perhaps you just forgot to `git add` that part, I don't know. It'd be professional negligence not to at least bring it up! If your reply is then, 'I'm aware, and didn't do this for reason X', that's perfectly fine, if reason X is at least slightly better than couldn't be arsed.
- mewpmewp2 2y agoI would say to sync on this out of PR before to make sure you are aligned on it with reviewers so they don't have to waste time focusing on the wrong things and writing those comments in the first place.