if It gets the job done, then there’s really no point in arguing about it.
Unless there is some job you think is missing, verbosity, performance, testabillity, future proof?
If that’s the case it can be explained in an objective unaccusatory tone.
I often leave optional‘ comments in PR‘s where I point out verbosity semantics, and other nice to have things, but I make it clear they are optional.
And then I say we’ instead of you when I point out things I want changed.
Saying we’ and shaping change requests as questions or requests is a great way to review in a more casual way, bonus points for remembering to include a why or a link that describes what you are getting at.
Ofc. this goes both ways, as PR makers we gotta remember, this is not a war, the reviewer is there to help. Regardless of how they might accidently come across.
It’s probably just a convenient excuse to be lazy, but I very rarely comment on PRs. Only if I spot an obvious functional error or code that will perform badly. Anything else can be improved in a later PR, if necessary.
I prefer to pair/mob when I can so that code can be improved at the moment it’s written.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
if It gets the job done, then there’s really no point in arguing about it.
Unless there is some job you think is missing, verbosity, performance, testabillity, future proof?
If that’s the case it can be explained in an objective unaccusatory tone.
I often leave optional‘ comments in PR‘s where I point out verbosity semantics, and other nice to have things, but I make it clear they are optional.
And then I say we’ instead of you when I point out things I want changed.
Saying we’ and shaping change requests as questions or requests is a great way to review in a more casual way, bonus points for remembering to include a why or a link that describes what you are getting at.
Ofc. this goes both ways, as PR makers we gotta remember, this is not a war, the reviewer is there to help. Regardless of how they might accidently come across.
Thank you for this.
It’s probably just a convenient excuse to be lazy, but I very rarely comment on PRs. Only if I spot an obvious functional error or code that will perform badly. Anything else can be improved in a later PR, if necessary.
I prefer to pair/mob when I can so that code can be improved at the moment it’s written.